INTERNET-DRAFT Subrata Goswami Expires February 26, 2003 Independent Consultant Sept 27, 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 consumate message sequences for both 802.11 and Mobile IPv4. If 802.11 pre-authentication is not done then 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 distributon 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 possile to nest these operations and thus reduce the number of messages that need to be exchnaged between the MN and the infrastructre. 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 discussion of co-located FA is also provided. Here 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 depits 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.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. 4. No 802.11 Pre-authentication On the surface it looks like the 802.1x based authentication/key-exchange and DMIPA share a number of common messages. Both message sequences do authentication of 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. With 802.11 Pre-authentication To be added. 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 A new Diameter AVP is defined for the AP-to-MN key, MIP-AP-to-MN Key. 6.3 Mobile IP Extensions No new Mobiel IP Extension is required, but a new sub-type, MN-AP Authentication sub-type is defined. 7. Mobile Entity Implications There are some implications for the different mobile entities involved. 7.1 Implications for MN 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. 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. Miscellanious To be added 10. Acknowledgments All the RFC's, IDĖs, freely available 802.11 standards, and Linux web-sites. Dr. Bernard Aboba for many useful pointers. Also apologize for submitting a hastily prepared draft. 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. 8. Author's Address Subrata Goswami, Ph.D. Independent Consultant Newark, CA 94560 sgoswami@umich.edu This document expires February 25, 2003.