idnits 2.17.1 draft-ietf-radext-rfc2486bis-01.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 594. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 571. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 578. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 584. ** 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 (October 19, 2004) is 7128 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '8' is defined on line 465, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2234 (ref. '3') (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 3490 (ref. '4') (Obsoleted by RFC 5890, RFC 5891) == Outdated reference: A later version (-10) exists of draft-ietf-sasl-saslprep-04 -- Obsolete informational reference (is this intentional?): RFC 821 (ref. '6') (Obsoleted by RFC 2821) -- Obsolete informational reference (is this intentional?): RFC 2486 (ref. '8') (Obsoleted by RFC 4282) -- Obsolete informational reference (is this intentional?): RFC 3588 (ref. '12') (Obsoleted by RFC 6733) == Outdated reference: A later version (-09) exists of draft-ietf-eap-netsel-problem-00 Summary: 7 errors (**), 0 flaws (~~), 6 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: April 19, 2005 M. Beadles 4 SmartPipes 5 J. Arkko 6 Ericsson 7 P. Eronen 8 Nokia 9 October 19, 2004 11 The Network Access Identifier 12 draft-ietf-radext-rfc2486bis-01 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 April 19, 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 . . . . . . . . . . . . . 6 70 2.4 International Character Sets . . . . . . . . . . . . . 7 71 2.5 Compatibility with E-Mail Usernames . . . . . . . . . 7 72 2.6 Compatibility with DNS . . . . . . . . . . . . . . . . 7 73 2.7 Realm Construction . . . . . . . . . . . . . . . . . . 8 74 2.8 Examples . . . . . . . . . . . . . . . . . . . . . . . 9 75 3. Security Considerations . . . . . . . . . . . . . . . . . . . 10 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, VPN usage, wireless LAN 90 authentication, and other applications. Interested parties have 91 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. 96 o National ISPs wishing to combine their operations with those of 97 one or more ISPs in another nation to offer more comprehensive 98 dialup service in a group of countries or on a continent. 99 o Wireless LAN hotspots providing service to one or more ISPs. 100 o Businesses desiring to offer their employees a comprehensive 101 package of dialup services on a global basis. Those services may 102 include Internet access as well as secure access to corporate 103 intranets via a Virtual Private Network (VPN), enabled by 104 tunneling protocols such as PPTP, L2F, L2TP, and IPsec tunnel 105 mode. 107 In order to enhance the interoperability of roaming services, it is 108 necessary to have a standardized method for identifying users. This 109 document defines syntax for the Network Access Identifier (NAI). 110 Examples of implementations that use the NAI, and descriptions of its 111 semantics, can be found in [7]. 113 This document is a revised version of RFC 2486 which originally 114 defined NAIs. Differences and enhancements compared to RFC 2486 are 115 listed in Appendix A. 117 1.1 Terminology 119 This document frequently uses the following terms: 120 Network Access Identifier 122 The Network Access Identifier (NAI) is the user identity submitted 123 by the client during network access authentication. In roaming, 124 the purpose of the NAI is to identify the user as well as to 125 assist in the routing of the authentication request. Please note 126 that the NAI may not necessarily be the same as the user's e-mail 127 address or the user identity submitted in an application layer 128 authentication. 129 Network Access Server 131 The Network Access Server (NAS) is the device that clients connect 132 to in order to get access to the network. In PPTP terminology 133 this is referred to as the PPTP Access Concentrator (PAC), and in 134 L2TP terminology, it is referred to as the L2TP Access 135 Concentrator (LAC). In IEEE 802.11, it is referred to as an 136 Access Point. 137 Roaming Capability 139 Roaming capability can be loosely defined as the ability to use 140 any one of multiple Internet service providers (ISPs), while 141 maintaining a formal, customer-vendor relationship with only one. 142 Examples of cases where roaming capability might be required 143 include ISP "confederations" and ISP- provided corporate network 144 access support. 145 Tunneling Service 147 A tunneling service is any network service enabled by tunneling 148 protocols such as PPTP, L2F, L2TP, and IPsec tunnel mode. One 149 example of a tunneling service is secure access to corporate 150 intranets via a Virtual Private Network (VPN). 152 1.2 Requirements language 154 In this document, the key words "MAY", "MUST, "MUST NOT", "OPTIONAL", 155 "RECOMMENDED", "SHOULD", and "SHOULD NOT", are to be interpreted as 156 described in [2]. 158 1.3 Purpose 160 As described in [7], there are a number of providers offering network 161 access services, and the number of Internet Service Providers 162 involved in roaming consortia is increasing rapidly. 164 In order to be able to offer roaming capability, one of the 165 requirements is to be able to identify the user's home authentication 166 server. For use in roaming, this function is accomplished via the 167 Network Access Identifier (NAI) submitted by the user to the NAS in 168 the initial network authentication. It is also expected that NASes 169 will use the NAI as part of the process of opening a new tunnel, in 170 order to determine the tunnel endpoint. 172 2. NAI Definition 174 2.1 Formal Syntax 176 The grammar for the NAI is given below, described in ABNF as 177 documented in [3]. The grammar for the username is based on [6], and 178 the grammar for the realm is an updated version of [1]. 180 nai = username 181 nai =/ "@" realm 182 nai =/ username "@" realm 184 username = dot-string 185 dot-string = string 186 dot-string =/ dot-string "." string 187 string = char 188 string =/ string char 189 char = c 190 char =/ "\" x 192 c = %x21 ; '!' allowed 193 ; '"' not allowed 194 c =/ %x23 ; '#' allowed 195 c =/ %x24 ; '$' allowed 196 c =/ %x25 ; '%' allowed 197 c =/ %x26 ; '&' allowed 198 c =/ %x27 ; ''' allowed 199 ; '(', ')' not allowed 200 c =/ %x2a ; '*' allowed 201 c =/ %x2b ; '+' allowed 202 ; ',' not allowed 203 c =/ %x2d ; '-' allowed 204 ; '.' not allowed 205 c =/ %x2f ; '/' allowed 206 c =/ %x30-39 ; '0'-'9' allowed 207 ; ';', ':', '<' not allowed 208 c =/ %x3d ; '=' allowed 209 ; '>' not allowed 210 c =/ %x3f ; '?' allowed 211 ; '@' not allowed 212 c =/ %x41-5a ; 'A'-'Z' allowed 213 ; '[', '\', ']' not allowed 214 c =/ %x5e ; '^' allowed 215 c =/ %x5f ; '_' allowed 216 c =/ %x60 ; '`' allowed 217 c =/ %x61-7a ; 'a'-'z' allowed 218 c =/ %x7b ; '{' allowed 219 c =/ %x7c ; '|' allowed 220 c =/ %x7d ; '}' allowed 221 c =/ %x7e ; '~' allowed 222 ; DEL not allowed 223 c =/ %x80-ff ; UTF-8 allowed (not in RFC 2486) 224 ; c must also satisfy rules in Section 2.4 225 x = %x00-FF ; all 128 ASCII characters, no exception; 226 ; as well as all UTF-8 characters (this 227 ; was not allowed in RFC 2486) 229 realm = 1*( label "." ) label 230 label = let-dig * (ldh-str) 231 ldh-str = *( alpha / digit / "-" ) let-dig 232 let-dig = alpha / digit 233 alpha = %x41-5A ; 'A'-'Z' 234 alpha =/ %x61-7A ; 'a'-'z' 235 digit = %x30-39 ; '0'-'9' 237 2.2 NAI Length Considerations 239 Devices handling NAIs MUST support an NAI length of at least 72 240 octets. Support for an NAI length of 253 octets is RECOMMENDED. 241 However, the following implementation issues should be considered: 242 o NAIs are often transported in the User-Name attribute of RADIUS. 243 Unfortunately, RFC 2865 [9] Section 5.1 states that "the ability 244 to handle at least 63 octets is recommended." As a result, it may 245 not be possible to transfer NAIs beyond 63 octets through all 246 devices. In addition, since only a single User-Name attribute may 247 be included in a RADIUS message and the maximum attribute length 248 is 253 octets, RADIUS is unable to support NAI lengths beyond 253 249 octets. 250 o NAIs can also be transported in the User-Name attribute of 251 Diameter [12], which supports content lengths up to 2^24 - 9 252 octets. As a result, NAIs processed only by Diameter nodes can be 253 very long. Unfortunately, an NAI transported over Diameter may 254 eventually be translated to RADIUS, in which case the above 255 limitations apply. 257 2.3 Support for Username Privacy 259 Interpretation of the "username" part of the NAI depends on the realm 260 in question. Therefore, the "username" part SHOULD be treated as 261 opaque data when processed by nodes that are not a part of the 262 authoritative domain (in the sense of Section 4) for that realm. 264 Where privacy is a concern, NAIs MAY be provided in an abbreviated 265 form by omitting the username portion. This is possible only when 266 NAIs are used together with a separate authentication method that can 267 transfer the username in a secure manner. 269 For roaming purposes it is typically necessary to locate the 270 appropriate backend authentication server for the given NAI before 271 the authentication conversation can proceed. As a result, the realm 272 portion is typically required in order for the authentication 273 exchange to be routed to the appropriate server. 275 2.4 International Character Sets 277 This specification allows both international usernames and realms. 278 International usernames are based on the use of Unicode characters, 279 encoded as UTF-8 and processed with a certain algorithm to ensure a 280 canonical representation. The realm part internationalization is 281 based on International Domain Name (IDN) [4]. 283 In order to ensure a canonical representation, characters of the 284 username portion in an NAI MUST fulfill the requirements specified in 285 [5]. In addition, the use of certain special characters (see grammar 286 rule c) are prohibited as well in order to retain compatibility with 287 the previous version of this RFC. 289 The realm name is an "IDN-unaware domain name slot" as defined in 290 [4]. That is, it can contain only ASCII characters. An 291 implementation MAY support internationalized domain names (IDNs) 292 using the ToASCII operation; see [4] for more information. 294 2.5 Compatibility with E-Mail Usernames 296 As proposed in this document, the Network Access Identifier is of the 297 form user@realm. Please note that while the user portion of the NAI 298 is based on the BNF described in [6], it has been extended for 299 internationalization support as well as for purposes of Section 2.7, 300 and is not necessarily compatible with the usernames used in e-mail. 301 Note also that the internationalization requirements for NAIs and 302 e-mail addresses are different, since the former need to be typed in 303 only by the user himself and his own operator, not by others. 305 2.6 Compatibility with DNS 307 The BNF of the realm portion allows the realm to begin with a digit, 308 which is not permitted by the BNF described in [1]. This change was 309 made to reflect current practice; although not permitted by the BNF 310 described in [1], FQDNs such as 3com.com are commonly used, and 311 accepted by current software. 313 2.7 Realm Construction 315 NAIs are used, among other purposes, for routing AAA transactions to 316 the user's home realm. Usually, the home realm appears in the realm 317 portion of the NAI, but in some cases a different realm can be used. 318 This may be useful, for instance, when the home realm is only 319 reachable via another mediating realm. 321 Such usage may prevent interoperability unless the parties involved 322 have a mutual agreement that the usage is allowed. In particular, 323 NAIs MUST NOT use a different realm than the home realm unless the 324 sender has explicit knowledge that (a) the specified other realm is 325 available and (b) the other realm supports such usage. The sender 326 may determine the fulfillment of these conditions through a database, 327 dynamic discovery, or other means not specified here. Note that the 328 first condition is affected by roaming, as the availability of the 329 other realm may depend on the user's location or the desired 330 application. 332 The use of the home realm MUST be the default unless otherwise 333 configured. 335 Where these conditions are fulfilled, an NAI such as 337 user@homerealm.example.net 339 MAY be represented as in 341 homerealm.example.net!user@otherrealm.example.net 343 In this case, the part before the (non-escaped) '!' MUST be a realm 344 name as defined in the ABNF in Section 2.1. When receiving such an 345 NAI, the other realm MUST convert the format back to 346 "user@homerealm.example.net" when passing the NAI forward, as well as 347 applying appropriate AAA routing for the transaction. 349 The conversion process may apply also recursively. That is, after 350 the conversion the result may still have one or more '!' characters 351 in the username. For instance, the NAI 353 other2.example.net!home.example.net!user@other1.example.net 355 would first be converted in other1.example.net to 357 home.example.net!user@other2.example.net 359 and then at other2.example.net finally to 360 user@homerealm.example.net 362 2.8 Examples 364 Examples of valid Network Access Identifiers include: 366 bob 367 joe@example.com 368 fred@foo-9.example.com 369 jack@3rd.depts.example.com 370 fred_smith@example.com 371 fred=?#$&*+-/^smith@example.com 372 nancy@eng.example.net 373 eng.example.net!nancy@example.net 374 eng%nancy@example.net 375 @privatecorp.example.net 376 alice@xn--tmonesimerkki-bfbb.example.net 378 The last example uses an IDN converted into an ASCII representation. 380 Examples of invalid Network Access Identifiers include: 382 fred@foo 383 fred@foo_9.com 384 fred@bigco.com@example.net 385 eng:nancy@example.net 386 eng;nancy@example.net 387 @example.net 389 3. Security Considerations 391 Since an NAI reveals the home affiliation of a user, it may assist an 392 attacker in further probing the username space. Typically this 393 problem is of most concern in protocols which transmit the user name 394 in clear-text across the Internet, such as in RADIUS, described in 395 [9] and [10]. In order to prevent snooping of the user name, 396 protocols may use confidentiality services provided by protocols 397 transporting them, such RADIUS protected by IPsec [11] or Diameter 398 protected by TLS [12]. 400 This specification adds the possibility of hiding the username part 401 in the NAI, by omitting it. As discussed in Section 2.3, this is 402 possible only when NAIs are used together with a separate 403 authentication method that can transfer the username in a secure 404 manner. In some cases application-specific privacy mechanism have 405 also been used with NAIs. For instance, some EAP methods apply a 406 method-specific pseudonyms in the username part of the NAI. While 407 neither of these approaches can protect the realm part, their 408 advantage over transport protection is that privacy of the username 409 is protected even through intermediate nodes such as NASes. 411 4. IANA Considerations 413 In order to to avoid creating any new administrative procedures, 414 administration of the NAI realm namespace piggybacks on the 415 administration of the DNS namespace. 417 NAI realm names are required to be unique and the rights to use a 418 given NAI realm for roaming purposes are obtained coincident with 419 acquiring the rights to use a particular fully qualified domain name 420 (FQDN). Those wishing to use an NAI realm name should first acquire 421 the rights to use the corresponding FQDN. Using an NAI realm without 422 ownership of the corresponding FQDN creates the possibility of 423 conflict and therefore is to be discouraged. 425 Note that the use of an FQDN as the realm name does not require use 426 of the DNS for location of the authentication server. While Diameter 427 [12] supports the use of DNS for location of authentication servers, 428 existing RADIUS implementations typically use proxy configuration 429 files in order to locate authentication servers within a domain and 430 perform authentication routing. The implementations described in [7] 431 did not use DNS for location of the authentication server within a 432 domain. Similarly, existing implementations have not found a need 433 for dynamic routing protocols, or propagation of global routing 434 information. Note also that there is no requirement that that the 435 NAI represent a valid email address. 437 5. References 439 5.1 Normative References 441 [1] Mockapetris, P., "Domain names - implementation and 442 specification", STD 13, RFC 1035, November 1987. 444 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 445 Levels", BCP 14, RFC 2119, March 1997. 447 [3] Crocker, D. and P. Overell, "Augmented BNF for Syntax 448 Specifications: ABNF", RFC 2234, November 1997. 450 [4] Faltstrom, P., Hoffman, P. and A. Costello, "Internationalizing 451 Domain Names in Applications (IDNA)", RFC 3490, March 2003. 453 [5] Zeilenga, K., "SASLprep: Stringprep profile for user names and 454 passwords", draft-ietf-sasl-saslprep-04 (work in progress), 455 October 2003. 457 5.2 Informative References 459 [6] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, 460 August 1982. 462 [7] Aboba, B., Lu, J., Alsop, J., Ding, J. and W. Wang, "Review of 463 Roaming Implementations", RFC 2194, September 1997. 465 [8] Aboba, B. and M. Beadles, "The Network Access Identifier", RFC 466 2486, January 1999. 468 [9] Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote 469 Authentication Dial In User Service (RADIUS)", RFC 2865, June 470 2000. 472 [10] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. 474 [11] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial 475 In User Service) Support For Extensible Authentication Protocol 476 (EAP)", RFC 3579, September 2003. 478 [12] Calhoun, P., Loughney, J., Guttman, E., Zorn, G. and J. Arkko, 479 "Diameter Base Protocol", RFC 3588, September 2003. 481 [13] Arkko, J. and B. Aboba, "Network Discovery and Selection within 482 the EAP Framework", draft-ietf-eap-netsel-problem-00 (work in 483 progress), January 2004. 485 Authors' Addresses 487 Bernard Aboba 488 Microsoft 489 One Microsoft Way 490 Redmond, WA 98052 491 USA 493 EMail: bernarda@microsoft.com 495 Mark A. Beadles 496 SmartPipes 497 565 Metro Place South Suite 300 498 Dublin OH 43017 499 USA 501 EMail: mbeadles@smartpipes.com 503 Jari Arkko 504 Ericsson 505 Jorvas 02420 506 Finland 508 EMail: jari.arkko@ericsson.com 510 Pasi Eronen 511 Nokia Research Center 512 P.O. Box 407 513 FIN-00045 Nokia Group 514 Finland 516 EMail: pasi.eronen@nokia.com 518 Appendix A. Changes from RFC 2486 520 This draft contains the following updates with respect to the 521 original NAI definition in RFC 2486: 522 o International character set support has been added for both 523 usernames and realms. Note that this implies character codes 128 524 - 255 may be used in the username portion, which may be 525 unacceptable to nodes that only support RFC 2486. Many devices 526 already allow this behaviour, however. 527 o Username privacy support has been added. Note that NAIs without a 528 username (for privacy) may not be acceptable to RFC 2486 compliant 529 nodes. Many devices already allow this behaviour, however. 530 o A recommendation to support NAI length of at least 253 octets has 531 been added, and compatibility considerations among NAI lengths in 532 this specification and various AAA protocols are discussed. Note 533 that long NAIs may not be acceptable to RFC 2486 compliant nodes. 534 o The mediating network syntax and its implications have been fully 535 described and not given only as an example. Note that this syntax 536 is not intended to be a full solution to network discovery and 537 selection needs as defined in [13]. Rather, it is intended as a 538 clarification of RFC 2486. 540 However, as discussed in Section 2.7, this specification requires 541 that this syntax be applied only when there is explicit knowledge 542 that the peer system supports such syntax. 543 o The realm BNF entry definition has been changed to avoid an error 544 (infinite recursion) in the original specification. 545 o Several clarifications and improvements have been incorporated to 546 the ABNF specification for NAIs. 548 Appendix B. Acknowledgements 550 Thanks to Glen Zorn for many useful discussions of this problem 551 space, and for Farid Adrangi and others for suggesting mediating 552 network representation in NAIs. Jonathan Rosenberg reported the BNF 553 error. Dale Worley suggested clarifications of the x and special BNF 554 entries. Arne Norefors reported the length differences between RFC 555 2486 and RFC 2865. Paul Hoffman helped with the international 556 character set issues. Kalle Tammela, Stefaan De Cnodder, Nagi 557 Jonnala, Bert Wijnen, Blair Bullock, Yoshihiro Ohba, Ignacio Goyret, 558 and Richard Perlman provided many useful comments on this draft. The 559 ABNF validator at http://www.apps.ietf.org/abnf.html was used to 560 verify the syntactic correctness of the ABNF in Section 2.1. 562 Intellectual Property Statement 564 The IETF takes no position regarding the validity or scope of any 565 Intellectual Property Rights or other rights that might be claimed to 566 pertain to the implementation or use of the technology described in 567 this document or the extent to which any license under such rights 568 might or might not be available; nor does it represent that it has 569 made any independent effort to identify any such rights. Information 570 on the procedures with respect to rights in RFC documents can be 571 found in BCP 78 and BCP 79. 573 Copies of IPR disclosures made to the IETF Secretariat and any 574 assurances of licenses to be made available, or the result of an 575 attempt made to obtain a general license or permission for the use of 576 such proprietary rights by implementers or users of this 577 specification can be obtained from the IETF on-line IPR repository at 578 http://www.ietf.org/ipr. 580 The IETF invites any interested party to bring to its attention any 581 copyrights, patents or patent applications, or other proprietary 582 rights that may cover technology that may be required to implement 583 this standard. Please address the information to the IETF at 584 ietf-ipr@ietf.org. 586 Disclaimer of Validity 588 This document and the information contained herein are provided on an 589 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 590 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 591 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 592 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 593 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 594 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 596 Copyright Statement 598 Copyright (C) The Internet Society (2004). This document is subject 599 to the rights, licenses and restrictions contained in BCP 78, and 600 except as set forth therein, the authors retain all their rights. 602 Acknowledgment 604 Funding for the RFC Editor function is currently provided by the 605 Internet Society.