INTERNET-DRAFT Subrata Goswami Expires March 12, 2003 Consultant October 13, 2002 DIAMETER Application for Mobile-IPv4 and 802.11 Authentication Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC 2119]. Abstract This document describes a single way to perform both Mobile-IPv4 and 802.11 authentication and key exchanges. Diameter Mobile-IPv4 Application can be used to consummate message sequences for both 802.11 and Mobile IPv4. It is possible to replace the currently proposed 802.1x Authentication/key-exchange with Diameter Mobile-IPv4 Application. 1. Overview and Rationale In the 802.11 wireless LAN [WiFi] network an 802.11 client connects to an 802.11 Access Point (AP) at the link layer. 802.11 provides a mechanism to achieve handoffs between AP's and the client. A 802.11 client first authenticates and then associates with one AP. When the 802.11 client decides that it is better to move to a second AP, it can do a re-association with the second AP. Similarly when a Mobile-IPv4 (MIP4) client moves from subnet to subnet, it seeks a Foreign Agent (FA) situated in the subnet and registers with the FA. The IP packet sent in Registration Message has the Home IP address as the source, and the destination address can be the FA's IP address or the "All Mobility Agents" multicast address 224.0.0.11. The FA then responds with Registration Reply message. The Registration Message also includes Authentication Extensions. A significant hurdle in deployment of MIPv4 has been the distribution and management of the security association between MN-HA, FA-HA, and MN-FA. Recently a method, Diameter Mobile IP v4 Application (DIMPA), has been suggested by which all these 3 different keys can be generated dynamically from a single shared secret between the MN and a AAA agent [DIMPA]. This DIMPA provides in addition to its core accounting functionality. As mentioned in a previous draft [SIMIP], there is substantial overlap between what 802.11 and MIPv4 do during their respective registration phases. As pointed out in that draft it is possible to nest these operations and thus reduce the number of messages that need to be exchanged between the MN and the infrastructure. The same issues of overlapping work between the 802.11i authentication phase and DIMPA registration arises. The situation of non co-located FA is primarily considered here, although a brief discussion of co-located FA is also provided. Also, we will only consider 802.11 infrastructure mode networks. 2. 802.11 Network Architecture. A hypothetical IP over 802.11 network is shown in the following figure. The mobile client, MN, can move from subnet X1 to X3 and from AP2 to AP3. [FA1]-[AAAF1] | ... [AP1]-------[X1]-| [MN]... | | [AP2]---- |----[X]-----> [HA]---[AAAH] | [AP3/FA3]---[X3]-| | [AAAF3] [MN] - Mobile Node [FA] - Foreign Agent [HA] - Home Agent [AAAH/F] - Home/Foreign AAA Agent [AP] - Access Point [X] - IP Router ... - 802.11 link --- - 802.3 link Figure 1: 802.11 Network with AAA Agents When the MN moves from AP1 to AP2, it first Authenticates with AP2 and then Dissociates with AP1 at the 802.11 link layer. As the move from AP1 to AP2 occurs within the same subnet, hence the MN is still served by the same FA and the same AAAF. When the MN moves from AP2 to AP3 it is served by a different set of FA and AAAF, FA3 and AAAF3 respectively. 3. Message Sequence The following figure shows the what happens when MN moves from AP2 to AP3. During the AP1 to AP2 handoff, the MN is in same subnet, hence MIPv4 registration is not required, although 802.1x key-exchange is required. Figure 2 depicts the messages exchanged between the MN and the infrastructure. Here the AAAF is assumed to be a RADIUS entity in addition to being a DIAMETER [DIM] entity. This particular figure depicts the situation when 802.11 pre-authentication is not done. We will first consider the scenario when 802.11 pre-authentication is not done [WiFiTGi]. Then we will discuss the scenario with pre-authentication. MN AP2 AP3 FA3 AAAF3 AAAH HA <--- 802.11 Data ------> -- 802.1x EAP Start---------------> <- 802.1x EAP Req-Id--------------- -- 802.1x EAP Res-Id--------------> --RADIUS Acc-Req---> -----------> <----------- <-RADIUS Acc-Cha---- <-- 802.1x EAP Req 1-------------- --- 802.1x EAP Res 1-------------> --RADIUS Acc-Req(1)-> <-RADIUS Acc-Res(1)-- . . <-RADIUS Acc-Acp/Rej-- <--802.1x EAP Suc/Fal------------- <--802.1x Install Keys------------ -- 802.1x Key Install status-----> ---802.1x EAPOL Key Msg ---------> (w/ nonce1) <---802.1x EAPOL Key Msg --------- (w/ nonce2 and MIC) ----802.1x EAPOL Key Msg --------> (w/ nonce1 and MIC, Install) <---802.1x EAPOL Key Msg --------- (w/ nonce2 and MIC, Install) -- 802.11 Dissoc-Req----> ----- MIPv4 Reg-Req w/MN-AAA -----------> --AAA AMR-> Session-Id=sid1 --AAA AMR-> sid1 ---HAR------> sid1 <--HAA------- sid1 <---AAA AMA- sid1 <-AAA AMA- sid1 <---- MIPv4 Reg-Res--------------------- Figure 2. 802.11 and MIPv4 message sequences in series. As can be seen in Figure 2, the 802.11 link layer key-exchange is done through the 4-way handshake is implemented using EAPOL-Key messages [TGi] after the authentication. "The 4-way handshake confirms the liveness of the STAs communicating directly with each other over the 802.1l link, guarantees the freshness of the their shared session key, and synchronizes the usage of the key to secure the 802.11 link" [TGi]. 4. When 802.11 Pre-authentication is not used On the surface it looks as if the 802.1x based authentication/key-exchange and DMIPA share a number of common messages. Both message sequences do authentication ?f the MN first and then do key exchanges. So it should be possible to combine both of them into a single message sequence. In a previous draft [SIMIP], it was suggested MIPv4 registration messages can be carried as Information Elements (IE) in 802.11 Association/Reassociation frames. Here the same IE's can be used. DIMPA provides an Attribute Value Pair (AVP) called the MIP-MN-AAA-Auth AVP, which identifies the MN's security association with the Home AAA agent (AAAH). The MIP-MN-AAA-Auth AVP is constructed from the MIPv4 Registration Request containing the Mobile IP Authentication extension with the MN-AAA Authentication subtype [MIPCR,DMIPA]. DIMPA constructs all the MIPv4 keys and distribute them. So it is a simple incremental task for DIMPA to generate one more key (RC4 40 or 104 bit for TKIP [WiFiTGi]) to share between MN an AP. The following figure, Figure 3., shows a message sequence for using DIMPA for both 802.11 and MIPv4 authentication and key-exchange. MN AP2 AP3 FA3 AAAF3 AAAH HA <--- 802.11 Data ------> ----- 802.11 Associate with-------> (MIPv4 Reg-Req w/MN-AAA) ----------> MIPv4 Reg-Req w/MN-AAA --AAA AMR-> Session-Id=sid1 --AAA AMR-> sid1 --HAR----> sid1 <-HAA----- sid1 <---AAA AMA- sid1 <-AAA AMA- sid1 <--------- MIPv4 Reg-Res w/MIPv4 Auth Extensions <---- MIPv4 Reg-Res--------------------- (MIPv4 Reg-Req w/MIPv4 Auth Extensions) Figure 3. DIMPA based combined 802.11/Mobile-IP authentication 5. When 802.11 Pre-authentication is used In 802.11 pre-authentication is used for fast handoff, here the MN collects a list of all the AP's it can hear from, through beacon frames or through probe response frames, and the authenticates with a number of them without associating with any [PREAUTH]. After association, the AP starts forwarding frames for the MN. Pre-authentiation is handled through pre-registration in MIPv4, which is described in section 5.3. A MIPv4 Pre-Registration Request/Reply is same as MIPv4 Registration Request/Reply with the following differences, contains a new MIPv4 extension called the Pre-Reg Extension which is followed by the MN-HA Authentication Extension. 5.1 The Pre-Reg Extension A new Mobile IP extension, called the Pre-Reg Extension, is defined to indicate to the FA/HA/AAF/AAH that this registration is only for key-exchange, the HA and FA MUST not re-route traffic if the Pre-Reg Extension is present. The following figure shows the Pre-Reg Extension, it is a MIPv4 Long Extension. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Subtype | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Number of Items | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | List of Items | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: The Pre-Reg Extension Type ? TBD (non skippable) Subtype A number assigned to identify the way in which the List of Items is to be used by the mobility and AAA agents. Length The 16-bit Length field indicates the length of the extension in bytes. It is equal to the number of bytes in the Authenticator, List of Items plus 4 (for the Number of Items field). Number of Items The number of items in List of Items. List of Items The List of Items contains a list of items (e.g. IP Address) Subtype 0: In Pre-Registration Request a Pre-Reg contains a list of FA IP addresses with which the MN as all ready pre-registered. In a Pre-Registration Reply, the Pre-Reg MUST contain only the IP address of the FA. An MN-HA Authentication Extension MUST follow this extension. Subtype 1: In a Registration Request the presence of this extension indicates to the FA that the MN has all ready Pre-Registered. An MN-FA Authentication Extension MUST follow this extension. Subtype 2-255 are reserved. 5.2 The MIP-Pre-Reg AAA AVP A corresponding AAA AVP is defined that carries the Pre-Reg Extension in AMR/AMA and HAR/HAA. The following figure shows the Pre-Reg AVP. The AVP Code is 1001 (tentative) and the value is the MIP Pre-Reg extension. 5.3 Message Sequence The messages sequence for pre-authentication is shown in Figure 4, which is same as Figure 3 except that the MIPv4 IE in the 802.11 Association Request/Reply does not contain a MN-HA Key Request/Response Extension. Several pre-registration may precede a registration. MN AP2 AP3 FA3 AAAF3 AAAH HA <--- 802.11 Data ------> --- 802.11 Pre-Auth Req with------> (MIPv4 Pre-Reg-Req w/MN-AAA+Pre-Reg Subtype 0) ----------> MIPv4 Pre-Reg-Req w/MN-AAA --AAA AMR-> Session-Id=sid1 --AAA AMR-> sid1 --HAR----> sid1 <----------> (Key exchange*) <-HAA----- sid1 <---AAA AMA- sid1, MN-HA+MN-FA+HA-FA+MN-AP Key AVP <-AAA AMA- sid1, MN-HA+MN-FA+HA-FA+MN-AP Key AVP <-------- MIPv4 Pre-Reg-Res MN-HA+MN-FA+HA-FA+MN-AP MIPv4 Auth Extension | Install MN-AP key in AP <---- MIPv4 Pre-Auth-Res------------- (MIPv4 IE Pre-Reg-Res w/+Pre-Reg Subtype 0) (MN-HA+MN-FA+HA-FA+MN-AP MIPv4 Auth Extension in IE) . . ----- 802.11 Associate with-------> (MIPv4 Reg-Req w/MN-FA and Pre-Reg Subtype 1) Figure 4. DIMPA based combined 802.11/Mobile-IP pre-auth/pre-reg The Key AVP's are secured by the MN-AAA security credential. The HA,FA, and AP gets their copy of the session key through IPSec or TLS or CMS secured connections [CMS,DIM]. IPSec and TLS are manually configured, hence are not very scalable. Cryptographic Message Syntax (CMS), is the method used to secure MIME (S/MIME) messages. CMS was designed to allow Diameter implementations to use existing S/MIME tools and thu? . How the keys are exactly distributed would provided in a later version of this draft. 6. New IE, AVP, Mobile IP Extensions. 6.1 New Information Elements in 802.11 Management Frames No new IE is required except those mentioned in [SIMIP]. 6.2 New Diameter AVP's 6.2.1 MIP-MN-to-AP-Key AVP A new Diameter AVP is defined for the AP-to-MN key, MIP-MN-to-AP Key. The MIP-MN-to-AP-Key AVP (AVP Code 1002) is of type Grouped, and contains the mobile node's key material, which it uses to derive the session key it shares with the AP. The home agent uses this AVP in the construction of the Mobile IP "Unsolicited MN-FA Key from AAA Subtype" extension [MIPKEYS]. The SPI in the extension's FA SPI field is allocated by the home agent, but it SHOULD take into consideration the SPI requested by the mobile node in the "MN-FA Key Request From AAA Subtype" extension. MIP-MN-to-AP-Key ::= < AVP Header: 1002 > { 80211-Algorithm-Type } { 80211-Key-Material } { 80211-MN-AAA-SPI } * [ AVP ] 6.2.2 MIP-Pre-Reg AVP Another new AVP, MIP-Pre-Reg, as mentioned in section 5.2 is also defined. 6.3 Mobile IP Extensions A new MIPv4 extension, Pre-Reg Extension, is required as defined in section 5.1. Another new MIPv4 Authentication Extension is required for transporting the MN-AP key to the AP from the FA. 7. Mobile Entity Implications There are some implications for the different mobile entities involved. 7.1 Implications for MN (STA) The MN should be capable of passing the MIPv4 information to the 802.11 driver and vice-versa. At the instant the MN is ready to send an Association Request it should be able to access the MN's Mobile-IPv4 attributes. Similarly, when the MN receives an Association Response there should be a mechanism to change the Mobile-IPv4 attributes in MN. The MN (or the 802.11 STA) should be provide a new Authentication Suite called DMIPA in the Robust Security Network (RSN) Information Element in the TGi spcification. Tentatively a value of 3 is assigned to it. 7.2 Implications for 802.11 AP The 802.11 AP should be able to extract/include the MIPv4-802.11 IE's. 7.3 Implications for FA To be added 7.4 Implications for AAAH To be added 7.5 Implications for AAAF To be added 8. Co-located FA To be added. 9. Miscellaneous To be added 10. Acknowledgments All the RFC's, ID's, freely available 802.11 standards. Dr. Bernard Aboba for many useful pointers and Mr. Aditya Agarwal for several discussions. 11. References [WiFi] IEEE, "Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications", 1999. [MIPv4] Perkins, C., "IP Mobility Support", RFC 3220, January 2002. [WiFiTGi] IEEE, "802.11i Draft 2.3", 2002. [DIM] Calhoun, P et. al., "Diameter Base Protocol", draft-ietf-aaa-diameter-12.txt, July 2002. [DMIPA] Calhoun, P. et. al., "Diameter Mobile IPv4 Application", draft-ietf-aaa-diameter-mobileip-12.txt, August 2002. [SIMIP] Goswami,S., "Simultaneous Handoff of 802.11 and Mobile IPv4", draft-goswami-mobileip-simultaneous-handoff-v4-01.txt, September 2002. [MIPCR] Perkins,C., et.al., "Mobile IPv4 Challenge/Response Extensions", November 2000. [PREAUTH] Aboba, B, "IEEE 802.1x Pre-authentication", IEEE 802.11-02/389r0, June 2002. [CMS] Calhoun,P. et. al., "Diameter CMS Security Application", draft-ietf-aaa-diameter-cms-sec-05.txt, April 2002. 8. Author's Address Subrata Goswami, Ph.D. Consultant Newark, CA 94560 sgoswami@umich.edu This document expires March 12, 2003.