idnits 2.17.1 draft-ietf-radext-rfc2486bis-06.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 3978, Section 5.1 on line 20. -- Found old boilerplate from RFC 3978, Section 5.5 on line 705. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 682. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 689. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 695. ** 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. 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 : ---------------------------------------------------------------------------- -- The draft header indicates that this document obsoletes RFC2486, but the abstract doesn't seem to directly say this. It does mention RFC2486 though, so this could be OK. 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 (July 18, 2005) is 6854 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 (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 3490 (Obsoleted by RFC 5890, RFC 5891) -- Obsolete informational reference (is this intentional?): RFC 821 (Obsoleted by RFC 2821) -- Obsolete informational reference (is this intentional?): RFC 2401 (Obsoleted by RFC 4301) -- Obsolete informational reference (is this intentional?): RFC 2486 (Obsoleted by RFC 4282) -- Obsolete informational reference (is this intentional?): RFC 3588 (Obsoleted by RFC 6733) == Outdated reference: A later version (-09) exists of draft-ietf-eap-netsel-problem-02 Summary: 5 errors (**), 0 flaws (~~), 4 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group B. Aboba 3 Internet-Draft Microsoft 4 Obsoletes: 2486 (if approved) M. Beadles 5 Expires: January 19, 2006 SmartPipes 6 J. Arkko 7 Ericsson 8 P. Eronen 9 Nokia 10 July 18, 2005 12 The Network Access Identifier 13 draft-ietf-radext-rfc2486bis-06 15 Status of this Memo 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he or she is aware 19 have been or will be disclosed, and any of which he or she becomes 20 aware will be disclosed, in accordance with Section 6 of BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on January 19, 2006. 40 Copyright Notice 42 Copyright (C) The Internet Society (2005). 44 Abstract 46 In order to provide roaming services, it is necessary to have a 47 standardized method for identifying users. This document defines the 48 syntax for the Network Access Identifier (NAI), the user identity 49 submitted by the client during network authentication. "Roaming" may 50 be loosely defined as the ability to use any one of multiple Internet 51 Service Providers (ISPs), while maintaining a formal, customer-vendor 52 relationship with only one. Examples of where roaming capabilities 53 might be required include ISP "confederations" and ISP-provided 54 corporate network access support. This document is a revised version 55 of RFC 2486 which originally defined NAIs. Enhancements include 56 international character set and privacy support, as well as a number 57 of corrections to the original RFC. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 63 1.2 Requirements language . . . . . . . . . . . . . . . . . . 4 64 1.3 Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 2. NAI Definition . . . . . . . . . . . . . . . . . . . . . . . . 5 66 2.1 Formal Syntax . . . . . . . . . . . . . . . . . . . . . . 5 67 2.2 NAI Length Considerations . . . . . . . . . . . . . . . . 6 68 2.3 Support for Username Privacy . . . . . . . . . . . . . . . 7 69 2.4 International Character Sets . . . . . . . . . . . . . . . 7 70 2.5 Compatibility with E-Mail Usernames . . . . . . . . . . . 9 71 2.6 Compatibility with DNS . . . . . . . . . . . . . . . . . . 9 72 2.7 Realm Construction . . . . . . . . . . . . . . . . . . . . 9 73 2.8 Examples . . . . . . . . . . . . . . . . . . . . . . . . . 10 74 3. Security Considerations . . . . . . . . . . . . . . . . . . . 11 75 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 76 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 77 5.1 Normative References . . . . . . . . . . . . . . . . . . . 12 78 5.2 Informative References . . . . . . . . . . . . . . . . . . 13 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 14 80 A. Changes from RFC 2486 . . . . . . . . . . . . . . . . . . . . 14 81 B. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 82 Intellectual Property and Copyright Statements . . . . . . . . 17 84 1. Introduction 86 Considerable interest exists for a set of features that fit within 87 the general category of "roaming capability" for network access, 88 including dialup Internet users, Virtual Private Network (VPN) usage, 89 wireless LAN authentication, and other applications. Interested 90 parties have included: 92 o Regional Internet Service Providers (ISPs) operating within a 93 particular state or province, looking to combine their efforts 94 with those of other regional providers to offer dialup service 95 over a wider area. 97 o National ISPs wishing to combine their operations with those of 98 one or more ISPs in another nation to offer more comprehensive 99 dialup service in a group of countries or on a continent. 101 o Wireless LAN hotspots providing service to one or more ISPs. 103 o Businesses desiring to offer their employees a comprehensive 104 package of dialup services on a global basis. Those services may 105 include Internet access as well as secure access to corporate 106 intranets via a VPN, enabled by tunneling protocols such as Point- 107 to-Point Tunneling Protocol (PPTP) [RFC2637], Layer 2 Forwarding 108 (L2F) protocol [RFC2341], Layer 2 Tunneling Protocol (L2TP) 109 [RFC2661], and IPsec tunnel mode [RFC2401]. 111 In order to enhance the interoperability of roaming services, it is 112 necessary to have a standardized method for identifying users. This 113 document defines syntax for the Network Access Identifier (NAI). 114 Examples of implementations that use the NAI, and descriptions of its 115 semantics, can be found in [RFC2194]. 117 This document is a revised version of RFC 2486 [RFC2486] which 118 originally defined NAIs. Differences and enhancements compared to 119 RFC 2486 are listed in Appendix A. 121 1.1 Terminology 123 This document frequently uses the following terms: 125 Network Access Identifier 127 The Network Access Identifier (NAI) is the user identity submitted 128 by the client during network access authentication. In roaming, 129 the purpose of the NAI is to identify the user as well as to 130 assist in the routing of the authentication request. Please note 131 that the NAI may not necessarily be the same as the user's e-mail 132 address or the user identity submitted in an application layer 133 authentication. 135 Network Access Server 137 The Network Access Server (NAS) is the device that clients connect 138 to in order to get access to the network. In PPTP terminology 139 this is referred to as the PPTP Access Concentrator (PAC), and in 140 L2TP terminology, it is referred to as the L2TP Access 141 Concentrator (LAC). In IEEE 802.11, it is referred to as an 142 Access Point. 144 Roaming Capability 146 Roaming capability can be loosely defined as the ability to use 147 any one of multiple Internet service providers (ISPs), while 148 maintaining a formal, customer-vendor relationship with only one. 149 Examples of cases where roaming capability might be required 150 include ISP "confederations" and ISP-provided corporate network 151 access support. 153 Tunneling Service 155 A tunneling service is any network service enabled by tunneling 156 protocols such as PPTP, L2F, L2TP, and IPsec tunnel mode. One 157 example of a tunneling service is secure access to corporate 158 intranets via a Virtual Private Network (VPN). 160 1.2 Requirements language 162 In this document, the key words "MAY", "MUST, "MUST NOT", "OPTIONAL", 163 "RECOMMENDED", "SHOULD", and "SHOULD NOT", are to be interpreted as 164 described in [RFC2119]. 166 1.3 Purpose 168 As described in [RFC2194], there are a number of providers offering 169 network access services, and the number of Internet Service Providers 170 involved in roaming consortia is increasing rapidly. 172 In order to be able to offer roaming capability, one of the 173 requirements is to be able to identify the user's home authentication 174 server. For use in roaming, this function is accomplished via the 175 Network Access Identifier (NAI) submitted by the user to the NAS in 176 the initial network authentication. It is also expected that NASes 177 will use the NAI as part of the process of opening a new tunnel, in 178 order to determine the tunnel endpoint. 180 2. NAI Definition 182 2.1 Formal Syntax 184 The grammar for the NAI is given below, described in Augmented 185 Backus-Naur Form (ABNF) as documented in [RFC2234]. The grammar for 186 the username is based on [RFC0821], and the grammar for the realm is 187 an updated version of [RFC1035]. 189 nai = username 190 nai =/ "@" realm 191 nai =/ username "@" realm 193 username = dot-string 194 dot-string = string 195 dot-string =/ dot-string "." string 196 string = char 197 string =/ string char 198 char = c 199 char =/ "\" x 201 c = %x21 ; '!' allowed 202 ; '"' not allowed 203 c =/ %x23 ; '#' allowed 204 c =/ %x24 ; '$' allowed 205 c =/ %x25 ; '%' allowed 206 c =/ %x26 ; '&' allowed 207 c =/ %x27 ; ''' allowed 208 ; '(', ')' not allowed 209 c =/ %x2A ; '*' allowed 210 c =/ %x2B ; '+' allowed 211 ; ',' not allowed 212 c =/ %x2D ; '-' allowed 213 ; '.' not allowed 214 c =/ %x2F ; '/' allowed 215 c =/ %x30-39 ; '0'-'9' allowed 216 ; ';', ':', '<' not allowed 217 c =/ %x3D ; '=' allowed 218 ; '>' not allowed 219 c =/ %x3F ; '?' allowed 220 ; '@' not allowed 221 c =/ %x41-5a ; 'A'-'Z' allowed 222 ; '[', '\', ']' not allowed 223 c =/ %x5E ; '^' allowed 224 c =/ %x5F ; '_' allowed 225 c =/ %x60 ; '`' allowed 226 c =/ %x61-7A ; 'a'-'z' allowed 227 c =/ %x7B ; '{' allowed 228 c =/ %x7C ; '|' allowed 229 c =/ %x7D ; '}' allowed 230 c =/ %x7E ; '~' allowed 231 ; DEL not allowed 232 c =/ %x80-FF ; UTF-8-Octet allowed (not in RFC 2486) 233 ; Where UTF-8-octet is any octet in the 234 ; multi-octet UTF-8 representation of a 235 ; unicode codepoint above %x7F. 236 ; Note that c must also satisfy rules in 237 ; Section 2.4, including, for instance, 238 ; checking that no prohibited output is 239 ; used (see also Section 2.3 of 240 ; [I-D.ietf-sasl-saslprep]). 241 x = %x00-FF ; all 128 ASCII characters, no exception; 242 ; as well as all UTF-8-octets as defined 243 ; above (this was not allowed in 244 ; RFC 2486). Note that x must nevertheless 245 ; again satisfy the Section 2.4 rules. 247 realm = 1*( label "." ) label 248 label = let-dig *(ldh-str) 249 ldh-str = *( alpha / digit / "-" ) let-dig 250 let-dig = alpha / digit 251 alpha = %x41-5A ; 'A'-'Z' 252 alpha =/ %x61-7A ; 'a'-'z' 253 digit = %x30-39 ; '0'-'9' 255 2.2 NAI Length Considerations 257 Devices handling NAIs MUST support an NAI length of at least 72 258 octets. Support for an NAI length of 253 octets is RECOMMENDED. 259 However, the following implementation issues should be considered: 261 o NAIs are often transported in the User-Name attribute of Remote 262 Authentication Dial In User Service (RADIUS) protocol. 263 Unfortunately, RFC 2865 [RFC2865] Section 5.1 states that "the 264 ability to handle at least 63 octets is recommended." As a 265 result, it may not be possible to transfer NAIs beyond 63 octets 266 through all devices. In addition, since only a single User-Name 267 attribute may be included in a RADIUS message and the maximum 268 attribute length is 253 octets, RADIUS is unable to support NAI 269 lengths beyond 253 octets. 271 o NAIs can also be transported in the User-Name attribute of 272 Diameter [RFC3588], which supports content lengths up to 2^24 - 9 273 octets. As a result, NAIs processed only by Diameter nodes can be 274 very long. Unfortunately, an NAI transported over Diameter may 275 eventually be translated to RADIUS, in which case the above 276 limitations apply. 278 2.3 Support for Username Privacy 280 Interpretation of the "username" part of the NAI depends on the realm 281 in question. Therefore, the "username" part SHOULD be treated as 282 opaque data when processed by nodes that are not a part of the 283 authoritative domain (in the sense of Section 4) for that realm. 285 In some situations NAIs are are used together with a separate 286 authentication method that can transfer the username part in a more 287 secure manner to increase privacy. In this case, NAIs MAY be 288 provided in an abbreviated form by omitting the username part. 289 Omitting the username part is RECOMMENDED over using a fixed username 290 part, such as "anonymous", since it provides an unambiguous way to 291 determine whether the username is intended to uniquely identify a 292 single user. 294 For roaming purposes it is typically necessary to locate the 295 appropriate backend authentication server for the given NAI before 296 the authentication conversation can proceed. As a result, the realm 297 portion is typically required in order for the authentication 298 exchange to be routed to the appropriate server. 300 2.4 International Character Sets 302 This specification allows both international usernames and realms. 303 International usernames are based on the use of Unicode characters, 304 encoded as UTF-8 and processed with a certain algorithm to ensure a 305 canonical representation. The realm part internationalization is 306 based on International Domain Name (IDN) [RFC3490]. 308 In order to ensure a canonical representation, characters of the 309 username portion in an NAI MUST fulfill both the ABNF in this 310 specification as well as the requirements specified in [I-D.ietf- 311 sasl-saslprep]. These requirements consist of the following: 313 o Mapping requirements, as specified in Section 2.1 of [I-D.ietf- 314 sasl-saslprep]. Mapping consists of mapping certain characters to 315 others (such as SPACE) in order to increase the likelihood of 316 correctly performed comparisons. 318 o Normalization requirements, as specified in Section 2.2 of 319 [I-D.ietf-sasl-saslprep], also designed to assist comparisons. 321 o Prohibited output. Certain characters are not permitted in 322 correctly formed strings that follow Section 2.3 of [I-D.ietf- 323 sasl-saslprep]. Ensuring that NAIs conform to their ABNF is not 324 sufficient, it is also necessary to ensure that they do not 325 contain prohibited output. 327 o Bidirectional characters are handled as specified in Section 2.4 328 of [I-D.ietf-sasl-saslprep]. 330 o Unassigned code points are specified in Section 2.5 of [I-D.ietf- 331 sasl-saslprep]. The use of unassigned code points is prohibited. 333 The mapping, normalization, and bidirectional character processing 334 MUST be performed by end systems that take international text as 335 input. In a network access setting, such systems are typically the 336 client and the AAA server. NAIs are sent over the wire in their 337 canonical form, and tasks such as normalization do not typically need 338 to be performed by nodes that just pass NAIs around or receive them 339 from the network. End systems MUST also perform checking for 340 prohibited output and unassigned code points. Other systems MAY 341 perform such checks, when they know that a particular data item is a 342 NAI. 344 The realm name is an "IDN-unaware domain name slot" as defined in 345 [RFC3490]. That is, it can contain only ASCII characters. An 346 implementation MAY support internationalized domain names (IDNs) 347 using the ToASCII operation; see [RFC3490] for more information. 349 The responsibility for the conversion of international domain names 350 to ASCII is left for the end-systems, such as network access clients 351 and AAA servers. Similarly, we expect domain name comparisons, 352 matching, resolution, and AAA routing to be performed on the ASCII 353 versions of the international domain names. This provides a 354 canonical representation, ensures that intermediate systems such as 355 AAA proxies do not need to perform translations, and can be expected 356 to work through systems that are unaware of international character 357 sets. 359 2.5 Compatibility with E-Mail Usernames 361 As proposed in this document, the Network Access Identifier is of the 362 form user@realm. Please note that while the user portion of the NAI 363 is based on the BNF described in [RFC0821], it has been extended for 364 internationalization support as well as for purposes of Section 2.7, 365 and is not necessarily compatible with the usernames used in e-mail. 366 Note also that the internationalization requirements for NAIs and 367 e-mail addresses are different, since the former need to be typed in 368 only by the user himself and his own operator, not by others. 370 2.6 Compatibility with DNS 372 The BNF of the realm portion allows the realm to begin with a digit, 373 which is not permitted by the BNF described in [RFC1035]. This 374 change was made to reflect current practice; although not permitted 375 by the BNF described in [RFC1035], FQDNs such as 3com.com are 376 commonly used, and accepted by current software. 378 2.7 Realm Construction 380 NAIs are used, among other purposes, for routing AAA transactions to 381 the user's home realm. Usually, the home realm appears in the realm 382 portion of the NAI, but in some cases a different realm can be used. 383 This may be useful, for instance, when the home realm is only 384 reachable via another mediating realm. 386 Such usage may prevent interoperability unless the parties involved 387 have a mutual agreement that the usage is allowed. In particular, 388 NAIs MUST NOT use a different realm than the home realm unless the 389 sender has explicit knowledge that (a) the specified other realm is 390 available and (b) the other realm supports such usage. The sender 391 may determine the fulfillment of these conditions through a database, 392 dynamic discovery, or other means not specified here. Note that the 393 first condition is affected by roaming, as the availability of the 394 other realm may depend on the user's location or the desired 395 application. 397 The use of the home realm MUST be the default unless otherwise 398 configured. 400 Where these conditions are fulfilled, an NAI such as 402 user@homerealm.example.net 404 MAY be represented as in 406 homerealm.example.net!user@otherrealm.example.net 408 In this case, the part before the (non-escaped) '!' MUST be a realm 409 name as defined in the ABNF in Section 2.1. This realm name is an 410 "IDN-unaware domain name slot", just like the realm name after the 411 "@" character; see Section 2.4 for details. When receiving such an 412 NAI, the other realm MUST convert the format back to 413 "user@homerealm.example.net" when passing the NAI forward, as well as 414 applying appropriate AAA routing for the transaction. 416 The conversion process may apply also recursively. That is, after 417 the conversion the result may still have one or more '!' characters 418 in the username. For instance, the NAI 420 other2.example.net!home.example.net!user@other1.example.net 422 would first be converted in other1.example.net to 424 home.example.net!user@other2.example.net 426 and then at other2.example.net finally to 428 user@homerealm.example.net 430 Note that the syntax described in this section is optional, and is 431 not a part of the ABNF. The '!' character may appear in the username 432 portion of a NAI for other purposes as well, and in those cases the 433 rules outlined here do not apply; the interpretation of the username 434 is up to an agreement between the identified user and the realm given 435 after the '@' character. 437 2.8 Examples 439 Examples of valid Network Access Identifiers include: 441 bob 442 joe@example.com 443 fred@foo-9.example.com 444 jack@3rd.depts.example.com 445 fred.smith@example.com 446 fred_smith@example.com 447 fred$@example.com 448 fred=?#$&*+-/^smith@example.com 449 nancy@eng.example.net 450 eng.example.net!nancy@example.net 451 eng%nancy@example.net 452 @privatecorp.example.net 453 alice@xn--tmonesimerkki-bfbb.example.net 454 \(user\)@example.net 456 The last example uses an IDN converted into an ASCII representation. 458 Examples of invalid Network Access Identifiers include: 460 fred@example 461 fred@example_9.com 462 fred@example.net@example.net 463 fred.@example.net 464 eng:nancy@example.net 465 eng;nancy@example.net 466 (user)@example.net 467 @example.net 469 3. Security Considerations 471 Since an NAI reveals the home affiliation of a user, it may assist an 472 attacker in further probing the username space. Typically this 473 problem is of most concern in protocols which transmit the user name 474 in clear-text across the Internet, such as in RADIUS, described in 475 [RFC2865] and [RFC2866]. In order to prevent snooping of the user 476 name, protocols may use confidentiality services provided by 477 protocols transporting them, such RADIUS protected by IPsec [RFC3579] 478 or Diameter protected by TLS [RFC3588]. 480 This specification adds the possibility of hiding the username part 481 in the NAI, by omitting it. As discussed in Section 2.3, this is 482 possible only when NAIs are used together with a separate 483 authentication method that can transfer the username in a secure 484 manner. In some cases application-specific privacy mechanism have 485 also been used with NAIs. For instance, some Extensible 486 Authentication Protocol (EAP) methods apply method-specific 487 pseudonyms in the username part of the NAI [RFC3748]. While neither 488 of these approaches can protect the realm part, their advantage over 489 transport protection is that privacy of the username is protected 490 even through intermediate nodes such as NASes. 492 4. IANA Considerations 494 In order to to avoid creating any new administrative procedures, 495 administration of the NAI realm namespace piggybacks on the 496 administration of the DNS namespace. 498 NAI realm names are required to be unique and the rights to use a 499 given NAI realm for roaming purposes are obtained coincident with 500 acquiring the rights to use a particular Fully Qualified Domain Name 501 (FQDN). Those wishing to use an NAI realm name should first acquire 502 the rights to use the corresponding FQDN. Using an NAI realm without 503 ownership of the corresponding FQDN creates the possibility of 504 conflict and therefore is to be discouraged. 506 Note that the use of an FQDN as the realm name does not require use 507 of the DNS for location of the authentication server. While Diameter 508 [RFC3588] supports the use of DNS for location of authentication 509 servers, existing RADIUS implementations typically use proxy 510 configuration files in order to locate authentication servers within 511 a domain and perform authentication routing. The implementations 512 described in [RFC2194] did not use DNS for location of the 513 authentication server within a domain. Similarly, existing 514 implementations have not found a need for dynamic routing protocols, 515 or propagation of global routing information. Note also that there 516 is no requirement that that the NAI represent a valid email address. 518 5. References 520 5.1 Normative References 522 [RFC1035] Mockapetris, P., "Domain names - implementation and 523 specification", STD 13, RFC 1035, November 1987. 525 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 526 Requirement Levels", BCP 14, RFC 2119, March 1997. 528 [RFC2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 529 Specifications: ABNF", RFC 2234, November 1997. 531 [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, 532 "Internationalizing Domain Names in Applications (IDNA)", 533 RFC 3490, March 2003. 535 [I-D.ietf-sasl-saslprep] 536 Zeilenga, K., "SASLprep: Stringprep profile for user names 537 and passwords", draft-ietf-sasl-saslprep-10 (work in 538 progress), July 2004. 540 5.2 Informative References 542 [RFC0821] Postel, J., "Simple Mail Transfer Protocol", STD 10, 543 RFC 821, August 1982. 545 [RFC2194] Aboba, B., Lu, J., Alsop, J., Ding, J., and W. Wang, 546 "Review of Roaming Implementations", RFC 2194, 547 September 1997. 549 [RFC2341] Valencia, A., Littlewood, M., and T. Kolar, "Cisco Layer 550 Two Forwarding (Protocol) "L2F"", RFC 2341, May 1998. 552 [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the 553 Internet Protocol", RFC 2401, November 1998. 555 [RFC2486] Aboba, B. and M. Beadles, "The Network Access Identifier", 556 RFC 2486, January 1999. 558 [RFC2637] Hamzeh, K., Pall, G., Verthein, W., Taarud, J., Little, 559 W., and G. Zorn, "Point-to-Point Tunneling Protocol", 560 RFC 2637, July 1999. 562 [RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, 563 G., and B. Palter, "Layer Two Tunneling Protocol "L2TP"", 564 RFC 2661, August 1999. 566 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 567 "Remote Authentication Dial In User Service (RADIUS)", 568 RFC 2865, June 2000. 570 [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. 572 [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication 573 Dial In User Service) Support For Extensible 574 Authentication Protocol (EAP)", RFC 3579, September 2003. 576 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. 577 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 579 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 580 Levkowetz, "Extensible Authentication Protocol (EAP)", 581 RFC 3748, June 2004. 583 [I-D.ietf-eap-netsel-problem] 584 Arkko, J. and B. Aboba, "Network Discovery and Selection 585 within the EAP Framework", 586 draft-ietf-eap-netsel-problem-02 (work in progress), 587 October 2004. 589 Authors' Addresses 591 Bernard Aboba 592 Microsoft 593 One Microsoft Way 594 Redmond, WA 98052 595 USA 597 Email: bernarda@microsoft.com 599 Mark A. Beadles 600 SmartPipes 601 565 Metro Place South Suite 300 602 Dublin OH 43017 603 USA 605 Email: mbeadles@smartpipes.com 607 Jari Arkko 608 Ericsson 609 Jorvas 02420 610 Finland 612 Email: jari.arkko@ericsson.com 614 Pasi Eronen 615 Nokia Research Center 616 P.O. Box 407 617 FIN-00045 Nokia Group 618 Finland 620 Email: pasi.eronen@nokia.com 622 Appendix A. Changes from RFC 2486 624 This draft contains the following updates with respect to the 625 original NAI definition in RFC 2486 [RFC2486]: 627 o International character set support has been added for both 628 usernames and realms. Note that this implies character codes 128 629 - 255 may be used in the username portion, which may be 630 unacceptable to nodes that only support RFC 2486. Many devices 631 already allow this behaviour, however. 633 o Username privacy support has been added. Note that NAIs without a 634 username (for privacy) may not be acceptable to RFC 2486 compliant 635 nodes. Many devices already allow this behaviour, however. 637 o A recommendation to support NAI length of at least 253 octets has 638 been added, and compatibility considerations among NAI lengths in 639 this specification and various AAA protocols are discussed. Note 640 that long NAIs may not be acceptable to RFC 2486 compliant nodes. 642 o The mediating network syntax and its implications have been fully 643 described and not given only as an example. Note that this syntax 644 is not intended to be a full solution to network discovery and 645 selection needs as defined in [I-D.ietf-eap-netsel-problem]. 646 Rather, it is intended as a clarification of RFC 2486. 648 However, as discussed in Section 2.7, this specification requires 649 that this syntax be applied only when there is explicit knowledge 650 that the peer system supports such syntax. 652 o The realm BNF entry definition has been changed to avoid an error 653 (infinite recursion) in the original specification. 655 o Several clarifications and improvements have been incorporated to 656 the ABNF specification for NAIs. 658 Appendix B. Acknowledgements 660 Thanks to Glen Zorn for many useful discussions of this problem 661 space, and to Farid Adrangi for suggesting the representation of 662 mediating networks in NAIs. Jonathan Rosenberg reported the BNF 663 error. Dale Worley suggested clarifications of the x and special BNF 664 entries. Arne Norefors reported the length differences between RFC 665 2486 and RFC 2865. Paul Hoffman helped with the international 666 character set issues. Kalle Tammela, Stefaan De Cnodder, Nagi 667 Jonnala, Bert Wijnen, Blair Bullock, Yoshihiro Ohba, Ignacio Goyret, 668 John Loughney, Henrik Levkowetz, Ted Hardie, Bill Fenner, Sam 669 Hartman, and Richard Perlman provided many useful comments on this 670 draft. The ABNF validator at http://www.apps.ietf.org/abnf.html was 671 used to verify the syntactic correctness of the ABNF in Section 2.1. 673 Intellectual Property Statement 675 The IETF takes no position regarding the validity or scope of any 676 Intellectual Property Rights or other rights that might be claimed to 677 pertain to the implementation or use of the technology described in 678 this document or the extent to which any license under such rights 679 might or might not be available; nor does it represent that it has 680 made any independent effort to identify any such rights. Information 681 on the procedures with respect to rights in RFC documents can be 682 found in BCP 78 and BCP 79. 684 Copies of IPR disclosures made to the IETF Secretariat and any 685 assurances of licenses to be made available, or the result of an 686 attempt made to obtain a general license or permission for the use of 687 such proprietary rights by implementers or users of this 688 specification can be obtained from the IETF on-line IPR repository at 689 http://www.ietf.org/ipr. 691 The IETF invites any interested party to bring to its attention any 692 copyrights, patents or patent applications, or other proprietary 693 rights that may cover technology that may be required to implement 694 this standard. Please address the information to the IETF at 695 ietf-ipr@ietf.org. 697 Disclaimer of Validity 699 This document and the information contained herein are provided on an 700 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 701 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 702 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 703 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 704 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 705 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 707 Copyright Statement 709 Copyright (C) The Internet Society (2005). This document is subject 710 to the rights, licenses and restrictions contained in BCP 78, and 711 except as set forth therein, the authors retain all their rights. 713 Acknowledgment 715 Funding for the RFC Editor function is currently provided by the 716 Internet Society.