idnits 2.17.1 draft-dekok-radext-nai-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (9 September 2009) is 5343 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 3490 (Obsoleted by RFC 5890, RFC 5891) -- Obsolete informational reference (is this intentional?): RFC 3588 (Obsoleted by RFC 6733) -- Obsolete informational reference (is this intentional?): RFC 4282 (Obsoleted by RFC 7542) -- Obsolete informational reference (is this intentional?): RFC 5335 (Obsoleted by RFC 6532) == Outdated reference: A later version (-18) exists of draft-ietf-idnabis-protocol-15 Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group DeKok, Alan (Ed.) 3 INTERNET-DRAFT FreeRADIUS 4 Obsoletes: 4282 5 Category: Standards Track 6 7 9 September 2009 9 The Network Access Identifier 10 draft-dekok-radext-nai-00 12 This Internet-Draft is submitted to IETF in full conformance with the 13 provisions of BCP 78 and BCP 79. This document may contain material 14 from IETF Documents or IETF Contributions published or made publicly 15 available before November 10, 2008. The person(s) controlling the 16 copyright in some of this material may not have granted the IETF 17 Trust the right to allow modifications of such material outside the 18 IETF Standards Process. Without obtaining an adequate license from 19 the person(s) controlling the copyright in such materials, this 20 document may not be modified outside the IETF Standards Process, and 21 derivative works of it may not be created outside the IETF Standards 22 Process, except to format it for publication as an RFC or to 23 translate it into languages other than English. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that 27 other groups may also distribute working documents as Internet- 28 Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/ietf/1id-abstracts.txt. 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html. 41 This Internet-Draft will expire on September 1, 2009. 43 Copyright Notice 45 Copyright (c) 2009 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents in effect on the date of 50 publication of this document (http://trustee.ietf.org/license-info). 51 Please review these documents carefully, as they describe your rights 52 and restrictions with respect to this document. 54 Abstract 56 In order to provide roaming services, it is necessary to have a 57 standardized method for identifying users. This document defines the 58 syntax for the Network Access Identifier (NAI), the user identity 59 submitted by the client during network authentication. "Roaming" may 60 be loosely defined as the ability to use any one of multiple Internet 61 Service Providers (ISPs), while maintaining a formal, customer-vendor 62 relationship with only one. Examples of where roaming capabilities 63 might be required include ISP "confederations" and ISP-provided 64 corporate network access support. This document is a revised version 65 of RFC 4282, which addresses issues with international character 66 sets, as well as a number of other corrections to the previous RFC. 68 Table of Contents 70 Appendix A - Changes from RFC4282 ............................ 3 71 1. Introduction ............................................. 4 72 1.1. Terminology ......................................... 4 73 1.2. Requirements Language ............................... 5 74 1.3. Purpose ............................................. 6 75 1.4. Motivation .......................................... 6 76 2. NAI Definition ........................................... 7 77 2.1. UTF-8 Syntax and Normalization ...................... 7 78 2.2. Formal Syntax ....................................... 7 79 2.3. NAI Length Considerations ........................... 8 80 2.4. Support for Username Privacy ........................ 9 81 2.5. International Character Sets ........................ 9 82 2.6. The Normalization Process ........................... 10 83 2.7. Routing inside of AAA Systems ....................... 10 84 2.8. Compatibility with E-Mail Usernames ................. 11 85 2.9. Compatibility with DNS .............................. 11 86 2.10. Realm Construction ................................. 12 87 2.10.1. Historical Practices .......................... 12 88 2.11. Examples ........................................... 13 89 3. Security Considerations .................................. 14 90 4. IANA Considerations ...................................... 14 91 5. References ............................................... 15 92 5.1. Normative references ................................ 15 93 5.2. Informative references .............................. 16 94 Appendix A - Changes from RFC4282 ............................ 18 95 1. Introduction 97 Considerable interest exists for a set of features that fit within 98 the general category of "roaming capability" for network access, 99 including dialup Internet users, Virtual Private Network (VPN) usage, 100 wireless LAN authentication, and other applications. Interested 101 parties have included the following: 103 o Regional Internet Service Providers (ISPs) operating within a 104 particular state or province, looking to combine their efforts 105 with those of other regional providers to offer dialup service 106 over a wider area. 108 o National ISPs wishing to combine their operations with those of 109 one or more ISPs in another nation to offer more comprehensive 110 dialup service in a group of countries or on a continent. 112 o Wireless LAN hotspots providing service to one or more ISPs. 114 o Businesses desiring to offer their employees a comprehensive 115 package of dialup services on a global basis. Those services may 116 include Internet access as well as secure access to corporate 117 intranets via a VPN, enabled by tunneling protocols such as the 118 Point-to-Point Tunneling Protocol (PPTP) [RFC2637], the Layer 2 119 Forwarding (L2F) protocol [RFC2341], the Layer 2 Tunneling 120 Protocol (L2TP) [RFC2661], and the IPsec tunnel mode [RFC4301]. 122 In order to enhance the interoperability of roaming services, it is 123 necessary to have a standardized method for identifying users. This 124 document defines syntax for the Network Access Identifier (NAI). 125 Examples of implementations that use the NAI, and descriptions of its 126 semantics, can be found in [RFC2194]. 128 This document is a revised version of [RFC4282], which originally 129 defined internationalized NAIs. Differences and enhancements 130 compared to RFC 4282 are listed in Appendix A. 132 1.1. Terminology 134 This document frequently uses the following terms: 136 Network Access Identifier 138 The Network Access Identifier (NAI) is the user identity submitted 139 by the client during network access authentication. In roaming, 140 the purpose of the NAI is to identify the user as well as to 141 assist in the routing of the authentication request. Please note 142 that the NAI may not necessarily be the same as the user's e-mail 143 address or the user identity submitted in an application layer 144 authentication. 146 Network Access Server 148 The Network Access Server (NAS) is the device that clients connect 149 to in order to get access to the network. In PPTP terminology, 150 this is referred to as the PPTP Access Concentrator (PAC), and in 151 L2TP terminology, it is referred to as the L2TP Access 152 Concentrator (LAC). In IEEE 802.11, it is referred to as an 153 Access Point. 155 Roaming Capability 157 Roaming capability can be loosely defined as the ability to use 158 any one of multiple Internet Service Providers (ISPs), while 159 maintaining a formal, customer-vendor relationship with only one. 160 Examples of cases where roaming capability might be required 161 include ISP "confederations" and ISP-provided corporate network 162 access support. 164 Tunneling Service 166 A tunneling service is any network service enabled by tunneling 167 protocols such as PPTP, L2F, L2TP, and IPsec tunnel mode. One 168 example of a tunneling service is secure access to corporate 169 intranets via a Virtual Private Network (VPN). 171 1.2. Requirements Language 173 In this document, several words are used to signify the requirements 174 of the specification. The key words "MUST", "MUST NOT", "REQUIRED", 175 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 176 and "OPTIONAL" in this document are to be interpreted as described in 177 [RFC2119]. 179 1.3. Purpose 181 As described in [RFC2194], there are a number of providers offering 182 network access services, and the number of Internet Service Providers 183 involved in roaming consortia is increasing rapidly. 185 In order to be able to offer roaming capability, one of the 186 requirements is to be able to identify the user's home authentication 187 server. For use in roaming, this function is accomplished via the 188 Network Access Identifier (NAI) submitted by the user to the NAS in 189 the initial network authentication. It is also expected that NASes 190 will use the NAI as part of the process of opening a new tunnel, in 191 order to determine the tunnel endpoint. 193 1.4. Motivation 195 The changes from [RFC4282] are listed in detail in Appendix A. 196 However, some additional discussion is appropriate to motivate those 197 changes. 199 The motivation to revise [RFC4282] began with internationalization 200 concerns raised in the context of [EDUROAM]. Section 2.1 of 201 [RFC4282] defines ABNF for realms which limits the realm grammer to 202 English letters, digits, and the hyphen "-" character. The intent 203 appears to have been to encode, compare, and transport realms with 204 the ToASCII operation defined in [RFC3490]. There are a number of 205 problems with this approach: 207 o Section 2.1 did not contain ABNF for the UTF-8 form of the 208 realm. This makes it impossible to create an inter-operable 209 internationalized version of the realm. 211 o Section 2.5 required mappings that are language-specific, 212 and which are nearly impossible to perform correctly without 213 information about that language. 215 o Section 2.5 requires normalization of user names, which 216 may conflict with local system or administrative requirements. 218 o The recommendations in Section 2.5 for treatment of 219 bidirectional characters have proven to be unworkable. 221 o The prohibition against use of unassigned code points in 222 Section 2.5 effectively prohibits support for new scripts. 224 o The document's requirement that realms are ASCII conflicts 225 with the Extensible Authentication Protocol (EAP) and RADIUS, 226 which are both 8-bit clean, and which both recommend the use of 227 UTF-8 for identities. 229 o No Authentication, Authorization, and Accounting (AAA) 230 client, proxy, or server has implemented any of the requirements 231 in [RFC4282] Section 2.5, among other sections. 233 With international roaming growing in popularity, it is important for 234 these issues to be corrected in order to provide robust and inter- 235 operable network services. 237 2. NAI Definition 239 2.1. UTF-8 Syntax and Normalization 241 UTF-8 characters can be defined in terms of octets using the 242 following ABNF [RFC5234], taken from [RFC3629]: 244 UTF8-xtra-char = UTF8-2 / UTF8-3 / UTF8-4 246 UTF8-2 = %xC2-DF UTF8-tail 248 UTF8-3 = %xE0 %xA0-BF UTF8-tail / 249 %xE1-EC 2(UTF8-tail) / 250 %xED %x80-9F UTF8-tail / 251 %xEE-EF 2(UTF8-tail) 253 UTF8-4 = %xF0 %x90-BF 2( UTF8-tail ) / 254 %xF1-F3 3( UTF8-tail ) / 255 %xF4 %x80-8F 2( UTF8-tail ) 257 UTF8-tail = %x80-BF 259 These are normatively defined in [RFC3629], but are repeated in this 260 document for reasons of convenience. 262 See [RFC5198] for a discussion of normalization; the use of 263 normalization form NFC for NAIs is REQUIRED. 265 2.2. Formal Syntax 267 The grammar for the NAI is given below, described in Augmented 268 Backus-Naur Form (ABNF) as documented in [RFC5234]. The grammar for 269 the user and realm portion is based on a combination of the "nai" 270 defined in [RFC4282] Section 2.1, and the "utf8-addr-spec" defined in 271 [RFC5335] Section 4.4. 273 nai = utf8-username 274 nai =/ "@" utf8-realm 275 nai =/ utf8-username "@" utf8-realm 277 utf8-username = dot-string 278 dot-string = string 279 dot-string =/ dot-string "." string 280 string = utf8-atext 281 string =/ string utf8-atext 283 utf8-atext = ALPHA / DIGIT / 284 "!" / "#" / 285 "$" / "%" / 286 "&" / "'" / 287 "*" / "+" / 288 "-" / "/" / 289 "=" / "?" / 290 "^" / "_" / 291 "`" / "{" / 292 "|" / "}" / 293 "~" / 294 UTF8-xtra-char 296 utf8-realm = 1*( label "." ) label 298 label = utf8-rtext *(ldh-str) 299 ldh-str = *( utf8-rtext / "-" ) utf8-rtext 300 utf8-rtext = ALPHA / DIGIT / UTF8-xtra-char 301 .fi 303 2.3. NAI Length Considerations 305 Devices handling NAIs MUST support an NAI length of at least 72 306 octets. Support for an NAI length of 253 octets is RECOMMENDED. 307 However, the following implementation issues should be considered: 309 o NAIs are often transported in the User-Name attribute of the 310 Remote Authentication Dial-In User Service (RADIUS) protocol. 311 Unfortunately, RFC 2865 [RFC2865], Section 5.1, states that "the 312 ability to handle at least 63 octets is recommended." As a 313 result, it may not be possible to transfer NAIs beyond 63 octets 314 through all devices. In addition, since only a single User-Name 315 attribute may be included in a RADIUS message and the maximum 316 attribute length is 253 octets; RADIUS is unable to support NAI 317 lengths beyond 253 octets. 319 o NAIs can also be transported in the User-Name attribute of 320 Diameter [RFC3588], which supports content lengths up to 2^24 - 9 321 octets. As a result, NAIs processed only by Diameter nodes can be 322 very long. Unfortunately, an NAI transported over Diameter may 323 eventually be translated to RADIUS, in which case the above 324 limitations apply. 326 2.4. Support for Username Privacy 328 Interpretation of the username part of the NAI depends on the realm 329 in question. Therefore, the username portion SHOULD be treated as 330 opaque data when processed by nodes that are not a part of the 331 authoritative domain (in the sense of Section 4) for that realm. 333 In some situations, NAIs are used together with a separate 334 authentication method that can transfer the username part in a more 335 secure manner to increase privacy. In this case, NAIs MAY be 336 provided in an abbreviated form by omitting the username part. 337 Omitting the username part is RECOMMENDED over using a fixed username 338 part, such as "anonymous", since it provides an unambiguous way to 339 determine whether the username is intended to uniquely identify a 340 single user. 342 For roaming purposes, it is typically necessary to locate the 343 appropriate backend authentication server for the given NAI before 344 the authentication conversation can proceed. As a result, the realm 345 portion is typically required in order for the authentication 346 exchange to be routed to the appropriate server. 348 2.5. International Character Sets 350 This specification allows both international usernames and realms. 351 International usernames are based on the use of Unicode characters, 352 encoded as UTF-8. Internationalization of the realm portion of the 353 NAI is based on "Internationalized Email Headers" [RFC5335]. 355 In order to ensure a canonical representation, characters of the 356 username portion in an NAI MUST fulfill the ABNF in this 357 specification as well as the requirements specified in [IDNAbis]. In 358 practice, these requirements consist of the following item: 360 o Realms MUST be of the form that can be registered as a 361 Fully Qualified Domain Name (FQDN) within the DNS name system. 363 This list is significantly shorter, and simpler, than the list in 364 Section 2.5 of [RFC4282]. Specifying the realm requirements in this 365 way means that realm requirements depend on specifications that are 366 referenced here, rather than copied here. 368 In general, the restriction above means following the requirements as 369 specified in [IDNAbis]. However, that document is in flux at the 370 time of this writing, and the issues with [RFC4282] mandate a timely 371 update to it. 373 2.6. The Normalization Process 375 All normalization MUST be performed by end systems that take "local" 376 text as input. That is, text that is in an encoding other than 377 UTF-8, or that has locale-specific variations. In a network access 378 setting, such systems are typically the client (e.g. EAP supplicant) 379 and the Authentication, Authorization, and Accounting (AAA) server. 381 All other AAA systems (proxies, etc.) MUST NOT perform 382 normalization. These other systems do not have access to locale and 383 character set information that is available to end systems. 385 That is, all processing of NAIs from "local" character sets and 386 locales to UTF-8 is performed by edge systems, prior to the NAIs 387 entering the AAA system. Inside of an AAA system, NAIs are sent over 388 the wire in their canonical form, and this canonical form is used for 389 all NAI and/or realm comparisons. 391 In contrast to the comments in [RFC4282] Section 2.4, we expect AAA 392 systems to perform NAI comparisons, matching, and AAA routing based 393 on the NAI as it is received. This requirement provides a canonical 394 representation, ensures that intermediate systems such as AAA proxies 395 do not need to perform translations, and can be expected to work 396 through systems that are unaware of international character sets. 398 For example, much of the common realm routing can be done on the 399 "utf8-realm" portion of NAI, through simple checks for equality. 400 This routing can be done even if the AAA proxy is unaware of 401 internalized domain names. All that is required is for the AAA proxy 402 to be able to enter, store, and compare 8-bit data. 404 EAP supplicants MUST normalize user names that get placed in the EAP- 405 Response/Identity field. They MUST NOT copy localized text into that 406 field. This normalization SHOULD be performed once, and then cached 407 for subsequent use. 409 2.7. Routing inside of AAA Systems 411 Many systems require that the "utf8-realm" portion of the NAI be used 412 to route requests within a AAA proxy network. The semantics of this 413 operation involves a logical AAA routing table, where the 414 "utf8-realm" portion acts as a key, the contents of the table are one 415 or more "next hop" AAA servers. 417 Intermediate nodes MUST use the "utf8-realm" portion of the NAI 418 without modification to perform this lookup. Comparisons between the 419 NAI as given in a AAA packet, and as provisioned in a logical AAA 420 routing table SHOULD be done as a byte-for-byte equality test. The 421 "utf8-realm" provisioned in the logical AAA routing table SHOULD be 422 provisioned prior to the proxy receiving any AAA traffic, and SHOULD 423 be supplied by the "next hop" system that also supplies the other 424 information about the next hop. 426 This "next hop" information may be IP address, port, RADIUS shared 427 secret, TLS certificates, or a DNS host name. 429 2.8. Compatibility with E-Mail Usernames 431 As proposed in this document, the Network Access Identifier is of the 432 form user@realm. Please note that while the user portion of the NAI 433 is based on the BNF described in [RFC5198], it has been modified for 434 the purposes of Section 2.2, and does not permit quoted text along 435 with "folding" or "non-folding" whitespace that is commonly used in 436 email addresses. As such, it is not necessarily equivalent to 437 usernames used in e-mail. 439 However, it is a common practice to use email addresses as user 440 identifiers in AAA systems. The ABNF in Section 2.2 is defined to be 441 close to the "utf8-addr-spec" portion of [RFC5335], while still being 442 compatible with [RFC4282]. 444 In contrast to the comments in [RFC4282] Section 2.5, we state that 445 the internationalization requirements for NAIs and e-mail addresses 446 are substantially similar. Both of the NAI and email identifiers may 447 be the same, and need to be entered by the user himself and his own 448 operator. There is therefore good reason for the 449 internationalization requirements to be similar. 451 2.9. Compatibility with DNS 453 The "realm" portion of the NAI is intended to be compatible with 454 domain names used in DNS systems. However, the "realm" portion 455 within an AAA system is treated as a UTF-8 string, not as an ASCII 456 string for use within the DNS protocol. AAA systems MUST NOT use the 457 ToAscii function to encode the "utf8-realm" portion of the NAI within 458 an AAA protocol. 460 When the realm portion of the NAI is used as the basis for name 461 lookups within the DNS system, the ToASCII operation define in 462 [RFC3490] MAY be used to convert internationalized realm names to 463 ASCII. This function is normally handled by a DNS resolver library 464 on the local system. When this function is not handled by a DNS 465 resolver library, the AAA system MAY perform the ToAscii conversion 466 itself, before passing the modified realm name to the DNS resolver 467 library. 469 There are, however, a number of problems with this approach. A AAA 470 proxy may not have sufficient information in order to perform the 471 ToAscii conversion properly. We therefore RECOMMEND that only the 472 owner of the realm perform the ToAscii conversion. We RECOMMEND that 473 the owner of the realm pre-provision to all proxies the "utf8-realm" 474 portion of the NAI, along with the canonical form returned by the 475 ToAscii function. This canonical form can then be used in the 476 logical AAA routing table discussed above, in order to perform DNS 477 lookups 479 This last suggestion does not negate the benefits of using DNS to 480 automatically discover the location of a "next hop" AAA server. Many 481 AAA proxies require a business or legal relationship prior to routing 482 any traffic. This relationship can be leveraged to bootstrap the DNS 483 information located in the logical AAA routing table. 485 2.10. Realm Construction 487 The home realm usually appears in the realm portion of the NAI, but 488 in some cases a different realm can be used. This may be useful, for 489 instance, when the home realm is reachable only via intermediate 490 proxies. 492 Such usage may prevent interoperability unless the parties involved 493 have a mutual agreement that the usage is allowed. In particular, 494 NAIs MUST NOT use a different realm than the home realm unless the 495 sender has explicit knowledge that (a) the specified other realm is 496 available and (b) the other realm supports such usage. The sender 497 may determine the fulfillment of these conditions through a database, 498 dynamic discovery, or other means not specified here. Note that the 499 first condition is affected by roaming, as the availability of the 500 other realm may depend on the user's location or the desired 501 application. 503 The use of the home realm MUST be the default unless otherwise 504 configured. 506 2.10.1. Historical Practices 508 Some systems have historically used NAI modifications with multiple 509 "prefix" and "suffix" decorations to perform explicit routing through 510 multiple proxies inside of a AAA network. This practice is NOT 511 RECOMMENDED for the following reasons: 513 o Using explicit routing paths is fragile, and is unresponsive to 514 changes in the network due to servers going up or down, or to 515 changing business relationships. 517 o There is no RADIUS routing protocol, meaning that routing paths 518 have to be communicated "out of band" to all intermediate AAA 519 nodes, and also to all end-user systems (supplicants) expecting to 520 obtain network access. 522 o Using explicit routing paths requires thousands, if not 523 millions of end-user systems to be updated with new path 524 information when a AAA routing path changes. This adds huge 525 expense for updates that would be better done at only a few AAA 526 systems in the network. 528 o Manual updates to RADIUS paths are expensive, time-consuming, 529 and prone to error. 531 o Re-writing of the User-Name in AAA servers means that it may not 532 match the EAP-Response/Identity fields. This mismatch may cause 533 the home AAA server to reject the request as being malformed. 535 o Creating compatible formats for the NAI is difficult 536 when locally-defined "prefixes" and "suffixes" conflict with 537 similar practices elsewhere in the network. These conflices mean 538 that connecting two networks may be impossible in some cases, as 539 there is no way for packets to be routed properly in a way that 540 meets all requirements at all intermediate proxies. 542 o Leveraging the DNS name system for realm names establishes 543 a globally unique name space for realms. 545 In summary, network practices and capabilities have changed 546 significantly since NAIs were first overloaded to define AAA routes 547 through a network. While explicit path routing was once useful, the 548 time has come for better methods to be used. 550 2.11. Examples 552 Examples of valid Network Access Identifiers include the following: 554 bob 555 joe@example.com 556 fred@foo-9.example.com 557 jack@3rd.depts.example.com 558 fred.smith@example.com 559 fred_smith@example.com 560 fred$@example.com 561 fred=?#$&*+-/^smith@example.com 562 nancy@eng.example.net 563 eng.example.net!nancy@example.net 564 eng%nancy@example.net 565 @privatecorp.example.net 566 \(user\)@example.net 568 Examples of invalid Network Access Identifiers include the following: 570 fred@example 571 fred@example_9.com 572 fred@example.net@example.net 573 fred.@example.net 574 eng:nancy@example.net 575 eng;nancy@example.net 576 (user)@example.net 577 @example.net 578 One example given in [RFC4282] is still permitted by the ABNF, but it 579 is NOT RECOMMMENDED because of the use of the ToAscii function to 580 create an ASCII encoding from what is now a valid UTF-8 string. 582 alice@xn--tmonesimerkki-bfbb.example.net 584 3. Security Considerations 586 Since an NAI reveals the home affiliation of a user, it may assist an 587 attacker in further probing the username space. Typically, this 588 problem is of most concern in protocols that transmit the username in 589 clear-text across the Internet, such as in RADIUS, described in 590 [RFC2865] and [RFC2866]. In order to prevent snooping of the 591 username, protocols may use confidentiality services provided by 592 protocols transporting them, such as RADIUS protected by IPsec 593 [RFC3579] or Diameter protected by TLS [RFC3588]. 595 This specification adds the possibility of hiding the username part 596 in the NAI, by omitting it. As discussed in Section 2.4, this is 597 possible only when NAIs are used together with a separate 598 authentication method that can transfer the username in a secure 599 manner. In some cases, application-specific privacy mechanism have 600 also been used with NAIs. For instance, some EAP methods apply 601 method-specific pseudonyms in the username part of the NAI [RFC3748]. 602 While neither of these approaches can protect the realm part, their 603 advantage over transport protection is that privacy of the username 604 is protected, even through intermediate nodes such as NASes. 606 4. IANA Considerations 608 In order to avoid creating any new administrative procedures, 609 administration of the NAI realm namespace piggybacks on the 610 administration of the DNS namespace. 612 NAI realm names are required to be unique, and the rights to use a 613 given NAI realm for roaming purposes are obtained coincident with 614 acquiring the rights to use a particular Fully Qualified Domain Name 615 (FQDN). Those wishing to use an NAI realm name should first acquire 616 the rights to use the corresponding FQDN. Using an NAI realm without 617 ownership of the corresponding FQDN creates the possibility of 618 conflict and therefore is to be discouraged. 620 Note that the use of an FQDN as the realm name does not require use 621 of the DNS for location of the authentication server. While Diameter 622 [RFC3588] supports the use of DNS for location of authentication 623 servers, existing RADIUS implementations typically use proxy 624 configuration files in order to locate authentication servers within 625 a domain and perform authentication routing. The implementations 626 described in [RFC2194] did not use DNS for location of the 627 authentication server within a domain. Similarly, existing 628 implementations have not found a need for dynamic routing protocols 629 or propagation of global routing information. Note also that there 630 is no requirement that the NAI represent a valid email address. 632 5. References 634 5.1. Normative references 636 [RFC2119] 637 Bradner, S., "Key words for use in RFCs to Indicate Requirement 638 Levels", RFC 2119, March, 1997. 640 [RFC3490] 641 Faltstrom, P., Hoffman, P., and A. Costello, "Internationalizing 642 Domain Names in Applications (IDNA)", RFC 3490, March 2003. 644 [RFC3629] 645 Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, 646 RFC 3629, November 2003. 648 [RFC5198] 649 Klensin J., and Padlipsky M., "Unicode Format for Network 650 Interchange", RFC 5198, March 2008 652 [RFC5234] 653 Crocker, D. and P. Overell, "Augmented BNF for Syntax 654 Specifications: ABNF", RFC 5234, January 2008. 656 5.2. Informative references 658 [RFC2194] 659 Aboba, B., Lu, J., Alsop, J., Ding, J., and W. Wang, "Review of 660 Roaming Implementations", RFC 2194, September 1997. 662 [RFC2341] 663 Valencia, A., Littlewood, M., and T. Kolar, "Cisco Layer Two 664 Forwarding (Protocol) "L2F"", RFC 2341, May 1998. 666 [RFC2637] 667 Hamzeh, K., Pall, G., Verthein, W., Taarud, J., Little, W., and G. 668 Zorn, "Point-to-Point Tunneling Protocol", RFC 2637, July 1999. 670 [RFC2661] 671 Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G., and B. 672 Palter, "Layer Two Tunneling Protocol "L2TP"", RFC 2661, August 673 1999. 675 [RFC2865] 676 Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote 677 Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. 679 [RFC2866] 680 Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. 682 [RFC3579] 683 Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial In 684 User Service) Support For Extensible Authentication Protocol 685 (EAP)", RFC 3579, September 2003. 687 [RFC3588] 688 Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, 689 "Diameter Base Protocol", RFC 3588, September 2003. 691 [RFC3748] 692 Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 693 Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, 694 June 2004. 696 [RFC4282] 697 Aboba, B. et al., "The Network Access Identifier", RFC 4282, 698 December 2005. 700 [RFC4301] 701 Kent, S. and S. Keo, "Security Architecture for the Internet 702 Protocol", RFC 4301, December 2005. 704 [RFC5335] 705 Y. Abel, Ed., "Internationalized Email Headers", RFC 5335, 706 September 2008. 708 [EDUROAM] 709 http://eduroam.org, "eduroam (EDUcational ROAMing)" 711 [IDNAbis] 712 Klensin, J., "Internationalized Domain Names in Applications 713 (IDNA): Protocol", draft-ietf-idnabis-protocol-15.txt, (work in 714 progress) 716 Acknowledgments 718 The initial text for this document was [RFC4282], which was then 719 heavily edited. The original authors of [RFC4282] were Bernard 720 Aboba, Mark A. Beadles, Jari Arkko, and Pasi Eronen. 722 The ABNF validator at http://www.apps.ietf.org/abnf.html was used to 723 verify the syntactic correctness of the ABNF in Section 2. 725 Appendix A - Changes from RFC4282 727 This document contains the following updates with respect to the 728 previous NAI definition in RFC 4282 [RFC4282]: 730 o The formal syntax in Section 2.1 has been updated to forbid 731 non-UTF8 characters. e.g. characters with the "high bit" set. 733 o The formal syntax in Section 2.1 has been updated to allow 734 UTF-8 in the "realm" portion of the NAI. 736 o The formal syntax in [RFC4282] Section 2.1 applied to the 737 NAI after it was "internationalized" via the ToAscii function. 738 The contents of the NAI before it was "internationalized" were 739 left indeterminate. This document updates the formal syntax to 740 define an internationalized form of the NAI, and forbids the use 741 of the ToAscii function for NAI "internationalization". 743 o All use of the ToAscii function has been moved to normal 744 requirements on DNS implementations when realms are used as the 745 basis for DNS lookups. This involves no changes to the existing 746 DNS infrastructure. 748 o The discussions on internationalized character sets in Section 2.4 749 have been updated. The suggestion to use the ToAscii function for 750 realm comparisons has been removed. No AAA system implemented the 751 suggestion, so this change should have no operational impact. 753 o The section "Routing inside of AAA Systems" section is new in this 754 document. The concept of a "local AAA routing table" is also new, 755 although it accurately describes the functionality of wide-spread 756 implementations. 758 o The "Compatibility with E-Mail Usernames" and "Compatibility 759 with DNS" sections have been revised and updated. We now note 760 that the ToAscii function is required to be used only when a realm 761 name is used for DNS lookups, and even then the function is only 762 used by a DNS resolving library on the local system, and even then 763 we recommend that only the home network perform this conversion. 765 o The "Realm Construction" section has been updated to note 766 that editing of the NAI is NOT RECOMMENDED. 768 o The "Examples" section has been updated to remove the instance 769 of the IDN being converted to ASCII. This behavior is now 770 forbidden. 772 Authors' Addresses 773 Alan DeKok 774 The FreeRADIUS Server Project 776 Email: aland@freeradius.org