idnits 2.17.00 (12 Aug 2021) /tmp/idnits14118/draft-adrangi-eap-network-discovery-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 22. -- Found old boilerplate from RFC 3978, Section 5.5 on line 671. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 648. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 655. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 661. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 677), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 44. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 2 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 269: '...he implementation MUST not require the...' RFC 2119 keyword, line 272: '...rators therefore MAY choose to deploy ...' RFC 2119 keyword, line 279: '...IUS proxy/server MAY send an EAP-Ident...' RFC 2119 keyword, line 286: '...the NAI, then it MUST discard the pack...' RFC 2119 keyword, line 288: '...m described in this document SHOULD be...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 448 has weird spacing: '...esponse to th...' == Line 458 has weird spacing: '...tribute to...' == Line 550 has weird spacing: '...tribute to th...' == 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: - In order for a wireless client software implementation to work with all options transparently, the implementation MUST not require the arrival of mediating network information on a particular EAP-Identity Request (i.e., the initial or a subsequent Request). Access network operators therefore MAY choose to deploy any of the above delivery mechanism options in their network without losing interoperability. However, delivery mechanism options 2 and 3 are recommended as they are backward-compatible with the currently-deployed APs. -- 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 (June 17, 2004) is 6547 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) ** Obsolete normative reference: RFC 2234 (ref. '1') (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 3588 (ref. '3') (Obsoleted by RFC 6733) ** Downref: Normative reference to an Informational RFC: RFC 3579 (ref. '4') == Outdated reference: draft-ietf-eap-rfc2284bis has been published as RFC 3748 == Outdated reference: A later version (-02) exists of draft-arkko-roamops-rfc2486bis-00 -- Possible downref: Normative reference to a draft: ref. '6' Summary: 11 errors (**), 0 flaws (~~), 8 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Extensible Authentication Protocol F. Adrangi 3 Working Group V. Lortz 4 Internet-Draft Intel Corporation 5 Expires: December 16, 2004 F. Bari 6 AT&T Wireless 7 P. Eronen 8 Nokia Research Center 9 M. Watson 10 Nortel 11 June 17, 2004 13 Mediating Network Discovery in the Extensible Authentication Protocol 14 (EAP) 15 draft-adrangi-eap-network-discovery-01 17 Status of this Memo 19 By submitting this Internet-Draft, I certify that any applicable 20 patent or other IPR claims of which I am aware have been disclosed, 21 and any of which I become aware will be disclosed, in accordance with 22 RFC 3668. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as 27 Internet-Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt. 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 This Internet-Draft will expire on December 16, 2004. 42 Copyright Notice 44 Copyright (C) The Internet Society (2004). All Rights Reserved. 46 Abstract 48 This document defines a mechanism to enable a wireless client to 49 discover roaming partners of an access network over EAP. The purpose 50 is to help a wireless client select the most appropriate roaming 51 partner as a next hop for routing of AAA packets. This solution is 52 especially useful in roaming scenarios where the access network does 53 not have a direct relationship with the wireless client's home 54 network - i.e., when AAA packets can not be directly routed from 55 access network to the home network. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 1.1 Applicability . . . . . . . . . . . . . . . . . . . . . . 4 61 1.2 Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 62 2. Data Model . . . . . . . . . . . . . . . . . . . . . . . . . . 5 63 3. Delivery Mechanism . . . . . . . . . . . . . . . . . . . . . . 6 64 4. Implementation Considerations . . . . . . . . . . . . . . . . 6 65 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 66 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 67 7. Appendix . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 68 8. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 13 69 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 70 9.1 Normative References . . . . . . . . . . . . . . . . . . . . 13 71 9.2 Informative References . . . . . . . . . . . . . . . . . . . 13 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 14 73 Intellectual Property and Copyright Statements . . . . . . . . 15 75 1. Introduction 77 In wireless network access, the high level network topology is 78 comprised of access networks, mediating networks, and home networks 79 as depicted in Figure 1. RADIUS [2] protocol has been assumed for 80 AAA mediation between the access network and the home network 81 although Diameter [3] could also be used instead of RADIUS without 82 introducing significant architectural differences. 84 Access Network Mediating Network 1 85 +-------------------+ +-----------+ Home 86 | | | | Network A 87 | +------+ | |AAA server;| +---------------+ 88 | +-----+ |Access| | | Other |=====|Home AAA server| 89 | |APs | |Router| | ||====|Components | | | 90 | |1..n | +------+ | || +------------ | and | 91 | +-----+ | || | Other | 92 | +------+ | || Mediating Network 2 | Components | 93 | +-----+ |local | | || +------------+ | | 94 | |Users| |AAA | | || |AAA Server; |====| | 95 | |1..n | |Server|============| Other | +---------------+ 96 | +-----+ +------+ | || | Components | 97 | | || +------------+ 98 +-------------------+ || 99 || Mediating Network 3 100 || +------------+ Home 101 || | | Network B 102 || |AAA Server; | +---------------+ 103 ||====| Other |===|Home AAA Server| 104 || | Components | | | 105 || +------------+ | and | 106 || | Other | 107 || | Components | 108 ||=====================| | 109 | | 110 +---------------+ 112 Figure 1. Network Access Arrangement. 114 In roaming situations, EAP authentication exchanges [5] will be 115 carried out between the wireless client in the access network and an 116 AAA server in the home network directly when the two networks have a 117 direct roaming relationship. However when a wireless client roams to 118 an access network that it does not recognize and which does not have 119 a direct roaming relationship with its home network, the AAA packets 120 have to be routed through a mediating AAA network to the home 121 network. For inter operator settlement reasons, it is necessary to 122 select the best mediating network. For instance, in Figure 2, access 123 through the Mediating Network 1 may be cheaper for isp1 user, than if 124 Mediating Network 2 is used. However this decision can not be made 125 by the access network as it would be unaware of the roaming 126 agreements of mediating networks 1 and 2 with the isp1. For this 127 reason, it is desirable for the wireless client to know which 128 mediating networks are available through an access network, and 129 influence the decision of using the desired mediating network. 131 +---------+ 132 | |---------> "isp1.com" 133 | Roaming | 134 +---------+ | Group 1 | 135 | |-------->| |---------> "isp2.com" 136 User "joe | Access | +---------+ 137 @isp1.com"--->| Network | 138 | | +---------+ 139 | |-------->| |---------> "isp1.com" 140 +---------+ | Roaming | 141 | Group 2 | 142 | |---------> "isp3.com" 143 +---------+ 145 Figure 2: Ambiguous AAA routing 147 Influencing the mediating network selection problem can be divided 148 into three sub-problems as follows: 150 1. A syntax by which mediating network information can be 151 represented. 153 2. A delivery mechanism by which mediating network information is 154 conveyed to a wireless client. 156 3. A general mechanism by which a wireless client's selection can be 157 conveyed to the access network. 159 Section 2.7 of [6] discusses the conditions upon which NAIs can be 160 used to affect AAA routing, i.e., problem 3 above. Problems 1 and 2 161 are discussed in this document. 163 1.1 Applicability 165 Although the proposed solution here is discussed in the context of 166 public 802.11 access network deployment, it is applicable to other 167 public wireless access networks where the wireless clients use the 168 EAP specification framework [5] for authentication, and they present 169 their identity to the network in NAI [6] format. 171 1.2 Terminology 173 Network Access Identifier (NAI) 174 An identifier that represents a wireless client or user 175 identity. The basic structure of a NAI is user@realm, where 176 the realm part of the NAI indicates the domain responsible 177 for interpretation and resolution of the user name. Please 178 See [6] for more details on NAI format. 180 Access Point (AP) 181 A station that provides access to the distribution services 182 via the wireless medium for associated Stations. 184 RADIUS server 185 This is a server which provides for authentication/ 186 authorization via the protocol described in [2]. 188 2. Data Model 190 Mediating network information needs to be structured in a general 191 format and syntax so that the EAP client software can interpret it 192 and behave accordingly. The syntax should have minimum overhead 193 because the proposed delivery mechanism (i.e., EAP-Identity Request) 194 doesn't support fragmentation and therefore size of the data is 195 limited by the link layer MTU. 197 Mediating network information is placed after the displayable string 198 and NULL in the EAP-Identity Request. It is structured as a set of 199 comma-separated attribute names and values according to the following 200 ABNF [1]: 202 identity-request-data = displayable-string [ %d0 network-info ] 203 displayable-string = *CHAR 205 network-info = attribute "=" value 207 attribute = 1*( ALPHA / "-" / "_" / DIGIT) 209 value = 1*( %x01-2B / %x2D-FF ) ; any non-null UTF-8 char except "," 211 The CHAR, DIGIT, ALPHA terminals are defined in [1]. 213 Only one attribute is defined here, the NAIRealms attribute. The use 214 of this facility for other purposes is discouraged due to the limited 215 amount of space available in EAP packets. 217 The format and semantics of the NAIRealms attribute value are as 218 follows: 220 value = Realm [ ";" Realm ] 222 Where the Realm is defined in [6]. 224 An example "NAIRealms" attribute is shown below: 226 NAIRealms=anyisp.com;mnc123.mcc334.3gppnetwork.org 228 3. Delivery Mechanism 230 There are three possible options of delivering mediating network 231 information to a wireless client by using an EAP-Identity Request. 232 These options are: 234 Option 1 - Use the Initial EAP-Identity Request issued by the access 235 network NAS 237 Mediating network information is pushed to a wireless client in 238 the initial EAP-Identity Request issued by the AP. 240 Option 2 - Use the initial EAP-Identity Request issued by the access 241 network RADIUS server 243 This is similar to Option 1, but the initial EAP-Identity Request 244 is issued by the access network RADIUS Server instead. Once a 245 wireless client associates with an access network AP using native 246 IEEE 802.11 procedures, the AP sends an EAP-Start message [4] 247 within a RADIUS Access-Request to trigger an EAP conversation 248 initiated by the access network RADIUS server. 250 Option 3 - Use a subsequent EAP-Identity Request issued by the access 251 network RADIUS server 253 Mediating network information is delivered to a wireless client in 254 a subsequent EAP-Identity request, after the initial EAP-Identity 255 Request/Response exchange, issued by by the access network RADIUS 256 server. 258 4. Implementation Considerations 260 - In general, an option that requires changes only to a central AAA 261 server is much preferred than a one that impacts a distributed set of 262 APs. The reasons for this preference include ease of operation and 263 deployment, update costs, backwards compatibility and possible impact 264 on current standards. Option 3 is therefore preferred as it does not 265 require any changes to the AP. Option 2 is also equally desirable if 266 the AP supports the EAP-Start message [4]. 268 - In order for a wireless client software implementation to work with 269 all options transparently, the implementation MUST not require the 270 arrival of mediating network information on a particular EAP-Identity 271 Request (i.e., the initial or a subsequent Request). Access network 272 operators therefore MAY choose to deploy any of the above delivery 273 mechanism options in their network without losing interoperability. 274 However, delivery mechanism options 2 and 3 are recommended as they 275 are backward-compatible with the currently-deployed APs. 277 - When Option 3 is used, upon receipt of a RADIUS Access-Request 278 packet containing the initial EAP-Identity Response, the access 279 network RADIUS proxy/server MAY send an EAP-Identity Request 280 containing mediating network information to the wireless client if it 281 cannot route the RADIUS packet to the next AAA hop based on the realm 282 portion (i.e., string after the @ sign) of the NAI in the RADIUS 283 User-Name attribute. When a RADIUS Access-Request containing a 284 subsequent EAP-Identity Response is received, if the RADIUS proxy/ 285 server still cannot route the RADIUS packet to the next AAA hop based 286 on the realm portion of the NAI, then it MUST discard the packet. 288 - The use of the mechanism described in this document SHOULD be 289 reserved for situations where the WLAN client can not identify a 290 direct route to its home network based on the available SSIDs in the 291 hotspot. 293 5. IANA Considerations 295 This document does not define a new name space, therefore, there are 296 no considerations for IANA. 298 6. Security Considerations 300 Mediating network information delivered inside an EAP-Identity 301 Request before the user authenticates to the network. Therefore, it 302 is considered as a hint in guiding the wireless client to select the 303 desired mediating network through which the AAA packets should be 304 routed. 306 It should also be noted that at least with some EAP methods, there is 307 no way for the home network RADIUS server to verify that the 308 mediating network used was actually the same one that the wireless 309 client had requested. 311 7. Appendix 313 The railroad diagrams below illustrate conversations between a 314 wireless client, AP, Access Network (AN) RADIUS proxy/server, 315 Mediating Network (MN) RADIUS proxy/server, and Home Network (HN) 316 RADIUS server for the three options described above. 318 Option 1 - Use the Initial EAP-Identity Request issued by the access 319 network AP 321 Wireless AP AN RADIUS MN RADIUS HN RADIUS 322 Client server server Server 323 | (1) | | | | 324 | EAP Id. Req. | | | | 325 |(Network Info) | | | | 326 |< -------------| | | | 327 | | | | | 328 | (2a) | | | | 329 | EAP Id. Resp. | | | | 330 |(Decorated NAI)| | | | 331 | *OR* | | | | 332 | (2b) | | | | 333 | EAP Id. Resp. | | | | 334 |(normal NAI) | | | | 335 |------------- >| (3) | | | 336 | |Access Request | | | 337 | |(EAP Id. Resp.)| | | 338 | |------------- >| (4) | | 339 | | |Access Request | | 340 | | |(EAP Id. Resp.)| | 341 | | |------------- >| | 342 | | | | | 343 | | | |Access Request | 344 | | | |(EAP Id. Resp.)| 345 | | | (5) |------------- >| 346 | ... | ... | ... | ... | 347 | < EAP Authentication Methods > | 348 | ... | | ... | ... | 349 | | | | | 350 | | | | | 351 | EAP Success | | | | 352 |< ------------ | | | | 353 | | | | | 355 The following describes each message flow in details. 357 1. The AP sends the initial EAP-Identity Request containing 358 mediating network information to the wireless client. 360 2. The wireless client sends an EAP-Identity Response containing a 361 Decorated NAI indicating the selected MN to the AP. OR, 363 3. The wireless client sends an EAP-Identity Response containing a 364 normal NAI (i.e., non-decorated)to the AP. 366 4. The AP sends a RADIUS Access Request packet containing the 367 EAP-Identity Response to the access network RADIUS proxy/server 368 as described in [4]. Please note that NAI in the EAP-Identity 369 Response is copied to the RADIUS User-Name attribute in the 370 Access-Request packet as per [4]. 372 5. The access network RADIUS proxy/server forwards the received 373 Access-Request packet to the next AAA hop based on the realm 374 portion of the NAI in the RADIUS User-Name attribute. 376 6. The MN RADIUS proxy/server forwards the received Access-Request 377 packet based on the NAI in the RADIUS User-Name attribute to the 378 next AAA hop (i.e., HN RADIUS Server). 380 7. The EAP Authentication continues as described in [4]. 382 Option 2 - Use the initial EAP-Identity Request issued by the access 383 network RADIUS server. 385 Wireless AP AN RADIUS MN RADIUS HN RADIUS 386 Client server server Server 388 | (1) | | | | 389 | Association | | | | 390 |------------ >| (2) | | | 391 | |Access Request | | | 392 | |(EAP-Start) | | | 393 | |-------------- >| | | 394 | | | | | 395 | | (3) | | | 396 | |Access Challenge| | | 397 | |(EAP Id. Req. + | | | 398 | | (Network Info) | | | 399 | (4) |< --------------| | | 400 | EAP Id. Req. | | | | 401 |(Network Info)| | | | 402 |< ------------| | | | 403 | | | | | 404 | (5a) | | | | 405 |EAP Id. Resp. | | | | 406 | | | | | 407 | (5b) | | | | 408 |EAP Id. Resp. | | | | 409 |------------ >| (6) | | | 410 | |Access Request | | | 411 | |(EAP Id. Resp.) | | | 412 | |-------------- >| (7) | | 413 | | |Access Req. ( | | 414 | | |EAP Id. Resp.)| | 415 | | |------------ >| | 416 | | | |Access Request | 417 | | | |(EAP Id. Resp.)| 418 | | | |------------- >| 419 | ... | ... |.. | ... | 420 | < EAP Authentication Methods > | 421 | ... | |... | ... | 422 | | | | | 423 | EAP Success | | | | 424 |< ------------| | | | 426 The following describes each message flow in details. 428 1. The wireless client associates with the AP. 430 2. An EAP-Start message encapsulated within a RADIUS Access-Request 431 sent to the access network RADIUS server. 433 3. The access network RADIUS server processes the received 434 Access-Request message and initiates an EAP conversation by 435 sending an EAP-Identity Request containing mediating network 436 information encapsulated within a RADIUS Access-Challenge. 438 4. The AP extracts the EAP-Identity Request from the received 439 Access-Challenge and sends it to the wireless client. 441 5. The wireless client sends an EAP-Identity Response containing its 442 decorated NAI indicating the selected MN to the AP. OR, 444 6. The wireless client sends an EAP-Identity Response containing a 445 normal NAI (i.e., non-decorated) to the AP. 447 7. The AP sends a RADIUS Access-Request packet containing the 448 EAP-Identity Response to the access network RADIUS server as 449 described in [4]. Please note that NAI in the EAP-Identity 450 Response is copied to the RADIUS User-Name attribute in the 451 Access-Request packet as per [4]. 453 8. The access network RADIUS proxy/server forwards the received 454 Access-Request packet to the next AAA hop based on the realm 455 portion of the NAI in the RADIUS User-Name attribute. 457 9. The MN RADIUS proxy/server forwards the received Access-Request 458 packet based on the NAI in the RADIUS User-Name attribute to 459 the next AAA hop (i.e., HN RADIUS Server). 461 10. The EAP Authentication continues as described in [4]. 463 Option 3 - Use a subsequent EAP-Identity Request issued by the access 464 network RADIUS server 466 Wireless AP AN RADIUS MN RADIUS HN RADIUS 467 Client server server Server 468 | (1) | | | | 469 | EAP Id. Req. | | | | 470 |< ------------| | | | 471 | | | | | 472 | (2) | | | | 473 | EAP Id. Resp.| | | | 474 |------------ >| (3) | | | 475 | |Access Request | | | 476 | |(EAP Id. Resp.) | | | 477 | |-------------- >| | | 478 | | | | | 479 | | (4) | | | 480 | |Access Challenge| | | 481 | |(EAP Id. Req. + | | | 482 | | (Network Info) | | | 483 | (5) |< --------------| | | 484 | EAP Id. Req. | | | | 485 |(Network Info)| | | | 486 |< ------------| | | | 487 | | | | | 488 | (6) | | | | 489 |EAP Id. Resp. | | | | 490 | | | | | 491 |------------ >| (7) | | | 492 | |Access Request | | | 493 | |(EAP Id. Resp.) | | | 494 | |-------------- >| (8) | | 495 | | |Access Req.( | | 496 | | |EAP Id. Resp.)| | 497 | | |------------ >| | 498 | | | |Access Request | 499 | | | |(EAP Id. Resp.)| 500 | | | |------------- >| 501 | ... | ... |.. | ... | 502 | < EAP Authentication Methods > | 503 | ... | ... |... | ... 504 | | | | | 505 | EAP Success | | | | 506 |< ------------| | | | 508 The following describes each message flow in details. 510 1. The access network AP issues an EAP-Identity Request to a 511 wireless client 513 2. The wireless client replies with an EAP-Identity Response 514 containing a normal NAI (i.e., non-decorated), or perhaps a 515 Decorated NAI [6] based on the mediating network information 516 cached from the most recent authentication session to the access 517 network. 519 3. The AP creates a RADIUS Access-Request packet encapsulating the 520 EAP-Identity Response and sends it to the access network RADIUS 521 server. 523 4. The access network RADIUS proxy/server sends a RADIUS 524 Access-Challenge packet encapsulating an EAP-Identity Request 525 containing mediating network information. Or, the step 8 is 526 executed if the access network proxy/server can route the packet 527 based on the realm portion of the NAI in the RADIUS User-Name 528 attribute to the next AAA hop. 530 5. The access network AP forwards the EAP-Identity Request 531 containing the mediating network information to the wireless 532 client. 534 6. The wireless client replies with an EAP-Identity Response 535 containing a Decorated NAI indicating the preferred MN. Wireless 536 client can still send an undecorated NAI to the RADIUS proxy/ 537 server, if it is a legacy client. It should also be noted that 538 the wireless client may also decide not to connect to the access 539 network in the absence of the desired MN in the received MN 540 information in step (4). 542 7. The access network AP forwards the EAP-Identity Response to the 543 access network RADIUS server over RADIUS protocol. 545 8. The access network RADIUS proxy/server forwards the received 546 Access Request to the appropriate MN RADIUS server based on the 547 realm portion of the NAI in the RADIUS User-Name attribute. 549 9. The MN RADIUS proxy/server forwards the received Access-Request 550 packet based on the NAI in the RADIUS User-Name attribute to the 551 next AAA hop (i.e., HN RADIUS Server). The EAP Authentication 552 continues as described in [4]. 554 8. Acknowledgement 556 The authors would specially like to thank Jari Arkko (of Ericsson) 557 for his help in scoping the problem, for reviewing the draft work in 558 progress and for suggesting improvements to it. 560 The authors would also like to acknowledge and thank Jari Arkko (of 561 Ericson), Bernard Aboba (of Microsoft), Adrian Buckley (of RIM), 562 Blair Bullock (of iPass) , Jose Puthenkulam (of Intel), Johanna Wild 563 (of Motorola), Joe Salowey (of Cisco), Marco Spini (of Telecom 564 Italia), Simone Ruffino (of Telecom Italia) and Mark Grayson (of 565 Cisco)for their support, feedback and guidance during the various 566 stages of this work. 568 9. References 570 9.1 Normative References 572 [1] Crocker, D. and P. Overell, "Augmented BNF for Syntax 573 Specifications: ABNF", RFC 2234, November 1997. 575 [2] Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote 576 Authentication Dial In User Service (RADIUS)", RFC 2865, June 577 2000. 579 [3] Calhoun, P., Loughney, J., Guttman, E., Zorn, G. and J. Arkko, 580 "Diameter Base Protocol", RFC 3588, September 2003. 582 [4] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial In 583 User Service) Support For Extensible Authentication Protocol 584 (EAP)", RFC 3579, September 2003. 586 [5] Blunk, L., "Extensible Authentication Protocol (EAP)", 587 draft-ietf-eap-rfc2284bis-09 (work in progress), February 2004. 589 [6] Aboba, B., "The Network Access Identifier", 590 draft-arkko-roamops-rfc2486bis-00 (work in progress), February 591 2004. 593 9.2 Informative References 594 Authors' Addresses 596 Farid Adrangi 597 Intel Corporation 598 2111 N.E. 25th Avenue 599 Hillsboro OR 600 USA 602 Phone: +1 503-712-1791 603 EMail: farid.adrangi@intel.com 605 Victor Lortz 606 Intel Corporation 607 2111 N.E. 25th Avenue 608 Hillsboro OR 609 USA 611 Phone: +1 503-264-3253 612 EMail: victor.lortz@intel.com 614 Farooq Bari 615 AT&T Wireless 616 7277 164th Avenue N.E. 617 Redmond WA 618 USA 620 Phone: +1 425-580-5526 621 EMail: Farooq.bari@attws.com 623 Pasi Eronen 624 Nokia Research Center 625 P.O. Box 407 626 FIN-0005 Nokia Group 627 Finland 629 EMail: pasi.eronen@nokia.com 631 Mark Watson 632 Nortel 633 2221, Lakeside Blvd 634 Richardson TX 635 USA 637 EMail: mwatson@nortel.com 639 Intellectual Property Statement 641 The IETF takes no position regarding the validity or scope of any 642 Intellectual Property Rights or other rights that might be claimed to 643 pertain to the implementation or use of the technology described in 644 this document or the extent to which any license under such rights 645 might or might not be available; nor does it represent that it has 646 made any independent effort to identify any such rights. Information 647 on the procedures with respect to rights in RFC documents can be 648 found in BCP 78 and BCP 79. 650 Copies of IPR disclosures made to the IETF Secretariat and any 651 assurances of licenses to be made available, or the result of an 652 attempt made to obtain a general license or permission for the use of 653 such proprietary rights by implementers or users of this 654 specification can be obtained from the IETF on-line IPR repository at 655 http://www.ietf.org/ipr. 657 The IETF invites any interested party to bring to its attention any 658 copyrights, patents or patent applications, or other proprietary 659 rights that may cover technology that may be required to implement 660 this standard. Please address the information to the IETF at 661 ietf-ipr@ietf.org. 663 Disclaimer of Validity 665 This document and the information contained herein are provided on an 666 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 667 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 668 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 669 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 670 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 671 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 673 Copyright Statement 675 Copyright (C) The Internet Society (2004). This document is subject 676 to the rights, licenses and restrictions contained in BCP 78, and 677 except as set forth therein, the authors retain all their rights. 679 Acknowledgment 681 Funding for the RFC Editor function is currently provided by the 682 Internet Society.