The OBAN project and issues for standardisation

Duration: 3 years 2004/1 – 2006/12

Budget/EC cont: 11/5 M€

14 partners coordinated by Telenor

• 4 telecom operators (Telenor, Telefonica, Swisscom, France Telecom)

• 6 industrial partners (Lucent(NL), Birdstep(N), ObexCode(N), Motorola(I), EuroConcepts(I), Lucent(UK)

• 3 universities/institutes Sintef(N), Techn. Univ. Berlin(D), ISMB(I)

• 1 national telecom regulatorNPT(N)

Abstract

• This presentation introduces the concept of OBAN (Open Broadband Access Network), an European funded project under the IST 6th framework program.

• The presentation focus on the mobility architecture and the challenges introduced:

– Scalable and flexible mobility management in a cross Access Service provider /Internet Service Provider scenario

– Handover for delay constrained services such as voice, video etc.

Rational behind

• Wireless LANs have large capacity and are often poorly exploited

• OBAN intends to investigate how the public can obtain access to these resources and what kind of services can be provided over this network.

The concept contains numerous challenges

• Mobility aspects – nomadic or continuous mobility

• Security and authentication

• Roaming agreements

– Between different network operators

– Between owners of Residential Gateways (RG)

• How to match QoS in the legacy network with what can be achieved in a wireless LAN and while traversing from RG to RG ?

• How to deal with the large variety of terminals?

• Interference between RGs and with other equipment – frequency planning

• Business models and commercial aspects

The Security & Mobility Challenge (1)

• The security level expected for OBAN architecture has to coexist with strong time and QoS constraints

• A goal of 120 ms maximum handover latency implies that a full authentication that involves several actors and ditto round-trip times is not acceptable.

• Fast handover requires an authentication mechanism that only involves the terminal and the RGW.

• Security in relation to fast re-authentication during handoff:

– Two potential solutions:

– delayed authentication,

– fast hand-over using Kerberos Tickets

The Security & Mobility Challenge (2)

• No preprocessing of keys and session parameters by network to prepare handover in advance.

– 2G and 3G does this by default

• An STA in IEEE802.11 can only be associated with one AP at a time.

• The mobile station must after sensing a beacon, negotiate with next AP that again must performs a full RADIUS roundtrip with ISP to handle AAA and security session

– In practice: a re-authentication (roaming) based on e.g. EAP will include a full time consuming RADIUS roundtrip involving STA, AP, and ISP(s). In addition; rerouting of traffic as well as 802.1X functions for port control and crypto session establishment on radio link.

Handover task - time considerations

T1 T2 T3 T4 T5

Handover Starts here

Session continues

here

Session Oriented Security Oriented

< 100 ms

>> 150 ms (!)

Interruption delay

T1: Beacon + Physical connection setup between the STA and the next AP/RGW

T2: Messaging session parameters, including STA’s ID / auth. info between the VU and the next AP/RGW.

T3: Processing of rerouting the traffic to and from STA via the new AP.

T4: AAA roundtrip for re-authentication of the STA between AP/RGW and H-ISP of the STA

T5: 802.1X port handling and TKIP/AES-based encryption of radio link between VU and AP

The high level architecture

VU

RGW 1

Mobility Broker(MB)

CARDServer

RGW 2

MIP

VU

CARDClient

FA

CARDProxy

FA

CARDProxy

MIP

CARDClient

HA (of VU)

ISP of VUInternet

MB: Mobility BrokerRG: Residential GatewayMIP: Mobile IPVU: Visiting UserHA: Home AgentFA: Foreign AgentGFA: Gateway FA

MB: Mobility BrokerRG: Residential GatewayMIP: Mobile IPVU: Visiting UserHA: Home AgentFA: Foreign AgentGFA: Gateway FA

GFA

AAASIP proxy/ registrar

HA

AAA

OBAN service provider

Mobility Broker

• A node serving a geographical area, composed of several RGWs

• Makes the access network look like a conventional WLAN/IP network, such that standard mechanisms can be reused

• Simplify the hand-off complexity, and reduce signaling round trips by managing mobility, security and QoS events locally during hand-off

Fast Handover using Kerberos tickets

Using Kerberos tickets for fast and secure layer 2 authentication

• The ticket consist primarily of an access key and an encrypted timestamp with a key known to the issuer and the final recipient

– Issuer = Mobility Broker

– Final recipient = RGW

• The ticket is issued to the client (user terminal) and encrypted with a key that is in the possession of the client. (shared secret)

– The client uses the ticket for authentication towards the RGW

– Proves that is possesses the session key within the ticket, by encrypting a challenge from the RGW with the session key

– RGW also checks that the timestamp is not expired

Fast Handover using Kerberos tickets

• First time authentication

– No tickets => full authentication towards HAAA. i.e. Anything that generates a session key (e.g. EAP – SIM)

– The final EAP SUCCESS is not proxied to the terminal but exchanged in the Mobility broker with a Ticket-granting Ticket

– The terminal requests MB for a suitable set of tickets.

– EAP SUCCESS is then finally delivered

– The MB is geographically aware.

• Successive re-auth

– Only between terminal and RGW

Fast Handover using Kerberos tickets

• Delay estimation

– Network Authentication + MIP registration = total delay

– Full auth: <120-290ms> + <35-100ms> = <155-390ms>

– Re-auth in same domain: <10-40ms> + <25-45ms> = <35-85ms>

– Re-auth in diff domain: <10-40ms> + <35-100ms> = <45-140ms>

• Standard compliance

– ”the full authentication” does not comply with the EAP requirement regarding sequence of methods.

Delayed Authentication (1) (Patent Pending)

• Open 802.1x for user traffic as fast as possible, and before security functions/authentication are completed.

• Full AAA roundtrip to be executed while ongoing user traffic from STA.

T1 T2 T3 T4 T5

Handover starts here

discontinued session(< 100 ms )

Session continues

here

FullSecurity

established

Continued, but insecure session (a few seconds)

, Secured andaccounted

traffic

< 100 ms

Delayed Authentication (2)

• New / Increased Security risks:

– Unaccounted user traffic for a few seconds

– No encryption on the radio link

– Potential DoS attacks (in addition to those already existing )

• Countermeasures:

– Introduce a timer to limit the maximum pending time for a RADIUS response (success or reject)

– Possible for AP to cache and block MAC addresses with repeated failing attempts

– Policy selector: Monitor accounted vs unaccounted traffic and allow to toggle back to standard 802.11 state machine (ie. standard policy) if unaccounted level is bad. (toggle back after a configurable time)

Consequences

• Introducing a new state: Pending_Authenticated in the IEEE 802.1X State Model

• Must allow for class 3 traffic (both STA and AP)

• Extra robustness functions to minimize the new risks (timer, MAC cache etc)

• Compensation functions also to account for conveyed STA traffic before successful RADIUS response. (STA traffic conveyed before a RADIUS reject (or timer elapse etc) cannot be accounted for).

Authenticated& Associated

AuthenticatedUnAssociated

UnAuthenticatedUnAssociated

Pending_AuthenticatedAssociated

Class 1, 2 & 3frames allowed

SuccessfulAuthentication

DeAuthenticationNotification

Class 1, 2 & 3frames allowed

Class 1& 2 frames allowed

Class 1frames allowed

Possible gain

• Applications with strict real-time requirements can be handled more comfortably also in the mobile case increased popularity & New Business opportunities

• Seamless functionality also delivered with high-speed broadband

– 2G/EDGE: max ~200 Kbit/s,

– 3G/UMTS ~400 Kbit/s,

– 802.11(): 1Mbit/s ++

• Enabling true roaming for 802.11-based access networks