idnits 2.17.00 (12 Aug 2021) /tmp/idnits34446/draft-arkko-roamops-rfc2486bis-00.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: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (February 9, 2004) is 6676 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) == Unused Reference: '9' is defined on line 409, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2052 (ref. '2') (Obsoleted by RFC 2782) ** Obsolete normative reference: RFC 2234 (ref. '4') (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 3490 (ref. '5') (Obsoleted by RFC 5890, RFC 5891) == Outdated reference: draft-ietf-sasl-saslprep has been published as RFC 4013 -- Obsolete informational reference (is this intentional?): RFC 821 (ref. '7') (Obsoleted by RFC 2821) -- Obsolete informational reference (is this intentional?): RFC 2486 (ref. '9') (Obsoleted by RFC 4282) -- Obsolete informational reference (is this intentional?): RFC 3588 (ref. '13') (Obsoleted by RFC 6733) == Outdated reference: draft-ietf-eap-netsel-problem has been published as RFC 5113 == Outdated reference: A later version (-01) exists of draft-adrangi-eap-network-discovery-and-selection-00 Summary: 4 errors (**), 0 flaws (~~), 7 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Extensible Authentication Protocol B. Aboba 2 Internet-Draft Microsoft 3 Expires: August 9, 2004 M. Beadles 4 WorldCom Advanced Networks 5 J. Arkko 6 Ericsson 7 P. Eronen 8 Nokia 9 February 9, 2004 11 The Network Access Identifier 12 draft-arkko-roamops-rfc2486bis-00 14 Status of this Memo 16 This document is an Internet-Draft and is in full conformance with 17 all provisions of Section 10 of RFC2026. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as 22 Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at http:// 30 www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on August 9, 2004. 37 Copyright Notice 39 Copyright (C) The Internet Society (2004). All Rights Reserved. 41 Abstract 43 In order to provide roaming services, it is necessary to have a 44 standardized method for identifying users. This document defines the 45 syntax for the Network Access Identifier (NAI), the user identity 46 submitted by the client during, for instance, PPP and wireless LAN 47 authentication. "Roaming" may be loosely defined as the ability to 48 use any one of multiple Internet service providers (ISPs), while 49 maintaining a formal, customer-vendor relationship with only one. 50 Examples of where roaming capabilities might be required include ISP 51 "confederations" and ISP-provided corporate network access support. 52 This document is a revised version of RFC 2486 which originally 53 defined NAIs. Enhancements include international character set and 54 privacy support, as well as a number of corrections to the original 55 RFC. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 61 1.2 Requirements language . . . . . . . . . . . . . . . . . . 4 62 1.3 Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 2. NAI Definition . . . . . . . . . . . . . . . . . . . . . . . . 5 64 2.1 Formal Syntax . . . . . . . . . . . . . . . . . . . . . . 5 65 2.2 NAI Length Considerations . . . . . . . . . . . . . . . . 6 66 2.3 Support for Username Privacy . . . . . . . . . . . . . . . 6 67 2.4 International Character Sets . . . . . . . . . . . . . . . 6 68 2.5 Compatibility with E-Mail Usernames . . . . . . . . . . . 7 69 2.6 Compatibility with DNS . . . . . . . . . . . . . . . . . . 7 70 2.7 Realm Construction . . . . . . . . . . . . . . . . . . . . 7 71 2.8 Examples . . . . . . . . . . . . . . . . . . . . . . . . . 8 72 3. Security Considerations . . . . . . . . . . . . . . . . . . . 9 73 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 74 Normative References . . . . . . . . . . . . . . . . . . . . . 11 75 Informative References . . . . . . . . . . . . . . . . . . . . 12 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 12 77 A. Changes from RFC 2486 . . . . . . . . . . . . . . . . . . . . 14 78 B. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 79 Intellectual Property and Copyright Statements . . . . . . . . 16 81 1. Introduction 83 Considerable interest exists for a set of features that fit within 84 the general category of "roaming capability" for dialup Internet 85 users, wireless LAN authentication, and other applications. 86 Interested parties have included: 88 o Regional Internet Service Providers (ISPs) operating within a 89 particular state or province, looking to combine their efforts 90 with those of other regional providers to offer dialup service 91 over a wider area. 93 o National ISPs wishing to combine their operations with those of 94 one or more ISPs in another nation to offer more comprehensive 95 dialup service in a group of countries or on a continent. 97 o Wireless LAN hotspots providing service to one or more ISPs. 99 o Businesses desiring to offer their employees a comprehensive 100 package of dialup services on a global basis. Those services may 101 include Internet access as well as secure access to corporate 102 intranets via a Virtual Private Network (VPN), enabled by 103 tunneling protocols such as PPTP, L2F, L2TP, and IPSEC tunnel 104 mode. 106 In order to enhance the interoperability of roaming services, it is 107 necessary to have a standardized method for identifying users. This 108 document defines syntax for the Network Access Identifier (NAI). 109 Examples of implementations that use the NAI, and descriptions of its 110 semantics, can be found in [8]. 112 This document is a revised version of RFC 2486 which originally 113 defined NAIs. Differences and enhancements compared to RFC 2486 are 114 listed in Appendix A. 116 1.1 Terminology 118 This document frequently uses the following terms: 120 Network Access Identifier 122 The Network Access Identifier (NAI) is the userID submitted by the 123 client during PPP authentication. In roaming, the purpose of the 124 NAI is to identify the user as well as to assist in the routing of 125 the authentication request. Please note that the NAI may not 126 necessarily be the same as the user's e-mail address or the userID 127 submitted in an application layer authentication. 129 Network Access Server 131 The Network Access Server (NAS) is the device that clients dial in 132 order to get access to the network. In PPTP terminology this is 133 referred to as the PPTP Access Concentrator (PAC), and in L2TP 134 terminology, it is referred to as the L2TP Access Concentrator 135 (LAC). 137 Roaming Capability 139 Roaming capability can be loosely defined as the ability to use 140 any one of multiple Internet service providers (ISPs), while 141 maintaining a formal, customer-vendor relationship with only one. 142 Examples of cases where roaming capability might be required 143 include ISP "confederations" and ISP- provided corporate network 144 access support. 146 Tunneling Service 148 A tunneling service is any network service enabled by tunneling 149 protocols such as PPTP, L2F, L2TP, and IPSEC tunnel mode. One 150 example of a tunneling service is secure access to corporate 151 intranets via a Virtual Private Network (VPN). 153 1.2 Requirements language 155 In this document, the key words "MAY", "MUST, "MUST NOT", "optional", 156 "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as 157 described in [3]. 159 1.3 Purpose 161 As described in [8], there are a number of services implementing 162 dialup roaming, and the number of Internet Service Providers involved 163 in roaming consortia is increasing rapidly. 165 In order to be able to offer roaming capability, one of the 166 requirements is to be able to identify the user's home authentication 167 server. For use in roaming, this function is accomplished via the 168 Network Access Identifier (NAI) submitted by the user to the NAS in 169 the initial PPP authentication. It is also expected that NASes will 170 use the NAI as part of the process of opening a new tunnel, in order 171 to determine the tunnel endpoint. 173 2. NAI Definition 175 2.1 Formal Syntax 177 The grammar for the NAI is given below, described in ABNF as 178 documented in [4]. The grammar for the username is based on [7], and 179 the grammar for the realm is an updated version of [1]. 181 nai = username / ( username "@" realm ) / ( "@" realm" ) 183 username = dot-istring 185 realm = [ realm "." ] ilabel 187 ilabel = let-dig * (ldh-str) 189 ldh-str = *( Alpha / Digit / "-" ) let-dig 191 dot-istring = istring / ( dot-istring "." istring ) 193 istring = ichar / ( string ichar ) 195 ichar = c / ( "\" x ) 197 let-dig = Alpha / Digit 199 Alpha = %x41-5A / %x61-7A ; A-Z / a-z 201 Digit = %x30-39 ;0-9 203 c = < a character as specified in 204 Section 2.4 205 > 207 x = %x00-7F 208 ; all 128 ASCII characters, no exception 210 SP = %x20 ; Space character 212 special = "<" / ">" / "(" / ")" / "[" / "]" / "\" / "." 213 / "," / ";" / ":" / "@" / %x22 / Ctl 214 ; %x22 is '"' 216 Ctl = %x00-1F / %x7F 217 ; the control characters (ASCII codes 0 through 31 218 ; inclusive and 127) 220 2.2 NAI Length Considerations 222 Devices handling NAIs MUST support an NAI length of at least 253 223 octets. However, the following interoperability considerations 224 should be noted: 226 o RFC 2486 required the support of NAIs only up to the length of 72 227 octets. As a result, it can generally not be assumed that all 228 devices can support 253 octets. 230 o NAIs are often transported in the User-Name attribute of RADIUS 231 [10]. Unfortunately, RADIUS requires devices to support content 232 lengths of only 63 octets for this attribute. As a result, it may 233 not be possible to transfer NAIs beyond 63 octets through all 234 devices. In addition, due to its message structure, RADIUS is 235 unable to support content lengths beyond 253 octets 237 o NAIs can also be transported in the User-Name attribute of 238 Diameter [13], which supports content lengths up to 2^24 - 9 239 octets. As a result, NAIs processed only by Diameter nodes can be 240 very long. Unfortunately, a NAI transported over Diameter may 241 eventually be translated to RADIUS, in which case the above 242 limitations apply. 244 2.3 Support for Username Privacy 246 Interpretation of the "username" part of the NAI depends on the realm 247 in question. Therefore, the "username" part SHOULD be treated as 248 opaque data when processed by nodes that are not authoritative (in 249 some sense) for that realm. 251 Where privacy is a concern, NAIs MAY be provided in an abbreviated 252 form by omitting the username portion. This is possible only when 253 NAIs are used in connection with a separate authentication method 254 that can transfer the username in a secure manner. 256 For roaming purposes it is typically necessary to locate the 257 appropriate backend authentication server for the given NAI before 258 the authentication conversation can proceed. As a result, realm 259 portion is typically required in order for the authentication 260 exchange to be routed to the appropriate server. 262 2.4 International Character Sets 264 Characters of the username portion in a NAI MUST fulfill the 265 requirements specified in [6]. In addition, the use of the SP 266 character is prohibited as well in order to retain compatibility with 267 the previous version of this RFC. 269 The realm name is an "IDN-unaware domain name slot" as defined in 270 [5]. That is, it can contain only ASCII characters. An 271 implementation MAY support internationalized domain names (IDNs) 272 using the ToASCII operation; see [5] for more information. 274 2.5 Compatibility with E-Mail Usernames 276 As proposed in this document, the Network Access Identifier is of the 277 form user@realm. Please note that while the user portion of the NAI 278 is based on the BNF described in [7], it has been extended for 279 internationalization support as well as for purposes of Section 2.7, 280 and is not necessarily compatible with the usernames used in e-mail. 281 Note also that the internationalization requirements for NAIs and 282 e-mail addresses are different, since the former need to be typed in 283 only by the user himself and his own operator, not by others. 285 2.6 Compatibility with DNS 287 The BNF of the realm portion allows the realm to begin with a digit, 288 which is not permitted by the BNF described in [1]. This change was 289 made to reflect current practice; although not permitted by the BNF 290 described in [1], FQDNs such as 3com.com are commonly used, and 291 accepted by current software. 293 2.7 Realm Construction 295 NAIs are used, among other purposes, for routing AAA transactions to 296 the user's home realm. Usually, the home realm appears in the realm 297 portion of the NAI, but in some cases a different realm can be used. 298 This may be useful, for instance, when the home realm is only 299 reachable via another mediating realm. 301 Such usage may prevent interoperability unless the parties involved 302 have a mutual agreement that the usage is allowed. In particular, 303 NAIs MUST NOT use a different realm than the home realm unless the 304 sender has explicit knowledge that (a) the specified other realm is 305 available and (b) the other realm supports such usage. The sender 306 may determine the fulfillment of these conditions through a database, 307 dynamic discovery, or other means not specified here. Note that the 308 first condition is affected by roaming, as the availability of the 309 other realm may depend on the user's location or the desired 310 application. The use of the home realm MUST be the default unless 311 otherwise configured. 313 Where these conditions are fulfilled, a NAI "user@homerealm" MAY be 314 represented as "homerealm!user@otherrealm". When receiving such NAI, 315 the other realm MUST convert the format back to "user@homerealm" when 316 passing the NAI onwards, as well as apply necessary AAA routing for 317 the transaction. 319 2.8 Examples 321 Examples of valid Network Access Identifiers include: 323 fred@3com.com 324 fred@foo-9.com 325 fred_smith@big-co.com 326 fred=?#$&*+-/^smith@bigco.com 327 fred@bigco.com 328 nancy@eng.bigu.edu 329 eng!nancy@bigu.edu 331 Examples of invalid Network Access Identifiers include: 333 fred@foo 334 fred@foo_9.com 335 @howard.edu 336 fred@bigco.com@smallco.com 337 eng:nancy@bigu.edu 338 eng;nancy@bigu.edu 339 @bigu.edu 341 3. Security Considerations 343 Since an NAI reveals the home affiliation of a user, it may assist an 344 attacker in further probing the username space. Typically this 345 problem is of most concern in protocols which transmit the user name 346 in clear-text across the Internet, such as in RADIUS, described in 347 [10] and [11]. In order to prevent snooping of the user name, 348 protocols may use confidentiality services provided by protocols 349 transporting them, such RADIUS protected by IPsec [12] or Diameter 350 protected by TLS [13]. 352 4. IANA Considerations 354 In order to to avoid creating any new administrative procedures, 355 administration of the NAI realm namespace piggybacks on the 356 administration of the DNS namespace. 358 NAI realm names are required to be unique and the rights to use a 359 given NAI realm for roaming purposes are obtained coincident with 360 acquiring the rights to use a particular fully qualified domain name 361 (FQDN). Those wishing to use an NAI realm name should first acquire 362 the rights to use the corresponding FQDN. Using an NAI realm without 363 ownership of the corresponding FQDN creates the possibility of 364 conflict and therefore is to be discouraged. 366 Note that the use of an FQDN as the realm name does not imply use of 367 the DNS for location of the authentication server or for 368 authentication routing. Since to date roaming has been implemented 369 on a relatively small scale, existing implementations typically 370 handle location of authentication servers within a domain and perform 371 authentication routing based on local knowledge expressed in proxy 372 configuration files. The implementations described in [8] have not 373 found a need for use of DNS for location of the authentication server 374 within a domain, although this can be accomplished via use of the DNS 375 SRV record, described in [2]. Similarly, existing implementations 376 have not found a need for dynamic routing protocols, or propagation 377 of global routing information. Note also that there is no 378 requirement that the NAI represent a valid email address. 380 Normative References 382 [1] Mockapetris, P., "Domain names - implementation and 383 specification", STD 13, RFC 1035, November 1987. 385 [2] Gulbrandsen, A. and P. Vixie, "A DNS RR for specifying the 386 location of services (DNS SRV)", RFC 2052, October 1996. 388 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement 389 Levels", BCP 14, RFC 2119, March 1997. 391 [4] Crocker, D. and P. Overell, "Augmented BNF for Syntax 392 Specifications: ABNF", RFC 2234, November 1997. 394 [5] Faltstrom, P., Hoffman, P. and A. Costello, "Internationalizing 395 Domain Names in Applications (IDNA)", RFC 3490, March 2003. 397 [6] Zeilenga, K., "SASLprep: Stringprep profile for user names and 398 passwords", draft-ietf-sasl-saslprep-04 (work in progress), 399 October 2003. 401 Informative References 403 [7] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, 404 August 1982. 406 [8] Aboba, B., Lu, J., Alsop, J., Ding, J. and W. Wang, "Review of 407 Roaming Implementations", RFC 2194, September 1997. 409 [9] Aboba, B. and M. Beadles, "The Network Access Identifier", RFC 410 2486, January 1999. 412 [10] Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote 413 Authentication Dial In User Service (RADIUS)", RFC 2865, June 414 2000. 416 [11] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. 418 [12] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial 419 In User Service) Support For Extensible Authentication Protocol 420 (EAP)", RFC 3579, September 2003. 422 [13] Calhoun, P., Loughney, J., Guttman, E., Zorn, G. and J. Arkko, 423 "Diameter Base Protocol", RFC 3588, September 2003. 425 [14] Arkko, J. and B. Aboba, "Network Discovery and Selection within 426 the EAP Framework", draft-ietf-eap-netsel-problem-00 (work in 427 progress), January 2004. 429 [15] Adrangi, F., "Network Discovery and Selection within the EAP 430 Framework", 431 draft-adrangi-eap-network-discovery-and-selection-00 (work in 432 progress), October 2003. 434 Authors' Addresses 436 Bernard Aboba 437 Microsoft 438 One Microsoft Way 439 Redmond, WA 98052 440 USA 442 EMail: aboba@internaut.com 443 Mark A. Beadles 444 WorldCom Advanced Networks 445 5000 Britton Rd. 446 Hilliard, OH 43026 447 USA 449 EMail: mbeadles@wcom.net 451 Jari Arkko 452 Ericsson 454 Jorvas 02420 455 Finland 457 EMail: jari.arkko@ericsson.com 459 Pasi Eronen 460 Nokia Research Center 461 P.O. Box 407 462 FIN-00045 Nokia Group 463 Finland 465 EMail: pasi.eronen@nokia.com 467 Appendix A. Changes from RFC 2486 469 This draft contains the following updates with respect to the 470 original NAI definition in RFC 2486: 472 o International character set support has been added for both 473 usernames and realms. 475 o Username privacy support has been added. 477 o A requirement to support NAI length of at least 253 octets has 478 been added, and compatibility considerations among NAI lengths in 479 this specification and various AAA protocols are discussed. 481 o The mediating network syntax and its implications have been fully 482 described and not given only as an example. Note that this syntax 483 is not intended to be a full solution to network discovery and 484 selection needs as defined in [14]. Rather, it is intended as a 485 clarification of RFC 2486. It could also be used as a component 486 in approaches such as [15]. 488 o The realm BNF entry definition has been changed to avoid an error 489 (infinite recursion) in the original specification. 491 o The x and special BNF entries have been clarified. 493 Appendix B. Acknowledgements 495 Thanks to Glen Zorn for many useful discussions of this problem 496 space, and for Farid Adrangi and others for suggesting mediating 497 network representation in NAIs. Jonathan Rosenberg reported the BNF 498 error. Dale Worley suggested clarifications of the x and special BNF 499 entries. Arne Norefors reported the length differences between RFC 500 2486 and RFC 2865. 502 Intellectual Property Statement 504 The IETF takes no position regarding the validity or scope of any 505 intellectual property or other rights that might be claimed to 506 pertain to the implementation or use of the technology described in 507 this document or the extent to which any license under such rights 508 might or might not be available; neither does it represent that it 509 has made any effort to identify any such rights. Information on the 510 IETF's procedures with respect to rights in standards-track and 511 standards-related documentation can be found in BCP-11. Copies of 512 claims of rights made available for publication and any assurances of 513 licenses to be made available, or the result of an attempt made to 514 obtain a general license or permission for the use of such 515 proprietary rights by implementors or users of this specification can 516 be obtained from the IETF Secretariat. 518 The IETF invites any interested party to bring to its attention any 519 copyrights, patents or patent applications, or other proprietary 520 rights which may cover technology that may be required to practice 521 this standard. Please address the information to the IETF Executive 522 Director. 524 Full Copyright Statement 526 Copyright (C) The Internet Society (2004). All Rights Reserved. 528 This document and translations of it may be copied and furnished to 529 others, and derivative works that comment on or otherwise explain it 530 or assist in its implementation may be prepared, copied, published 531 and distributed, in whole or in part, without restriction of any 532 kind, provided that the above copyright notice and this paragraph are 533 included on all such copies and derivative works. However, this 534 document itself may not be modified in any way, such as by removing 535 the copyright notice or references to the Internet Society or other 536 Internet organizations, except as needed for the purpose of 537 developing Internet standards in which case the procedures for 538 copyrights defined in the Internet Standards process must be 539 followed, or as required to translate it into languages other than 540 English. 542 The limited permissions granted above are perpetual and will not be 543 revoked by the Internet Society or its successors or assignees. 545 This document and the information contained herein is provided on an 546 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 547 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 548 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 549 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 550 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 552 Acknowledgement 554 Funding for the RFC Editor function is currently provided by the 555 Internet Society.