idnits 2.17.1 draft-ietf-radext-rfc2486bis-02.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 623. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 600. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 607. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 613. ** 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 : ---------------------------------------------------------------------------- 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 (November 4, 2004) is 7110 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 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 (==), 10 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 Expires: May 5, 2005 M. Beadles 4 SmartPipes 5 J. Arkko 6 Ericsson 7 P. Eronen 8 Nokia 9 November 4, 2004 11 The Network Access Identifier 12 draft-ietf-radext-rfc2486bis-02 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 May 5, 2005. 41 Copyright Notice 43 Copyright (C) The Internet Society (2004). 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 . . . . . . . . . . . 7 72 2.6 Compatibility with DNS . . . . . . . . . . . . . . . . . . 8 73 2.7 Realm Construction . . . . . . . . . . . . . . . . . . . . 8 74 2.8 Examples . . . . . . . . . . . . . . . . . . . . . . . . . 9 75 3. Security Considerations . . . . . . . . . . . . . . . . . . . 10 76 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 77 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 78 5.1 Normative References . . . . . . . . . . . . . . . . . . . . 11 79 5.2 Informative References . . . . . . . . . . . . . . . . . . . 11 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 12 81 A. Changes from RFC 2486 . . . . . . . . . . . . . . . . . . . . 12 82 B. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 83 Intellectual Property and Copyright Statements . . . . . . . . 15 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, VPN usage, wireless LAN 90 authentication, and other applications. Interested parties have 91 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 Virtual Private Network (VPN), enabled by 108 tunneling protocols such as PPTP, L2F, L2TP, and IPsec tunnel 109 mode. 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 ABNF as 185 documented in [RFC2234]. The grammar for the username is based on 186 [RFC0821], and the grammar for the realm is an updated version of 187 [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 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 allowed (not in RFC 2486) 234 ; c must also satisfy rules in Section 2.4 235 x = %x00-FF ; all 128 ASCII characters, no exception; 236 ; as well as all UTF-8 characters (this 237 ; was not allowed in RFC 2486) 239 realm = 1*( label "." ) label 240 label = let-dig * (ldh-str) 241 ldh-str = *( alpha / digit / "-" ) let-dig 242 let-dig = alpha / digit 243 alpha = %x41-5A ; 'A'-'Z' 244 alpha =/ %x61-7A ; 'a'-'z' 245 digit = %x30-39 ; '0'-'9' 247 2.2 NAI Length Considerations 249 Devices handling NAIs MUST support an NAI length of at least 72 250 octets. Support for an NAI length of 253 octets is RECOMMENDED. 251 However, the following implementation issues should be considered: 253 o NAIs are often transported in the User-Name attribute of RADIUS. 254 Unfortunately, RFC 2865 [RFC2865] Section 5.1 states that "the 255 ability to handle at least 63 octets is recommended." As a result, 256 it may not be possible to transfer NAIs beyond 63 octets through 257 all devices. In addition, since only a single User-Name attribute 258 may be included in a RADIUS message and the maximum attribute 259 length is 253 octets, RADIUS is unable to support NAI lengths 260 beyond 253 octets. 262 o NAIs can also be transported in the User-Name attribute of 263 Diameter [RFC3588], which supports content lengths up to 2^24 - 9 264 octets. As a result, NAIs processed only by Diameter nodes can be 265 very long. Unfortunately, an NAI transported over Diameter may 266 eventually be translated to RADIUS, in which case the above 267 limitations apply. 269 2.3 Support for Username Privacy 271 Interpretation of the "username" part of the NAI depends on the realm 272 in question. Therefore, the "username" part SHOULD be treated as 273 opaque data when processed by nodes that are not a part of the 274 authoritative domain (in the sense of Section 4) for that realm. 276 Where privacy is a concern, NAIs MAY be provided in an abbreviated 277 form by omitting the username portion. This is possible only when 278 NAIs are used together with a separate authentication method that can 279 transfer the username in a secure manner. 281 For roaming purposes it is typically necessary to locate the 282 appropriate backend authentication server for the given NAI before 283 the authentication conversation can proceed. As a result, the realm 284 portion is typically required in order for the authentication 285 exchange to be routed to the appropriate server. 287 2.4 International Character Sets 289 This specification allows both international usernames and realms. 290 International usernames are based on the use of Unicode characters, 291 encoded as UTF-8 and processed with a certain algorithm to ensure a 292 canonical representation. The realm part internationalization is 293 based on International Domain Name (IDN) [RFC3490]. 295 In order to ensure a canonical representation, characters of the 296 username portion in an NAI MUST fulfill the requirements specified in 297 [I-D.ietf-sasl-saslprep]. In addition, the use of certain special 298 characters (see grammar rule c) are prohibited as well in order to 299 retain compatibility with the previous version of this RFC. 301 The realm name is an "IDN-unaware domain name slot" as defined in 302 [RFC3490]. That is, it can contain only ASCII characters. An 303 implementation MAY support internationalized domain names (IDNs) 304 using the ToASCII operation; see [RFC3490] for more information. 306 2.5 Compatibility with E-Mail Usernames 308 As proposed in this document, the Network Access Identifier is of the 309 form user@realm. Please note that while the user portion of the NAI 310 is based on the BNF described in [RFC0821], it has been extended for 311 internationalization support as well as for purposes of Section 2.7, 312 and is not necessarily compatible with the usernames used in e-mail. 313 Note also that the internationalization requirements for NAIs and 314 e-mail addresses are different, since the former need to be typed in 315 only by the user himself and his own operator, not by others. 317 2.6 Compatibility with DNS 319 The BNF of the realm portion allows the realm to begin with a digit, 320 which is not permitted by the BNF described in [RFC1035]. This 321 change was made to reflect current practice; although not permitted 322 by the BNF described in [RFC1035], FQDNs such as 3com.com are 323 commonly used, and accepted by current software. 325 2.7 Realm Construction 327 NAIs are used, among other purposes, for routing AAA transactions to 328 the user's home realm. Usually, the home realm appears in the realm 329 portion of the NAI, but in some cases a different realm can be used. 330 This may be useful, for instance, when the home realm is only 331 reachable via another mediating realm. 333 Such usage may prevent interoperability unless the parties involved 334 have a mutual agreement that the usage is allowed. In particular, 335 NAIs MUST NOT use a different realm than the home realm unless the 336 sender has explicit knowledge that (a) the specified other realm is 337 available and (b) the other realm supports such usage. The sender 338 may determine the fulfillment of these conditions through a database, 339 dynamic discovery, or other means not specified here. Note that the 340 first condition is affected by roaming, as the availability of the 341 other realm may depend on the user's location or the desired 342 application. 344 The use of the home realm MUST be the default unless otherwise 345 configured. 347 Where these conditions are fulfilled, an NAI such as 349 user@homerealm.example.net 351 MAY be represented as in 353 homerealm.example.net!user@otherrealm.example.net 355 In this case, the part before the (non-escaped) '!' MUST be a realm 356 name as defined in the ABNF in Section 2.1. When receiving such an 357 NAI, the other realm MUST convert the format back to 358 "user@homerealm.example.net" when passing the NAI forward, as well as 359 applying appropriate AAA routing for the transaction. 361 The conversion process may apply also recursively. That is, after 362 the conversion the result may still have one or more '!' characters 363 in the username. For instance, the NAI 365 other2.example.net!home.example.net!user@other1.example.net 367 would first be converted in other1.example.net to 369 home.example.net!user@other2.example.net 371 and then at other2.example.net finally to 373 user@homerealm.example.net 375 2.8 Examples 377 Examples of valid Network Access Identifiers include: 379 bob 380 joe@example.com 381 fred@foo-9.example.com 382 jack@3rd.depts.example.com 383 fred.smith@example.com 384 fred_smith@example.com 385 fred$@example.com 386 fred=?#$&*+-/^smith@example.com 387 nancy@eng.example.net 388 eng.example.net!nancy@example.net 389 eng%nancy@example.net 390 @privatecorp.example.net 391 alice@xn--tmonesimerkki-bfbb.example.net 392 \(user\)@example.net 394 The last example uses an IDN converted into an ASCII representation. 396 Examples of invalid Network Access Identifiers include: 398 fred@example 399 fred@example_9.com 400 fred@example.net@example.net 401 fred.@example.net 402 eng:nancy@example.net 403 eng;nancy@example.net 404 (user)@example.net 405 @example.net 407 3. Security Considerations 409 Since an NAI reveals the home affiliation of a user, it may assist an 410 attacker in further probing the username space. Typically this 411 problem is of most concern in protocols which transmit the user name 412 in clear-text across the Internet, such as in RADIUS, described in 413 [RFC2865] and [RFC2866]. In order to prevent snooping of the user 414 name, protocols may use confidentiality services provided by 415 protocols transporting them, such RADIUS protected by IPsec [RFC3579] 416 or Diameter protected by TLS [RFC3588]. 418 This specification adds the possibility of hiding the username part 419 in the NAI, by omitting it. As discussed in Section 2.3, this is 420 possible only when NAIs are used together with a separate 421 authentication method that can transfer the username in a secure 422 manner. In some cases application-specific privacy mechanism have 423 also been used with NAIs. For instance, some EAP methods apply a 424 method-specific pseudonyms in the username part of the NAI. While 425 neither of these approaches can protect the realm part, their 426 advantage over transport protection is that privacy of the username 427 is protected even through intermediate nodes such as NASes. 429 4. IANA Considerations 431 In order to to avoid creating any new administrative procedures, 432 administration of the NAI realm namespace piggybacks on the 433 administration of the DNS namespace. 435 NAI realm names are required to be unique and the rights to use a 436 given NAI realm for roaming purposes are obtained coincident with 437 acquiring the rights to use a particular fully qualified domain name 438 (FQDN). Those wishing to use an NAI realm name should first acquire 439 the rights to use the corresponding FQDN. Using an NAI realm without 440 ownership of the corresponding FQDN creates the possibility of 441 conflict and therefore is to be discouraged. 443 Note that the use of an FQDN as the realm name does not require use 444 of the DNS for location of the authentication server. While Diameter 445 [RFC3588] supports the use of DNS for location of authentication 446 servers, existing RADIUS implementations typically use proxy 447 configuration files in order to locate authentication servers within 448 a domain and perform authentication routing. The implementations 449 described in [RFC2194] did not use DNS for location of the 450 authentication server within a domain. Similarly, existing 451 implementations have not found a need for dynamic routing protocols, 452 or propagation of global routing information. Note also that there 453 is no requirement that that the NAI represent a valid email address. 455 5. References 457 5.1 Normative References 459 [RFC1035] Mockapetris, P., "Domain names - implementation and 460 specification", STD 13, RFC 1035, November 1987. 462 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 463 Requirement Levels", BCP 14, RFC 2119, March 1997. 465 [RFC2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 466 Specifications: ABNF", RFC 2234, November 1997. 468 [RFC3490] Faltstrom, P., Hoffman, P. and A. Costello, 469 "Internationalizing Domain Names in Applications (IDNA)", 470 RFC 3490, March 2003. 472 [I-D.ietf-sasl-saslprep] 473 Zeilenga, K., "SASLprep: Stringprep profile for user names 474 and passwords", draft-ietf-sasl-saslprep-10 (work in 475 progress), July 2004. 477 5.2 Informative References 479 [RFC0821] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 480 821, August 1982. 482 [RFC2194] Aboba, B., Lu, J., Alsop, J., Ding, J. and W. Wang, 483 "Review of Roaming Implementations", RFC 2194, September 484 1997. 486 [RFC2486] Aboba, B. and M. Beadles, "The Network Access Identifier", 487 RFC 2486, January 1999. 489 [RFC2865] Rigney, C., Willens, S., Rubens, A. and W. Simpson, 490 "Remote Authentication Dial In User Service (RADIUS)", RFC 491 2865, June 2000. 493 [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. 495 [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication 496 Dial In User Service) Support For Extensible 497 Authentication Protocol (EAP)", RFC 3579, September 2003. 499 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G. and J. 500 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 502 [I-D.ietf-eap-netsel-problem] 503 Arkko, J. and B. Aboba, "Network Discovery and Selection 504 within the EAP Framework", 505 draft-ietf-eap-netsel-problem-02 (work in progress), 506 October 2004. 508 Authors' Addresses 510 Bernard Aboba 511 Microsoft 512 One Microsoft Way 513 Redmond, WA 98052 514 USA 516 EMail: bernarda@microsoft.com 518 Mark A. Beadles 519 SmartPipes 520 565 Metro Place South Suite 300 521 Dublin OH 43017 522 USA 524 EMail: mbeadles@smartpipes.com 526 Jari Arkko 527 Ericsson 528 Jorvas 02420 529 Finland 531 EMail: jari.arkko@ericsson.com 533 Pasi Eronen 534 Nokia Research Center 535 P.O. Box 407 536 FIN-00045 Nokia Group 537 Finland 539 EMail: pasi.eronen@nokia.com 541 Appendix A. Changes from RFC 2486 543 This draft contains the following updates with respect to the 544 original NAI definition in RFC 2486 [RFC2486]: 546 o International character set support has been added for both 547 usernames and realms. Note that this implies character codes 128 548 - 255 may be used in the username portion, which may be 549 unacceptable to nodes that only support RFC 2486. Many devices 550 already allow this behaviour, however. 552 o Username privacy support has been added. Note that NAIs without a 553 username (for privacy) may not be acceptable to RFC 2486 compliant 554 nodes. Many devices already allow this behaviour, however. 556 o A recommendation to support NAI length of at least 253 octets has 557 been added, and compatibility considerations among NAI lengths in 558 this specification and various AAA protocols are discussed. Note 559 that long NAIs may not be acceptable to RFC 2486 compliant nodes. 561 o The mediating network syntax and its implications have been fully 562 described and not given only as an example. Note that this syntax 563 is not intended to be a full solution to network discovery and 564 selection needs as defined in [I-D.ietf-eap-netsel-problem]. 565 Rather, it is intended as a clarification of RFC 2486. 567 However, as discussed in Section 2.7, this specification requires 568 that this syntax be applied only when there is explicit knowledge 569 that the peer system supports such syntax. 571 o The realm BNF entry definition has been changed to avoid an error 572 (infinite recursion) in the original specification. 574 o Several clarifications and improvements have been incorporated to 575 the ABNF specification for NAIs. 577 Appendix B. Acknowledgements 579 Thanks to Glen Zorn for many useful discussions of this problem 580 space, and for Farid Adrangi and others for suggesting mediating 581 network representation in NAIs. Jonathan Rosenberg reported the BNF 582 error. Dale Worley suggested clarifications of the x and special BNF 583 entries. Arne Norefors reported the length differences between RFC 584 2486 and RFC 2865. Paul Hoffman helped with the international 585 character set issues. Kalle Tammela, Stefaan De Cnodder, Nagi 586 Jonnala, Bert Wijnen, Blair Bullock, Yoshihiro Ohba, Ignacio Goyret, 587 and Richard Perlman provided many useful comments on this draft. The 588 ABNF validator at http://www.apps.ietf.org/abnf.html was used to 589 verify the syntactic correctness of the ABNF in Section 2.1. 591 Intellectual Property Statement 593 The IETF takes no position regarding the validity or scope of any 594 Intellectual Property Rights or other rights that might be claimed to 595 pertain to the implementation or use of the technology described in 596 this document or the extent to which any license under such rights 597 might or might not be available; nor does it represent that it has 598 made any independent effort to identify any such rights. Information 599 on the procedures with respect to rights in RFC documents can be 600 found in BCP 78 and BCP 79. 602 Copies of IPR disclosures made to the IETF Secretariat and any 603 assurances of licenses to be made available, or the result of an 604 attempt made to obtain a general license or permission for the use of 605 such proprietary rights by implementers or users of this 606 specification can be obtained from the IETF on-line IPR repository at 607 http://www.ietf.org/ipr. 609 The IETF invites any interested party to bring to its attention any 610 copyrights, patents or patent applications, or other proprietary 611 rights that may cover technology that may be required to implement 612 this standard. Please address the information to the IETF at 613 ietf-ipr@ietf.org. 615 Disclaimer of Validity 617 This document and the information contained herein are provided on an 618 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 619 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 620 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 621 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 622 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 623 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 625 Copyright Statement 627 Copyright (C) The Internet Society (2004). This document is subject 628 to the rights, licenses and restrictions contained in BCP 78, and 629 except as set forth therein, the authors retain all their rights. 631 Acknowledgment 633 Funding for the RFC Editor function is currently provided by the 634 Internet Society.