idnits 2.17.00 (12 Aug 2021) /tmp/idnits59920/draft-adrangi-eap-network-discovery-and-selection-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: ---------------------------------------------------------------------------- ** Bad filename characters: the document name given in the document, 'draft-adrangi-eap-network-Discovery-and-Selection-01', contains other characters than digits, lowercase letters and dash. == Mismatching filename: the document gives the document name as 'draft-adrangi-eap-network-Discovery-and-Selection-01', but the file name used is 'draft-adrangi-eap-network-discovery-and-selection-01' == There are 28 instances of lines with non-ascii characters in the document. == The page length should not exceed 58 lines per page, but there was 2 longer pages, the longest (page 20) being 79 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The "Author's Address" (or "Authors' Addresses") section title is misspelled. == Line 26 has weird spacing: '... The list ...' == Line 79 has weird spacing: '...ireless acce...' == Line 91 has weird spacing: '...reafter these...' == Line 92 has weird spacing: '...Network in t...' == Line 919 has weird spacing: '... This docum...' == 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 WLAN client software implementation to work with all options transparently, the implementation MUST not expect the arrival of Network Information on a particular EAP-Identity Request (i.e., the initial or a subsequent Request). PWLAN AN operators therefore MAY choose to deploy any of the above delivery mechanism options in their network without risking the interoperability. However, this document recommends deploying delivery mechanism options 2 and 3 as they are backward-compatible with the currently deployed APs. == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (Aug 10, 2004) is 6493 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: 'RFC2119' on line 276 -- Looks like a reference, but probably isn't: 'Option 1' on line 390 -- Looks like a reference, but probably isn't: 'Option 2' on line 485 -- Looks like a reference, but probably isn't: 'Option 3' on line 601 == Outdated reference: draft-ietf-aaa-diameter has been published as RFC 3588 ** Obsolete normative reference: RFC 2284 (ref. '3') (Obsoleted by RFC 3748) ** Obsolete normative reference: RFC 2234 (ref. '7') (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 2434 (ref. '8') (Obsoleted by RFC 5226) == Outdated reference: draft-ietf-eap-rfc2284bis has been published as RFC 3748 Summary: 6 errors (**), 0 flaws (~~), 14 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Farid Adrangi (Ed.) 3 INTERNET DRAFT Intel Corporation 4 Category: Informational Feb 10, 2004 5 Expires : Aug 10, 2004 7 Mediating Network Discovery and Selection 8 draft-adrangi-eap-network-Discovery-and-Selection-01.txt 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance 13 with all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet 16 Engineering Task Force (IETF), its areas, and its working 17 groups. Note that other groups may also distribute working 18 documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six 21 months and may be updated, replaced, or obsoleted by other 22 documents at any time. It is inappropriate to use Internet- 23 Drafts as reference material or to cite them other than as "work 24 in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 Abstract 34 This document proposes a solution for Service Network discovery 35 and selection that could be implemented within the existing EAP 36 specification framework. The purpose of Service Network discovery 37 and selection here is to help a WLAN client using EAP for 38 authentication to decide whether or not to connect to a WLAN 39 Access Network, and help it select the most appropriate Mediating 40 Network as a next hop for routing AAA packets in roaming 41 situations where the WLAN Access Network has agreements with more 42 than one Mediating Network affiliated with the clientÆs Home 43 Service Network. 45 The proposed solution has 3 components: a delivery mechanism for 46 conveying Access Network and Service Network Information to a WLAN 47 client, a data model/syntax for structuring the information in a 48 generic manner, and a mechansim by which the WLAN client can 49 indicate its selection to the WLAN Access Network. 51 Table of Contents 53 1. Introduction....................................................3 54 1.1 Authentication Message Flow....................................4 55 1.2 Problem Statement..............................................5 56 1.3 Rationale for the Proposed Solution............................5 57 1.4 Applicability of the Proposed Solution.........................7 58 1.5 Requirements language..........................................7 59 1.6 Terminology....................................................7 60 2. Proposed Solution...............................................8 61 2.1 Delivery Mechanism.............................................9 62 2.2 Data Model / Syntax...........................................17 63 2.3 NAI Decoration................................................18 64 3. Attribute Definitions..........................................18 65 3.1 NAIRealms.....................................................18 66 4. IANA Considerations............................................18 67 5. Security Considerations........................................19 68 6. Contributors...................................................19 69 7. Acknowledgements...............................................19 70 8. References.....................................................19 71 AuthorsÆ Addresses................................................20 73 1. Introduction 75 Wireless LAN (WLAN) Access Networks are being deployed in public 76 places such as airports, hotels, shopping malls, and coffee shops. 77 A Public WLAN (PWLAN) Access Network typically consists of three 78 key components that work together to provide authorized users with 79 a wireless access to the Internet or to services 80 offered/authorized by their Service Network providers (e.g., WISP, 81 3GPP, or 3GPP2 type Service Networks). The three components are: 82 the Access Points (AP), the PWLAN AAA server, and the Access 83 Router which links the PWLAN Access Network to the services 84 network (i.e., Internet and/or operatorÆs core IP network). 86 A PWLAN Access Network MAY have a direct or an indirect (i.e., via 87 a mediator) relationship with 1 or more Service Networks (e.g., 88 WISP, 3GPP, or 3GPP2). Figure 1 illustrates a PWLAN Access 89 Network that has roaming agreements with three Mediating Networks 90 (i.e., öRoaming Partnerö or öBrokerö or öVisited Service Networkö 91 - hereafter these terms are used interchangeably to mean a 92 Mediating Network in this document). As the figure shows, 93 Mediating Networks 1 and 2 have relationships with Home Service 94 Network A; Mediating Network 3 has relationship with Home Service 95 Network B. The figure also shows a direct relationship between 96 the PWLAN Access Network and Home Service Network B. 98 PWLAN Access Network Mediating Network 1 99 +-------------------+ +-----------+ Home Service 100 | | | | Network A 101 | +------+ | |AAA server;| +---------------+ 102 | +-----+ |Access| | | Other |=====|Home AAA server| 103 | |APs | |Router| | ||====|Components | | | 104 | |1..n | +------+ | || +------------ | ,And | 105 | +-----+ | || | Other | 106 | +------+ | || Mediating Network 2 | Components | 107 | +-----+ |PWLAN | | || +------------+ | | 108 | |Users| |AAA | | || |AAA Server; |====| | 109 | |1..n | |Server|============| Other | +---------------+ 110 | +-----+ +------+ | || | Components | 111 | | || +------------+ 112 +-------------------+ || 113 || Mediating Network 3 114 || +------------+ Home Service 115 || | | Network B 116 || |AAA Server; | +---------------+ 117 ||====| Other |===|Home AAA Server| 118 || | Components | | | 119 || +------------+ | ,And | 120 || | Other | 121 || | Components | 122 ||=====================| | 123 | | 124 +---------------+ 126 Figure 1 : WLAN Roaming Network Architecture with AAA mediation 128 To be specific, hereafter, RADIUS [1] protocol is assumed for AAA 129 mediation between the PWLAN Access Network and the Home Service 130 Provider. Diameter [2] could also be used instead of RADIUS 131 without introducing significant architectural differences. 133 1.1 Authentication Message Flow 135 This section provides an overview of authentication exchanges 136 between a WLAN client and a Home Service Provider. 138 In roaming situations, authentication exchanges are carried out 139 between a WLAN client in a PWLAN AN and a RADIUS server in a Home 140 Service Network through 1 or more RADIUS proxies/servers located 141 in the PWLAN Access Network and the Mediating Networks as shown 142 in Figure 2. During the authentication phase, EAP messages are 143 encapsulated using a mechanism such as EAPOL (EAP over LAN) 144 between the WLAN client and the AP and re-encapsulated in RADIUS 145 messages (referred to as the öEAP over RADIUSö [4]) from the AP 146 to the home RADIUS server in the Home Service Network. 148 WLAN Access Point Mediating Network Home 149 Client RADIUS Server RADIUS Server 150 (1 or more) 151 |<------------------------- EAP------------------------------->| 152 |<--- EAPOL ---->|<-------------- RADIUS --------------------->| 153 |<--------------- UDP ----------------------->| 154 |<--------------- IP ------------------------>| 156 Figure 2 û EAP-based Authentication Message Flow 158 1.2 Problem Statement 160 In roaming situations where a WLAN Access Network has agreements 161 with more than one Mediating Network affiliated with a WLAN 162 clientÆs Home Service Network, the WLAN client SHOULD be able to 163 influence the selection of the desired Mediating Network through 164 which authentication packets SHOULD be routed through. The WLAN 165 client may prefer one Mediating Network over another for 166 charging, Quality of Service (QoS), or other reasons. The WLAN 167 client may also decide to not connect to the WLAN Access Network 168 due to the absence of a desired Mediating Network. 170 Influencing the Mediating Network selection problem can be 171 divided into three sub-problems as follows: 173 1) A delivery mechanism by which Network Information is 174 conveyed to a WLAN client. 176 2) A general data model and syntax by which Network 177 Information is structured for unambiguous interpretation by 178 the WLAN client. 180 3) A general mechanism by which a WLAN clientÆs selection 181 can be conveyed to the WLAN Access Network. 183 1.3 Rationale for the Proposed Solution 185 Several solution alternatives were considered for Network 186 Discovery and Selection. The fundamental difference among them 187 is the type of bearer that they use to convey Network Information 188 to a WLAN client. This section articulates the rationale for 189 using EAP as a mechanism / bearer for Network Discovery and 190 Selection by describing why the competing solution alternatives 191 are undesirable. 193 [Competing Solution Alternative 1] 195 It is possible for a WLAN client to derive Network Information 196 from the Broadcast SSID or other such information. However, 197 this requires having structured SSID values with a standardized 198 namespace which will break backwards compatibility, since 199 deployed PWLAN networks may not be in a position to change the 200 SSID used. Also private WLAN SSIDs could overlap with the 201 standardized namespace making it inefficient. 203 Note that the SSIDs can be broadcasted as the identities of the 204 Mediating Networks which eliminates the need for having 205 structure SSID values with a standardized namespace. However, 206 this will require APs to support broadcast of multiple SSIDs 207 which is not an IEEE standard. Furthermore, the capability for 208 broadcasting multiple SSIDs may have some scalability 209 implications. 211 [Competing Solution Alternative 2] 213 It is possible to convey Network Information in Access Point 214 (AP) broadcasts (e.g., beacon frames) to a WLAN client. 215 However, this is undesirable because of the high frequency 216 (i.e., every 100-400ms) of these broadcast frames and the 217 incurred traffic overhead which would adversely impact the 218 PWLAN performance. Furthermore, this is not backward- 219 compatible with existing PWLAN deployments as it requires 220 firmware/hardware changes to the APs. 222 [Competing Solution Alternative 3] 224 It is possible for a WLAN client to do active scanning wherein 225 the WLAN client would send a probe request with a specific 226 SSID and the Access Point would respond with the Network 227 Information. However, this will require changes to the APs to 228 support administrating and delivering Network Information, 229 hence it is not backward-compatible with currently deployed 230 PWLAN networks. It will also require changes to network 231 software layers on the client to propagate the information up 232 to the appropriate layer. 234 [Competing Solution Alternative 4] 236 It is possible for a WLAN client to have a local database 237 mapping SSIDs to Mediating Network names, where it is not 238 necessary to change SSIDs. However, this will have the same 239 problems as the alternative 1. Furthermore, it will require 240 storage space for the database, and a mechanism for updating 241 it. 243 Having described the disadvantages of the competing solution 244 alternatives, this document proposes a solution that uses EAP as 245 a mechanism for conveying Network Information to a WLAN client. 246 And, the rationale for this as follows: 248 o The proposed solution is backward-compatible with existing 249 PWLAN deployments. 251 o The proposed solution does not introduce a new protocol 252 standard, or require any significant protocol changes to 253 existing protocol standards. 255 o The proposed solution can be implemented without impacting 256 existing APs deployed in PWLAN networks. 258 o The proposed solution does not negatively impact the 259 performance of PWLAN networks. 261 1.4 Applicability of the Proposed Solution 263 The solution can be deployed in any wireless access network 264 architecture where the clients use the existing EAP specification 265 framework [9] for authentication, and they present their identity 266 to the network in NAI [5][10] format. 268 1.5 Requirements language 270 In this document, several words are used to signify the 271 requirements of the specification. These words are often 272 capitalized. The key words "MUST", "MUST NOT", "REQUIRED", 273 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", 274 "MAY", and "OPTIONAL" in this document are to be interpreted as 275 described in [RFC2119]. 277 1.6 Terminology 279 Access Network (AN) 280 The PWLAN hotspot network that provides wireless connectivity 281 to the Internet for WLAN clients (or stations) present in the 282 local access area. This MAY be in a separate security and 283 routing domain with respect to the Home Service Network or a 284 Mediating Network. 286 Home Service Network (HSN) 287 The network providing the service and therefore maintaining 288 the direct relationship to the user/subscriber of the WLAN 289 service. All AAA functions are ultimately performed by the 290 HSN. 292 Visited Service Network (VSN) 293 The Service network providing service in the local 294 geographical region to roaming customers of another HSN. Such 295 networks may act as Mediating Networks to the roaming 296 clients. 298 Mediating Network (MN) 299 The network responsible for mediation between a PWLAN Access 300 Network and a Home Service Network. They could be AAA brokers 301 or Visited Service Networks. 303 Network Information (NI) 304 Network-related information pertaining to a PWLAN network 305 (e.g., location information such as country, state, city, 306 location ID, and etc.) and its roaming partners (e.g., a list 307 of övisited networksö that the PWLAN has agreements with). 309 Network Access Identifier (NAI) 310 An identifier that represents a client or user identity. The 311 basic structure of a NAI is user@realm, where the realm part 312 of the NAI indicates the domain responsible for interpretation 313 and resolution of the user name. See [5][10] for more details 314 on NAI format. 316 Decorated NAI 317 A valid NAI with additional information influencing the 318 routing choice of the next Mediating Network to the PWLAN AAA 319 server as describe in this document. It may include 320 information for several Mediating Networks to be indicated on 321 the route to the Home Service Network. 323 Access Point (AP) 324 öA station that provides access to the distribution services 325 via the wireless medium for associated Stations.ö 327 RADIUS server 328 öThis is a server which provides for 329 authentication/authorization via the protocol described in 330 [1], and for accounting as described in [6].ö It is deployed 331 in the PWLAN AN, MN, and HSN. 333 Service Set Identifier (SSID) 334 öan identifier attached to packets sent over the wireless LAN 335 that functions as a öpasswordö for joining a particular radio 336 network.ö 338 2. Proposed Solution 340 The EAP-Identity request message is used to deliver Network 341 Information (structured by a general data model/syntax) to a WLAN 342 client. Upon receipt of the information, the WLAN client then MAY 343 influence the selection of an MN which has a direct relationship 344 with the PWLAN AN for routing RADIUS packets through to the HSN. 345 This is achieved by sending a Decorated NAI in the Type-Data field 346 of the EAP-Identity Response. As specified in [4], the PWLAN AP 347 then encapsulates the EAP-Response within an EAP-Message attribute 348 and sends it to the PWLAN RADIUS server within a RADIUS Access- 349 Request packet. It also copies the contents of the Type-Data field 350 of the EAP-Response (i.e., the Decorated NAI) into the User-Name 351 attribute. 353 When a PWLAN RADIUS server receives a RADIUS Access-Request packet 354 containing a Decorated NAI which does not specify an MN recognized 355 by the PWLAN AN as the next hop for routing the RADIUS packet, the 356 PWLAN RADIUS server SHOULD route the RADIUS packet based on its 357 local routing policy. 359 The solution is comprised of three components: the delivery 360 mechanism for conveying the information to a WLAN client, the data 361 model / syntax for structuring the information, and the NAI 362 decoration for indicating the selected MN. The following sections 363 describe each solution component in details. 365 2.1 Delivery Mechanism 367 The EAP specification [3] describes the use of the Type-Data 368 field in an EAP-Identity Request for a displayable message 369 terminated by a null. It also suggests that additional data 370 (with format currently undefined) can be placed after the null 371 character. 373 Network Information MUST be placed after the null character in 374 the Type-Data field. The portion of the field prior to the null 375 MAY contain zero or more bytes (depending on whether or not there 376 is a displayable message). There are three possible options of 377 delivering Network Information to a WLAN client by using an EAP- 378 Identity Request. These options are: 380 1) Use the Initial EAP-Identity Request issued by the PWLAN AP. 382 2) Use the initial EAP-Identity Request issued by the PWLAN 383 RADIUS server. 385 3) Use a subsequent EAP-Identity Request issued by the PWLAN 386 RADIUS server. 388 Here we look at these three options with pros and cons of each. 390 [Option 1] Use the Initial EAP-Identity Request issued by the 391 PWLAN AP 393 Network information is pushed to a WLAN Client in the initial 394 EAP-Identity Request issued by the AP. 396 The message flow below illustrates conversations between an 397 authenticating peer, AP, PWLAN AN RADIUS server, MN RADIUS 398 server, and HSN RADIUS server. Where the AP sends an EAP- 399 Request/Identity containing Network Information as the initial 400 packet, the exchange appears as follows: 402 WLAN PWLAN PWLAN MN HSN 403 Client AP RADIUS RADIUS RADIUS 404 | server server Server 405 | (1) | | | | 406 | EAP Id. Req. | | | | 407 |(Network Info) | | | | 408 |<--------------| | | | 409 | | | | | 410 | (2a) | | | | 411 | EAP Id. Resp. | | | | 412 |(Decorated NAI)| | | | 413 | *OR* | | | | 414 | (2b) | | | | 415 | EAP Id. Resp. | | | | 416 |(normal NAI) | | | | 417 |-------------->| (3) | | | 418 | |Access Request | | | 419 | |(EAP Id. Resp.)| | | 420 | |-------------->| (4) | | 421 | | |Access Request | | 422 | | |(EAP Id. Resp.)| | 423 | | |-------------->| | 424 | | | | | 425 | | | |Access Request | 426 | | | |(EAP Id. Resp.)| 427 | | | (5) |-------------->| 428 | ... | ... | ... | ... | 429 | <> | 430 | ... | | ... | ... | 431 | | | | | 432 | | | | Access Accept | 433 | | | | (EAP Success) | 434 | | | |<--------------| 435 | | | | | 436 | | | Access Accept | | 437 | | | (EAP Success) | | 438 | | |<--------------| | 439 | | | | | 440 | |Access Accept | | | 441 | |(EAP Success) | | | 442 | |<--------------| | | 443 | | | | | 444 | EAP Success | | | | 445 |<------------- | | | | 446 | | | | | 447 The following describes each message flow in details. 449 (1) The PWLAN AP sends the initial EAP-Identity Request 450 containing Network Information the WLAN Client. 452 (2a) The WLAN client sends an EAP-Identity Response containing a 453 Decorated NAI indicating the selected MN to the PWLAN AP. OR, 455 (2b) The WLAN client sends an EAP-Identity Response containing a 456 normal NAI defined in [5][10] to the PWLAN AP. 458 (3) The PWLAN AP sends a RADIUS Access Request packet containing 459 the EAP-Identity Response (as defined in [4]) to the PWLAN RADIUS 460 server. 462 (4) The PWLAN RADIUS server processes the received Access-Request 463 packet as specified in [4] and forwards it to the appropriate MN 464 RADIUS server. 466 (5) The EAP Authentication continues as described in [4]. 468 The following summarizes pros and cons of this option. 470 Pros: 471 o It does not introduce additional EAP messages 473 Cons: 474 o It requires modifications to APs, since most currently- 475 deployed APs do not include support for administering and 476 delivering Network Information in the EAP-Identity Request. 478 o It MAY require modification to the PWLAN RADIUS server for 479 processing a Decorated NAI (many RADIUS servers already have 480 this capability). 482 o It MAY introduce a contention problem if space in the Type- 483 Data field has already been used up for other purposes. 485 [Option 2] Use the initial EAP-Identity Request issued by the 486 PWLAN RADIUS server 488 This is similar to Option 1, but the initial EAP-Identity Request 489 is issued by the PWLAN RADIUS Server instead. Once a WLAN client 490 associates with a PWLAN AP using native IEEE 802.11 procedures, 491 the AP sends an EAP-Start message within a RADIUS Access-Request 492 as defined in [4] to trigger an EAP conversation initiated by the 493 PWLAN RADIUS server. 495 The message flow below illustrates conversations between an 496 authenticating peer, AP, PWLAN AN RADIUS server, MN RADIUS 497 server, and HSN RADIUS server. Where the AP sends an EAP- 498 Request/Identity containing Network Information as the initial 499 packet, the exchange appears as follows: 501 WLAN PWLAN PWLAN RADIUS MN RADIUS HSN RADIUS 502 Client AP server server Server 503 | (1) | | | | 504 | Association | | | | 505 |------------->| (2) | | | 506 | |Access Request | | | 507 | |(EAP-Start) | | | 508 | |--------------->| | | 509 | | | | | 510 | | (3) | | | 511 | |Access Challenge| | | 512 | |(EAP Id. Req. + | | | 513 | | (Network Info) | | | 514 | (4) |<---------------| | | 515 | EAP Id. Req. | | | | 516 |(Network Info)| | | | 517 |<-------------| | | | 518 | | | | | 519 | (5a) | | | | 520 |EAP Id. Resp. | | | | 521 | | | | | 522 | (5b) | | | | 523 |EAP Id. Resp. | | | | 524 |------------->| (6) | | | 525 | |Access Request | | | 526 | |(EAP Id. Resp.+ | | | 527 | | Decorated NAI) | | | 528 | |--------------->| (7) | | 529 | | |Access Req. ( | | 530 | | |EAP Id. Resp.+| | 531 | | |Decorated NAI)| | 532 | | |------------->| | 533 | | | |Access Request | 534 | | | |(EAP Id. Resp.)| 535 | | | |-------------->| 536 | ... | ... |.. | ... | 537 | <> | 538 | ... | |... | ... | 539 | | | | | 540 | | | | Access Accept | 541 | | | | (EAP Success) | 542 | | | |<--------------| 543 | | |Access Accept | | 544 | | |(EAP Success) | | 545 | | |<-------------| | 546 | |Access Accept | | | 547 | |(EAP Success) | | | 548 | |<---------------| | | 549 | EAP Success | | | | 550 |<-------------| | | | 552 The following describes each message flow in details. 554 (1) The WLAN client associates with the PWLAN AP. 556 (2) An EAP-Start message encapsulated within a RADIUS Access- 557 Request sent to the PWLAN AN RADIUS server. 559 (3) The PWLAN RADIUS server processes the received Access-Request 560 message and initiates an EAP conversation by sending an EAP- 561 Identity Request encapsulated within a RADIUS Access-Challenge. 563 (4) The PWLAN AP extracts the EAP-Identity Request from the 564 received Access-Challenge and sends it to the WLAN client. 566 (5a) The WLAN client sends an EAP-Identity Response containing a 567 Decorated NAI indicating the selected MN to the PWLAN AP. OR, 569 (5b) The WLAN client sends an EAP-Identity Response containing a 570 normal NAI [5][10] to the PWLAN AP. 572 (6) The PWLAN AP sends a RADIUS Access-Request packet containing 573 the EAP Response (as defined in [4]) to the PWLAN RADIUS server. 575 (7) The PWLAN AN RADIUS server processes the received Access- 576 Request packet and forwards it to the appropriate MN RADIUS 577 server. 579 (8) The EAP Authentication continues as described in [4]. 581 The following summarizes pros and cons of this option. 583 Pros: 584 o It does not introduce additional EAP messages 586 o It does not require any modifications to APs to include 587 support for administrating and delivering Network 588 Information. 590 Cons: 591 o It may not be backwards compatible if currently deployed 592 APs in PWLAN ANs do not support EAP-Start. 594 o It MAY require modification to the PWLAN RADIUS server for 595 processing a Decorated NAI (many RADIUS servers already have 596 this capability). 598 o It MAY introduce a contention problem if space in the Type- 599 Data field has already been used up for other purposes. 601 [Option 3] û Use a subsequent EAP-Identity Request issued by the 602 PWLAN RADIUS server 604 Network Information is delivered to a WLAN Client in a subsequent 605 EAP-Identity request after the initial EAP-Identity 606 Request/Response exchange. 608 Upon receipt of a RADIUS Access-Request packet containing the 609 initial EAP-Identity Response, the PWLAN RADIUS server MAY send 610 an EAP-Identity Request containing Network Information to the 611 WLAN client if the Response does not already contain a Decorated 612 NAI which specifies an MN recognized by the PWLAN AN as the next 613 hop for routing the RADIUS packet. 615 When a RADIUS Access-Request containing a subsequent EAP-Identity 616 Response is received, if the User-Name attribute contains a 617 normal NAI [5][10] then the PWLAN server MUST route the RADIUS 618 packet based on its local routing policy as usual. 620 The protocol message flow below illustrates conversations between 621 an authenticating peer, AP, PWLAN RADIUS server, MN RADIUS 622 server, and HSN RADIUS server. Where the AP sends an EAP- 623 Request/Identity containing Network Information as the initial 624 packet, the exchange appears as follows: 626 WLAN PWLAN PWLAN RADIUS MN RADIUS HSN RADIUS 627 Client AP server server Server 628 | (1) | | | | 629 | EAP Id. Req. | | | | 630 |<-------------| | | | 631 | | | | | 632 | (2) | | | | 633 | EAP Id. Resp.| | | | 634 |------------->| (3) | | | 635 | |Access Request | | | 636 | |(EAP Id. Resp.) | | | 637 | |--------------->| | | 638 | | | | | 639 | | (4) | | | 640 | |Access Challenge| | | 641 | |(EAP Id. Req. + | | | 642 | | (Network Info) | | | 643 | (5) |<---------------| | | 644 | EAP Id. Req. | | | | 645 |(Network Info)| | | | 646 |<-------------| | | | 647 | | | | | 648 | (6) | | | | 649 |EAP Id. Resp. | | | | 650 | | | | | 651 |------------->| (7) | | | 652 | |Access Request | | | 653 | |(EAP Id. Resp.+ | | | 654 | | Decorated NAI) | | | 655 | |--------------->| (8) | | 656 | | |Access Req.( | | 657 | | |EAP Id. Resp.+| | 658 | | |Decorated NAI)| | 659 | | |------------->| | 660 | | | |Access Request | 661 | | | |(EAP Id. Resp.)| 662 | | | |-------------->| 663 | ... | ... |.. | ... | 664 | <> | 665 | ... | ... |... | ... | 666 | | | | | 667 | | | | Access Accept | 668 | | | | (EAP Success) | 669 | | | |<--------------| 670 | | |Access Accept | | 671 | | |(EAP Success) | | 672 | | |<-------------| | 673 | |Access Accept | | | 674 | |(EAP Success) | | | 675 | |<---------------| | | 676 | EAP Success | | | | 677 |<-------------| | | | 679 The following describes each message flow in details. 681 (1) The PWLAN AP issues an EAP-Identity Request to a WLAN Client 683 (2) The WLAN Client replies with an EAP-Identity Response 684 containing a normal NAI, or perhaps a Decorated NAI based on the 685 Network Information cached from the most recent authentication 686 session to the PWLAN AN. 688 (3) The AP creates a RADIUS Access-Request packet encapsulating 689 the EAP-Identity Response and sends it to the PWLAN RADIUS 690 server. 692 (4) The PWLAN RADIUS server sends a RADIUS Access-Challenge 693 packet encapsulating an EAP-Identity Request containing Network 694 Information. Or, the step 8 is executed if the Response does 695 already contain a Decorated NAI which specifies an MN recognized 696 by the PWLAN. 698 (5) The PWLAN AP forwards the EAP-Identity Request containing the 699 network information to the WLAN Client. 701 (6) The WLAN Client replies with an EAP-Identity Response 702 containing a Decorated NAI indicating the preferred MN. 704 (7) The AP forwards the EAP-Identity Response to the PWLAN RADIUS 705 server over RADIUS protocol. 707 (8) The PWLAN RADIUS server processes the received Access-Request 708 message containing a normal or a Decorated NAI and forwards it to 709 the appropriate MN RADIUS server. 711 (9) The EAP Authentication continues as described in [4]. 713 The following summarizes pros and cons of this option. 715 Pros: 716 o It does not require any modifications to existing APs 718 o It uses a dedicated EAP-Identity Request for delivering 719 Network Information and hence no contention problem for using 720 the space in the Type-Data field. 722 Cons: 723 o It introduces an extra EAP-Identity Request/Response pair 725 o It requires software upgrades to the PWLAN RADIUS server 727 In the above options, if the HSN RADIUS server uses an updated 728 User-Name attribute, for example, in RADIUS Access-Challenge and 729 Access-Accept packets, then this SHOULD be used in subsequent 730 RADIUS message flows between AP and Home RADIUS Server. 732 In order for a WLAN client software implementation to work with 733 all options transparently, the implementation MUST not expect the 734 arrival of Network Information on a particular EAP-Identity 735 Request (i.e., the initial or a subsequent Request). PWLAN AN 736 operators therefore MAY choose to deploy any of the above 737 delivery mechanism options in their network without risking the 738 interoperability. However, this document recommends deploying 739 delivery mechanism options 2 and 3 as they are backward- 740 compatible with the currently deployed APs. 742 2.2 Data Model / Syntax 744 Network Information needs to be structured in a general format 745 and syntax so that the WLAN Client software can interpret it and 746 behave accordingly. The syntax SHOULD have minimum overhead 747 because the proposed delivery mechanism (i.e., EAP-Identity 748 Request) doesn't support fragmentation and therefore size of the 749 data is limited by the link layer MTU. 751 Network Information is placed after the displayable string and 752 NULL in the EAP-Identity Request. It is structured as a set of 753 comma-separated attribute names following an optional prefix and 754 values according to the following ABNF [7]. 756 identity-request-data = displayable-string [ %d0 network-info ] 757 displayable-string = *CHAR 759 network-info = item ["," item ] 760 item = attribute "=" value 762 attribute = [prefix] 1*( ALPHA / "-" / "_" / DIGIT) 763 prefix = 1* alphanum ö:ö 765 value = 1*( 0x01-2B / 0x2D-FF ) ; any non-null UTF-8 char except 766 "," 768 The intent of prefixes is to define a namespace to avoid 769 collision where private attribute names (i.e., not registered 770 with IANA) are used. Either Attribute names or their prefixes 771 MUST be registered with IANA [8]. The content of an attribute 772 MUST NOT contain a comma (ö,ö). The exact format and semantics of 773 the content of an attribute MUST be specified in the definition 774 of the attribute. Examples of prefixed and non-prefixed attribute 775 names are: 3GPP:HotSpotInfo, NAIRealms. 777 2.3 NAI Decoration 779 The WLAN client using EAP specifies the preferred MN for routing 780 AAA packets by decorating the NAI that would use a mediating 781 realm, instead of the WLAN clientÆs home realm, in the EAP- 782 Identity Response. The NAI decoration is a representation of a 783 NAI in accordance to the guidelines specified in [5][10] for 784 routing AAA transactions to the userÆs home realm when the home 785 realm is only reachable via another mediating realm. For example, 786 given a userÆs NAI öuser@homerealmö, the NAI can be represented 787 as öhomerealm!user@mediating-netö. 789 3. Attribute Definitions 791 This section lists definitions of 1 or more EAP Network 792 Information attribute(s). 794 3.1 NAIRealms 796 It defines a Network Information attribute for specifying a list 797 of NAI realms corresponding to MNs that are recognized by the 798 PWLAN AN. 800 Attribute name: öNAIRealmsö 802 Attribute value: 804 NAIRealms-value = Realm [ ö;ö Realm ] 806 Realm = *( domainlabel "." ) toplabel 807 domainlabel = alphanum *( alphanum / "-" ) 808 toplabel = ALPHA *alphanum 810 The öNAIRealmsö attribute lists MN names that are recognized by 811 the PWLAN AN. 813 An example öNAIRealmsö attribute is shown below: 815 NAIRealms=ipass.com;mnc123.mcc334.3gppnetwork.org 817 4. IANA Considerations 819 This section provides guidance to the Internet Assigned Numbers 820 Authority (IANA) regarding registration of a new namespace for the 821 EAP Network Information attributes or prefixes, in accordance with 822 [7]. The initial attribute(s) are listed in Section 3. New 823 attributes or prefixes are assigned using the First Come Fist 824 Served policy defined in [8]. 826 Requests for new attribute names MUST be accompanied by a 827 reference to a publicly available description of the attribute 828 value syntax and semantics. 830 5. Security Considerations 832 Network Information delivered inside an EAP-Identity Request is 833 considered as a hint in guiding the WLAN Client to select the 834 desired MN. It SHOULD be treated similarly to the SSID in beacon 835 broadcast: subject to modification and spoofing. 837 It should also be noted that at least with some EAP methods, there 838 is no way for the HSN RADIUS server to verify that the MN used was 839 actually the same one that the WlAN client had requested. 841 6. Contributors 843 This document is a joint work of the contributing authors (in 844 alphabetical order): 846 - Farid Adrangi (Intel) 847 - Farooq Bari (AT&T Wireless) 848 - Adrian Buckley (Rim) 849 - Blair Bullock (iPass) 850 - Pasi Eronen (Nokia) 851 - Mark Grayson (Cisco) 852 - Victor Lortz (Intel) 853 - Jose Puthenkulam (Intel) 854 - Joe Salowey (Cisco) 855 - Marco Spini (Telecom Italia) 856 - Mark Watson (Nortel) 857 - Johanna Wild (Motorola) 859 7. Acknowledgements 861 The authors would like to thank Bernard Aboba (of Microsoft), and 862 Jari Arkko (of Ericsson), Jesse Walker (of Intel), Prakash Iyer 863 (of Intel), Dj Johnston (of Intel), Serge Manning (of Sprint), Ed 864 Van Horne (of Cisco), Antonio Ascolese (of Telecom Italia), Simone 865 Ruffino (Telecom Italia), Luca Dell'uomo (of Telecom Italia), 866 Luciana Costa (of Telecom Italia), Basavaraj Patil (of Nokia) for 867 their feedback and guidance. 869 8. References 871 [1] Rigney, C., Willens, S., Rubens, A. and W. Simpson, 872 "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, 874 June 2000. 876 [2] Calhoun, P., "Diameter Base Protocol", 877 draft-ietf-aaa-diameter-17 (work in progress), January 2003. 879 [3] Blunk, L. and J. Vollbrecht, "PPP Extensible 880 Authentication Protocol (EAP)", RFC 2284, March 1998. 882 [4] Aboba, B. and P. Calhoun, "RADIUS Support for Extensible 883 Authentication Protocol (EAP)", Internet draft (work in 884 progress), RFC 3579, September 2003. 886 [5] Aboba, B. and M. Beadles, "The Network Access Identifier", RFC 888 2486, January 1999. 890 [6] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. 892 [7] Crocker, D. and P. Overell, "Augmented BNF for Syntax 893 Specifications: ABNF", RFC 2234, November 1997. 895 [8] Narten, T. and H. Alvestrand, "Guidelines for Writing an 896 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 897 October 1998. 899 [9] Blunk, L., "Extensible Authentication Protocol (EAP)", draft- 900 ietf-eap-rfc2284bis-04 (work in progress), June 2003. 902 [10] Arkko, Jari, "The Network Access Identifier", RFC 904 2486bis, 905 Feburary 2004. 907 AuthorsÆ Addresses 909 Farid Adrangi 910 Intel Corporation 911 Email: farid.adrangi@intel.com 912 Phone:+1 503-712-1791 914 Full Copyright Statement 916 Copyright (C) The Internet Society (2002). All Rights 917 Reserved. 919 This document and translations of it may be copied and 920 furnished to others, and derivative works that comment on or 921 otherwise explain it or assist in its implementation may be 922 prepared, copied, published and distributed, in whole or in 923 part, without restriction of any kind, provided that the above 924 copyright notice and this paragraph are included on all such 925 copies and derivative works. However, this document itself may 926 not be modified in any way, such as by removing the copyright 927 notice or references to the Internet Society or other Internet 928 organizations, except as needed for the purpose of developing 929 Internet standards in which case the procedures for copyrights 930 defined in the Internet Standards process must be followed, or 931 as required to translate it into languages other than English. 933 The limited permissions granted above are perpetual and will 934 not be revoked by the Internet Society or its successors or 935 assigns. 937 This document and the information contained herein is provided 938 on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 939 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 940 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE 941 OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY 942 IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 943 PARTICULAR PURPOSE. 945 Acknowledgement 947 Funding for the RFC Editor function is currently provided by 948 the Internet Society.