Adaptation of Existing Mobile IP Authentication for use in IEEE 802.11 Systems

1. Adaptation of Existing Mobile IP Authentication for use in IEEE 802.11 Systems Submitted to IEEE 802.11 TGi July 2001 L. Salgarelli, M. Buddhikot, S. Miller , Lucent Technologies D. Stanley Agere Systems Luca Salgarelli, Bell Labs, Lucent Technologies

2. Motivation • Wireless Data Service providers are interested in deploying both 802.11 and Cellular data networks • Key driver – Single AAA infrastructure • Show an approach to adapt Mobile IP authentication to 802.11i EAP framework • This enables single AAA infrastructure for these applications • Similar EAP extensions exist in • GSM SIM Authentication in IEEE 802.11 System - Submission to Task Group ‘e’, January 2001, H. Haverinen, J.P. Edney, Nokia, IEEE 802.11-01/039 • J. Arkko, H. Haverinen, “EAP AKA Authentication”, draft-arkko-pppext-eap-aka-00.txt, May 2001 • H. Haverinen, “EAP SIM Authentication, draft-haverinen-pppext-eap-sim-01.txt • Expect to publish as an Internet Draft. Luca Salgarelli, Bell Labs, Lucent Technologies

3. User Information • Pre-configured network access identifier (NAI) • A pre-configured security association with the Local AAA server or Home AAA server (H-AAA) • Mobile IP uses an MD5 prefix-suffix with a 128bit key, which is a cryptographically strong authentication algorithm Luca Salgarelli, Bell Labs, Lucent Technologies

4. Local Authentication Example MN=Mobile Node Kmn-laaa = Pre-established security association In Mobile IP – Pre shared 128 bit Cryptographic Key Luca Salgarelli, Bell Labs, Lucent Technologies

5. EAP Message Exchange Luca Salgarelli, Bell Labs, Lucent Technologies

6. User Authentication • EAP Authentication assuming a pre-shared cryptographically strong key could be used in an 802.11 network. • For a mobile IP/roaming situation, authenticate to the Home AAA, get session key for the AP, then Mobile IP UDP messages can be passed. Can be made seamless for the end user. • EAP framework can adapt to include future IETF Mobile IP changes. Luca Salgarelli, Bell Labs, Lucent Technologies

7. Local & Remote AAA Authentication at Home AAA, via local AAA Luca Salgarelli, Bell Labs, Lucent Technologies

8. EAP Message Exchange Luca Salgarelli, Bell Labs, Lucent Technologies

9. EAP Message Description • 1.       802.11 Association • 2.       EAP Authentication - The AP issues a EAP request frame (Figure 4 - Step 1) with [Code=1, Identifier=X, Type= Identity, OptionalMsg=“Please Enter Your NAI”]. This frame is encapsulated using the 802.1x frame format. The packet is handed over to the EAP software stack on the MN, The MN responds with a EAP response [Code=2,Identifier=X,Type=NAI (Figure 4 - Step 2). • 3.       AP presents the MD5-challenge: The AP issues a EAP request frame with [Code=1, Identifier=Y, Type= 4 (MD5-Challenge), Type-Data=[Value-Size= 238, Value= CHSTR (Challenge string with 238 bytes), Name= ``String identifying AP”] (Figure 4 - Step 3). • 4.       The MN computes the Authenticator using MD5 as follows:Authenticator = MD5(High order byte from challenge | KMN-HAAA | least-order 237 bytes of challenge).It sends back a EAP response packet Resp = [Code=2, Identifier=Y, Type= 4 (MD5-Challenge), Type-Data=[Value-Size= 16, Value= Authenticator, Name=``String identifying MN”] (Figure - Step 4).  • 5.       Forward challenge response to H-AAA server: Each AP runs a RADIUS client and maintains a security association with a local AAA server L-AAA. When MN response is received, the AP removes the 802.1x encapsulation and generates a RADIUS access-request with [User-Name=NAI, CHAP-Password=High-order byte from challenge followed by Authenticator, CHAP-Challenge=least order 237 bytes from challenge], and sends the access-request to L-AAA (Figure 2 - Step 5).  Luca Salgarelli, Bell Labs, Lucent Technologies

10. EAP Message Description - 2 • 6. The L-AAA server resolves the user NAI to an authoritative H-AAA server using a local database or a network resident LDAP server. It then uses the RADIUS protocol to forward the access-request to the H-AAA server (Figure 4 - Step 6). • 7. Processing at H-AAA: On receipt of the access-request, the H-AAA server looks up the KMN-HAAA key for the user ‘NAI’ and uses it to verify the access-request, by following the standard EAP-MD5 procedure, calculating the Authenticator as explained in item 5 above. In case of failed authentication the H-AAA server relays the failure message to L-AAA, which will forward it to the RADIUS client in the AP. The AP eventually sends a EAP Failure response packet [Code=4, Identifier=y] to MN. If the authentication succeeds, the H-AAA undertakes following steps: (1) Allocate a large (64-bit) random number R. (2) Compute a 128 bit key KMN-AP as follows:KMN-AP = MD5(KMN-HAAA | R | NAI | KMN-HAAA). (3) Forward (KMN-AP, R) to L-AAA in a RADIUS access-response (Figure 4 - Step 7). • 8. Processing response at AP: The L-AAA forwards the response to the RADIUS client on AP (Figure 4 - Step 8). The AP extracts the KMN-AP key allocated for the MN and sends an EAP response packet [Code=2, Identifier=Z, Type= Notification, Msg=“Random number R”] to MN (Figure 4 - Step 9). The MN uses R and KMN-HAAA to generate KMN-AP following the exact same procedure used at H-AAA server. The AP in the end sends a [Code=4 Identifier=A] success message to MN to signify the authentication is successfully completed (Figure 4 - Step 10). Luca Salgarelli, Bell Labs, Lucent Technologies

11. For Further Info Contact • L. Salgarelli (Primary Contact) salga@dnrc.bell-labs.com • M. Buddhikot, S. MillerBell Laboratories {salga, milind, scm} @dnrc.bell-labs.com • P. Feder, R. ShapiraWNG – Lucent Technologies{pfeder, rshapira}@lucent.com Luca Salgarelli, Bell Labs, Lucent Technologies