idnits 2.17.1 draft-goswami-aaa-mipv4-wlan-auth-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 541 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 73 instances of too long lines in the document, the longest one being 12 characters in excess of 72. ** There are 16 instances of lines with control characters in the document. == There are 1 instance of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 49 has weird spacing: '...ciation with ...' == Line 54 has weird spacing: '...and the desti...' == Line 66 has weird spacing: '...between what ...' == Line 110 has weird spacing: '... figure shows...' == Line 114 has weird spacing: '...assumed to be...' == (3 more instances...) == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: 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. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 13, 2002) is 7860 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC 2119' is mentioned on line 32, but not defined == Missing Reference: 'DIMPA' is mentioned on line 62, but not defined == Missing Reference: 'MN' is mentioned on line 91, but not defined == Missing Reference: 'AAAF3' is mentioned on line 89, but not defined == Missing Reference: 'FA' is mentioned on line 92, but not defined == Missing Reference: 'HA' is mentioned on line 93, but not defined == Missing Reference: 'AP' is mentioned on line 95, but not defined == Missing Reference: 'X' is mentioned on line 96, but not defined == Missing Reference: 'TGi' is mentioned on line 201, but not defined == Missing Reference: 'MIPKEYS' is mentioned on line 403, but not defined == Unused Reference: 'MIPv4' is defined on line 474, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'WiFi' ** Obsolete normative reference: RFC 3220 (ref. 'MIPv4') (Obsoleted by RFC 3344) -- Possible downref: Non-RFC (?) normative reference: ref. 'WiFiTGi' == Outdated reference: A later version (-16) exists of draft-ietf-aaa-diameter-12 == Outdated reference: A later version (-20) exists of draft-ietf-aaa-diameter-mobileip-12 == Outdated reference: A later version (-02) exists of draft-goswami-mobileip-simultaneous-handoff-v4-01 -- Possible downref: Normative reference to a draft: ref. 'SIMIP' -- Possible downref: Non-RFC (?) normative reference: ref. 'MIPCR' -- Possible downref: Non-RFC (?) normative reference: ref. 'PREAUTH' -- Unexpected draft version: The latest known version of draft-ietf-aaa-diameter-cms-sec is -04, but you're referring to -05. -- Possible downref: Normative reference to a draft: ref. 'CMS' Summary: 8 errors (**), 0 flaws (~~), 24 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Subrata Goswami 3 Expires March 12, 2003 Consultant 4 October 13, 2002 6 DIAMETER Application for Mobile-IPv4 and 802.11 Authentication 7 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with all 12 provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering Task 15 Force (IETF), its areas, and its working groups. Note that other groups 16 may also distribute working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet- Drafts as reference material 21 or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 30 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 31 document are to be interpreted as described in RFC 2119 [RFC 2119]. 33 Abstract 35 This document describes a single way to perform both Mobile-IPv4 36 and 802.11 authentication and key exchanges. Diameter Mobile-IPv4 37 Application can be used to consummate message sequences for both 38 802.11 and Mobile IPv4. It is possible to replace the currently 39 proposed 802.1x Authentication/key-exchange with Diameter 40 Mobile-IPv4 Application. 42 1. Overview and Rationale 44 In the 802.11 wireless LAN [WiFi] network an 802.11 client connects to an 45 802.11 Access Point (AP) at the link layer. 802.11 provides a mechanism to 46 achieve handoffs between AP's and the client. A 802.11 client first 47 authenticates and then associates with one AP. When the 802.11 client 48 decides that it is better to move to a second AP, it can do a 49 re-association with the second AP. 51 Similarly when a Mobile-IPv4 (MIP4) client moves from subnet to subnet, it 52 seeks a Foreign Agent (FA) situated in the subnet and registers with the FA. 53 The IP packet sent in Registration Message has the Home IP address as the 54 source, and the destination address can be the FA's IP address or the "All 55 Mobility Agents" multicast address 224.0.0.11. The FA then responds with 56 Registration Reply message. The Registration Message also includes 57 Authentication Extensions. A significant hurdle in deployment of MIPv4 has 58 been the distribution and management of the security association between MN-HA, 59 FA-HA, and MN-FA. Recently a method, Diameter Mobile IP v4 Application 60 (DIMPA), has been suggested by which all these 3 different keys can be 61 generated dynamically from a single shared secret between the MN and a 62 AAA agent [DIMPA]. This DIMPA provides in addition to its core 63 accounting functionality. 65 As mentioned in a previous draft [SIMIP], there is substantial overlap 66 between what 802.11 and MIPv4 do during their respective registration 67 phases. As pointed out in that draft it is possible to nest these operations 68 and thus reduce the number of messages that need to be exchanged between 69 the MN and the infrastructure. The same issues of overlapping work between 70 the 802.11i authentication phase and DIMPA registration arises. 72 The situation of non co-located FA is primarily considered here, although a 73 brief discussion of co-located FA is also provided. Also, we will only 74 consider 802.11 infrastructure mode networks. 76 2. 802.11 Network Architecture. 78 A hypothetical IP over 802.11 network is shown in the following figure. 79 The mobile client, MN, can move from subnet X1 to X3 and from AP2 to AP3. 81 [FA1]-[AAAF1] 82 | 83 ... [AP1]-------[X1]-| 84 [MN]... | | 85 [AP2]---- |----[X]-----> [HA]---[AAAH] 86 | 87 [AP3/FA3]---[X3]-| 88 | 89 [AAAF3] 91 [MN] - Mobile Node 92 [FA] - Foreign Agent 93 [HA] - Home Agent 94 [AAAH/F] - Home/Foreign AAA Agent 95 [AP] - Access Point 96 [X] - IP Router 97 ... - 802.11 link 98 --- - 802.3 link 100 Figure 1: 802.11 Network with AAA Agents 102 When the MN moves from AP1 to AP2, it first Authenticates with AP2 and then 103 Dissociates with AP1 at the 802.11 link layer. As the move from AP1 to AP2 104 occurs within the same subnet, hence the MN is still served by the same FA 105 and the same AAAF. When the MN moves from AP2 to AP3 it is served by a 106 different set of FA and AAAF, FA3 and AAAF3 respectively. 108 3. Message Sequence 110 The following figure shows the what happens when MN moves from AP2 to 111 AP3. During the AP1 to AP2 handoff, the MN is in same subnet, hence MIPv4 112 registration is not required, although 802.1x key-exchange is required. 113 Figure 2 depicts the messages exchanged between the MN and the infrastructure. 114 Here the AAAF is assumed to be a RADIUS entity in addition to being a 115 DIAMETER [DIM] entity. This particular figure depicts the situation 116 when 802.11 pre-authentication is not done. 118 We will first consider the scenario when 802.11 pre-authentication is 119 not done [WiFiTGi]. Then we will discuss the scenario with 120 pre-authentication. 122 MN AP2 AP3 FA3 AAAF3 AAAH HA 124 <--- 802.11 Data ------> 126 -- 802.1x EAP Start---------------> 128 <- 802.1x EAP Req-Id--------------- 130 -- 802.1x EAP Res-Id--------------> 132 --RADIUS Acc-Req---> 134 -----------> 136 <----------- 138 <-RADIUS Acc-Cha---- 140 <-- 802.1x EAP Req 1-------------- 142 --- 802.1x EAP Res 1-------------> 144 --RADIUS Acc-Req(1)-> 146 <-RADIUS Acc-Res(1)-- 147 . 148 . 150 <-RADIUS Acc-Acp/Rej-- 152 <--802.1x EAP Suc/Fal------------- 154 <--802.1x Install Keys------------ 156 -- 802.1x Key Install status-----> 158 ---802.1x EAPOL Key Msg ---------> 159 (w/ nonce1) 161 <---802.1x EAPOL Key Msg --------- 162 (w/ nonce2 and MIC) 164 ----802.1x EAPOL Key Msg --------> 165 (w/ nonce1 and MIC, Install) 167 <---802.1x EAPOL Key Msg --------- 168 (w/ nonce2 and MIC, Install) 170 -- 802.11 Dissoc-Req----> 172 ----- MIPv4 Reg-Req w/MN-AAA -----------> 174 --AAA AMR-> 175 Session-Id=sid1 177 --AAA AMR-> 178 sid1 180 ---HAR------> 181 sid1 183 <--HAA------- 184 sid1 186 <---AAA AMA- 187 sid1 189 <-AAA AMA- 190 sid1 192 <---- MIPv4 Reg-Res--------------------- 194 Figure 2. 802.11 and MIPv4 message sequences in series. 196 As can be seen in Figure 2, the 802.11 link layer key-exchange is done 197 through the 4-way handshake is implemented using EAPOL-Key messages [TGi] after 198 the authentication. "The 4-way handshake confirms the liveness of the STAs 199 communicating directly with each other over the 802.1l link, guarantees the 200 freshness of the their shared session key, and synchronizes the usage of the 201 key to secure the 802.11 link" [TGi]. 203 4. When 802.11 Pre-authentication is not used 205 On the surface it looks as if the 802.1x based authentication/key-exchange 206 and DMIPA share a number of common messages. Both message sequences 207 do authentication ?f the MN first and then do key exchanges. So it should 208 be possible to combine both of them into a single message sequence. In a 209 previous draft [SIMIP], it was suggested MIPv4 registration messages can be 210 carried as Information Elements (IE) in 802.11 Association/Reassociation frames. 211 Here the same IE's can be used. DIMPA provides an Attribute Value Pair (AVP) 212 called the MIP-MN-AAA-Auth AVP, which identifies the MN's security association 213 with the Home AAA agent (AAAH). The MIP-MN-AAA-Auth AVP is constructed 214 from the MIPv4 Registration Request containing the Mobile IP Authentication 215 extension with the MN-AAA Authentication subtype [MIPCR,DMIPA]. DIMPA constructs 216 all the MIPv4 keys and distribute them. So it is a simple incremental task for 217 DIMPA to generate one more key (RC4 40 or 104 bit for TKIP [WiFiTGi]) to share 218 between MN an AP. The following figure, Figure 3., shows a message sequence 219 for using DIMPA for both 802.11 and MIPv4 authentication and key-exchange. 221 MN AP2 AP3 FA3 AAAF3 AAAH HA 223 <--- 802.11 Data ------> 225 ----- 802.11 Associate with-------> 226 (MIPv4 Reg-Req w/MN-AAA) 228 ----------> MIPv4 Reg-Req w/MN-AAA 230 --AAA AMR-> 231 Session-Id=sid1 233 --AAA AMR-> 234 sid1 236 --HAR----> 237 sid1 239 <-HAA----- 240 sid1 242 <---AAA AMA- 243 sid1 245 <-AAA AMA- 246 sid1 248 <--------- MIPv4 Reg-Res w/MIPv4 Auth Extensions 250 <---- MIPv4 Reg-Res--------------------- 251 (MIPv4 Reg-Req w/MIPv4 Auth Extensions) 253 Figure 3. DIMPA based combined 802.11/Mobile-IP authentication 255 5. When 802.11 Pre-authentication is used 257 In 802.11 pre-authentication is used for fast handoff, here the MN collects 258 a list of all the AP's it can hear from, through beacon frames or through 259 probe response frames, and the authenticates with a number of them without 260 associating with any [PREAUTH]. After association, the AP starts forwarding 261 frames for the MN. 263 Pre-authentiation is handled through pre-registration in MIPv4, which is 264 described in section 5.3. A MIPv4 Pre-Registration Request/Reply is same 265 as MIPv4 Registration Request/Reply with the following differences, contains 266 a new MIPv4 extension called the Pre-Reg Extension which is followed by the 267 MN-HA Authentication Extension. 269 5.1 The Pre-Reg Extension 271 A new Mobile IP extension, called the Pre-Reg Extension, 272 is defined to indicate to the FA/HA/AAF/AAH that this registration is only for 273 key-exchange, the HA and FA MUST not re-route traffic if the Pre-Reg 274 Extension is present. The following figure shows the Pre-Reg 275 Extension, it is a MIPv4 Long Extension. 277 0 1 2 3 278 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 279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 280 | Type | Subtype | Length | 281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 282 | Number of Items | 283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 284 | List of Items | 285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 287 Figure 4: The Pre-Reg Extension 289 Type ? TBD (non skippable) 291 Subtype A number assigned to identify the way in 292 which the List of Items is to be used by the 293 mobility and AAA agents. 295 Length The 16-bit Length field indicates the length of 296 the extension in bytes. It is equal to the number 297 of bytes in the Authenticator, List of Items plus 298 4 (for the Number of Items field). 300 Number of Items The number of items in List of Items. 302 List of Items The List of Items contains a list of items 303 (e.g. IP Address) 305 Subtype 0: 306 In Pre-Registration Request a Pre-Reg contains a list of FA IP 307 addresses with which the MN as all ready pre-registered. In a Pre-Registration 308 Reply, the Pre-Reg MUST contain only the IP address of the FA. 310 An MN-HA Authentication Extension MUST follow this extension. 312 Subtype 1: 313 In a Registration Request the presence of this extension indicates to the 314 FA that the MN has all ready Pre-Registered. 316 An MN-FA Authentication Extension MUST follow this extension. 318 Subtype 2-255 are reserved. 320 5.2 The MIP-Pre-Reg AAA AVP 322 A corresponding AAA AVP is defined that carries the Pre-Reg 323 Extension in AMR/AMA and HAR/HAA. The following figure shows the Pre-Reg 324 AVP. The AVP Code is 1001 (tentative) and the value is the MIP Pre-Reg 325 extension. 327 5.3 Message Sequence 329 The messages sequence for pre-authentication is shown in Figure 4, which is 330 same as Figure 3 except that the MIPv4 IE in the 802.11 Association Request/Reply 331 does not contain a MN-HA Key Request/Response Extension. Several pre-registration 332 may precede a registration. 334 MN AP2 AP3 FA3 AAAF3 AAAH HA 336 <--- 802.11 Data ------> 338 --- 802.11 Pre-Auth Req with------> 339 (MIPv4 Pre-Reg-Req w/MN-AAA+Pre-Reg Subtype 0) 341 ----------> MIPv4 Pre-Reg-Req w/MN-AAA 343 --AAA AMR-> 344 Session-Id=sid1 346 --AAA AMR-> 347 sid1 348 --HAR----> 349 sid1 351 <----------> 352 (Key exchange*) 354 <-HAA----- 355 sid1 357 <---AAA AMA- 358 sid1, MN-HA+MN-FA+HA-FA+MN-AP Key AVP 360 <-AAA AMA- 361 sid1, MN-HA+MN-FA+HA-FA+MN-AP Key AVP 363 <-------- MIPv4 Pre-Reg-Res 364 MN-HA+MN-FA+HA-FA+MN-AP MIPv4 Auth Extension 366 | Install MN-AP key in AP 368 <---- MIPv4 Pre-Auth-Res------------- 369 (MIPv4 IE Pre-Reg-Res w/+Pre-Reg Subtype 0) 370 (MN-HA+MN-FA+HA-FA+MN-AP MIPv4 Auth Extension in IE) 371 . 372 . 373 ----- 802.11 Associate with-------> 374 (MIPv4 Reg-Req w/MN-FA and Pre-Reg Subtype 1) 376 Figure 4. DIMPA based combined 802.11/Mobile-IP pre-auth/pre-reg 378 The Key AVP's are secured by the MN-AAA security credential. The HA,FA, and AP 379 gets their copy of the session key through IPSec or TLS or CMS secured 380 connections [CMS,DIM]. IPSec and TLS are manually configured, hence are not 381 very scalable. Cryptographic Message Syntax (CMS), is the method used to 382 secure MIME (S/MIME) messages. CMS was designed to allow Diameter 383 implementations to use existing S/MIME tools and thu? . 385 How the keys are exactly distributed would provided in a later version of this 386 draft. 388 6. New IE, AVP, Mobile IP Extensions. 390 6.1 New Information Elements in 802.11 Management Frames 392 No new IE is required except those mentioned in [SIMIP]. 394 6.2 New Diameter AVP's 396 6.2.1 MIP-MN-to-AP-Key AVP 398 A new Diameter AVP is defined for the AP-to-MN key, MIP-MN-to-AP Key. 399 The MIP-MN-to-AP-Key AVP (AVP Code 1002) is of type Grouped, and 400 contains the mobile node's key material, which it uses to derive the 401 session key it shares with the AP. The home agent uses 402 this AVP in the construction of the Mobile IP "Unsolicited MN-FA Key 403 from AAA Subtype" extension [MIPKEYS]. The SPI in the extension's FA 404 SPI field is allocated by the home agent, but it SHOULD take into 405 consideration the SPI requested by the mobile node in the "MN-FA Key 406 Request From AAA Subtype" extension. 408 MIP-MN-to-AP-Key ::= < AVP Header: 1002 > 409 { 80211-Algorithm-Type } 410 { 80211-Key-Material } 411 { 80211-MN-AAA-SPI } 412 * [ AVP ] 414 6.2.2 MIP-Pre-Reg AVP 415 Another new AVP, MIP-Pre-Reg, as mentioned in section 5.2 is also defined. 417 6.3 Mobile IP Extensions 419 A new MIPv4 extension, Pre-Reg Extension, is required as defined in section 5.1. 421 Another new MIPv4 Authentication Extension is required for transporting the 422 MN-AP key to the AP from the FA. 424 7. Mobile Entity Implications 426 There are some implications for the different mobile entities involved. 428 7.1 Implications for MN (STA) 430 The MN should be capable of passing the MIPv4 information to the 802.11 431 driver and vice-versa. At the instant the MN is ready to send an 432 Association Request it should be able to access the MN's Mobile-IPv4 433 attributes. Similarly, when the MN receives an Association Response there 434 should be a mechanism to change the Mobile-IPv4 attributes in MN. 436 The MN (or the 802.11 STA) should be provide a new Authentication Suite 437 called DMIPA in the Robust Security Network (RSN) Information Element in 438 the TGi spcification. Tentatively a value of 3 is assigned to it. 440 7.2 Implications for 802.11 AP 442 The 802.11 AP should be able to extract/include the MIPv4-802.11 IE's. 444 7.3 Implications for FA 446 To be added 448 7.4 Implications for AAAH 450 To be added 452 7.5 Implications for AAAF 454 To be added 456 8. Co-located FA 458 To be added. 460 9. Miscellaneous 462 To be added 464 10. Acknowledgments 466 All the RFC's, ID's, freely available 802.11 standards. Dr. Bernard Aboba for 467 many useful pointers and Mr. Aditya Agarwal for several discussions. 469 11. References 471 [WiFi] IEEE, "Part 11: Wireless LAN Medium Access Control (MAC) and 472 Physical Layer (PHY) Specifications", 1999. 474 [MIPv4] Perkins, C., "IP Mobility Support", RFC 3220, January 2002. 476 [WiFiTGi] IEEE, "802.11i Draft 2.3", 2002. 478 [DIM] Calhoun, P et. al., 479 "Diameter Base Protocol", draft-ietf-aaa-diameter-12.txt, July 2002. 481 [DMIPA] Calhoun, P. et. al., "Diameter Mobile IPv4 Application", 482 draft-ietf-aaa-diameter-mobileip-12.txt, August 2002. 484 [SIMIP] Goswami,S., "Simultaneous Handoff of 802.11 and Mobile IPv4", 485 draft-goswami-mobileip-simultaneous-handoff-v4-01.txt, September 2002. 487 [MIPCR] Perkins,C., et.al., "Mobile IPv4 Challenge/Response Extensions", 488 November 2000. 490 [PREAUTH] Aboba, B, "IEEE 802.1x Pre-authentication", IEEE 802.11-02/389r0, 491 June 2002. 493 [CMS] Calhoun,P. et. al., "Diameter CMS Security Application", 494 draft-ietf-aaa-diameter-cms-sec-05.txt, April 2002. 496 8. Author's Address 498 Subrata Goswami, Ph.D. 499 Consultant 500 Newark, CA 94560 501 sgoswami@umich.edu 503 This document expires March 12, 2003.