The OBAN project and issues for standardisation

1. The OBAN project and issues for standardisation

2. 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)

3. 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.

4. 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.

5. 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

6. 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

7. 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.

8. T T T T T 1 2 3 4 5 Handover task - time considerations Session Handover continues Starts here here Interruption delay Session Oriented Security Oriented < 100 ms >> 150 ms (!) 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

9. The high level architecture Internet ISP of VU HA (of VU) AAA AAA SIP proxy/ registrar CARD Server MB: Mobility BrokerRG: Residential GatewayMIP: Mobile IPVU: Visiting UserHA: Home AgentFA: Foreign AgentGFA: Gateway FA Mobility Broker (MB) HA GFA OBAN service provider RGW 2 RGW 1 FA FA CARD Proxy CARD Proxy MIP MIP CARD Client CARD Client VU VU

10. 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

11. 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

12. 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

13. 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.

14. 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. T T T T T 1 2 3 4 5 Session Handover continues starts here here Secured and Continued, but insecure session (a few seconds) discontinued session , accounted (< 100 ms ) traffic < 100 ms Full Security established

15. 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)

16. Authenticated & Associated Authenticated UnAssociated UnAuthenticated UnAssociated Pending_Authenticated Associated 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). Successful Authentication Class 1, 2 & 3 frames allowed Class 1, 2 & 3 frames allowed Class 1& 2 frames allowed DeAuthentication Notification Class 1 frames allowed

17. 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