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