idnits 2.17.1 draft-ietf-radext-nai-15.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 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 (17 December 2014) is 3380 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 informational reference (is this intentional?): RFC 4282 (Obsoleted by RFC 7542) -- Obsolete informational reference (is this intentional?): RFC 5335 (Obsoleted by RFC 6532) Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 RADEXT Working Group DeKok, Alan 3 INTERNET-DRAFT FreeRADIUS 4 Obsoletes: 4282 5 Category: Standards Track 6 7 17 December 2014 9 The Network Access Identifier 10 draft-ietf-radext-nai-15 12 Abstract 14 In order to provide inter-domain authentication services, it is 15 necessary to have a standardized method that domains can use to 16 identify each other's users. This document defines the syntax for 17 the Network Access Identifier (NAI), the user identifier submitted by 18 the client prior to accessing resources. This document is a revised 19 version of RFC 4282, which addresses issues with international 20 character sets, as well as a number of other corrections to the 21 previous document. 23 Status of this Memo 25 This Internet-Draft is submitted to IETF in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF), its areas, and its working groups. Note that 30 other groups may also distribute working documents as Internet- 31 Drafts. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 The list of current Internet-Drafts can be accessed at 39 http://www.ietf.org/ietf/1id-abstracts.txt. 41 The list of Internet-Draft Shadow Directories can be accessed at 42 http://www.ietf.org/shadow.html. 44 This Internet-Draft will expire on June 17, 2015. 46 Copyright Notice 48 Copyright (c) 2014 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 This document may contain material from IETF Documents or IETF 62 Contributions published or made publicly available before November 63 10, 2008. The person(s) controlling the copyright in some of this 64 material may not have granted the IETF Trust the right to allow 65 modifications of such material outside the IETF Standards Process. 66 Without obtaining an adequate license from the person(s) controlling 67 the copyright in such materials, this document may not be modified 68 outside the IETF Standards Process, and derivative works of it may 69 not be created outside the IETF Standards Process, except to format 70 it for publication as an RFC or to translate it into languages other 71 than English. 73 Table of Contents 75 Appendix A - Changes from RFC4282 ............................ 3 76 1. Introduction ............................................. 4 77 1.1. Terminology ......................................... 6 78 1.2. Requirements Language ............................... 7 79 1.3. Purpose ............................................. 8 80 1.4. Motivation .......................................... 9 81 2. NAI Definition ........................................... 10 82 2.1. UTF-8 Syntax and Normalization ...................... 10 83 2.2. Formal Syntax ....................................... 11 84 2.3. NAI Length Considerations ........................... 11 85 2.4. Support for Username Privacy ........................ 12 86 2.5. International Character Sets ........................ 13 87 2.6. The Normalization Process ........................... 14 88 2.6.1. Issues with the Normalization Process .......... 15 89 2.7. Use in Other Protocols .............................. 16 90 2.8. Using the NAI format for other identifiers .......... 17 91 3. Routing inside of AAA Systems ............................ 18 92 3.1. Compatibility with Email Usernames .................. 19 93 3.2. Compatibility with DNS .............................. 19 94 3.3. Realm Construction .................................. 20 95 3.3.1. Historical Practices ........................... 21 96 3.4. Examples ............................................ 22 97 4. Security Considerations .................................. 23 98 4.1. Correlation of Identities over Time and Protocols ... 23 99 4.2. Multiple Identifiers ................................ 23 100 5. Administration of Names .................................. 24 101 6. IANA Considerations ...................................... 25 102 7. References ............................................... 25 103 7.1. Normative References ................................ 25 104 7.2. Informative References .............................. 26 105 Appendix A - Changes from RFC4282 ............................ 29 106 1. Introduction 108 Considerable interest exists for a set of features that fit within 109 the general category of inter-domain authentication, or "roaming 110 capability" for network access, including dialup Internet users, 111 Virtual Private Network (VPN) usage, wireless LAN authentication, and 112 other applications. 114 By "inter-domain authentication", this document refers to situations 115 where a user has authentication credentials at one "home" domain, but 116 is able to present them at a second "visited" domain to access 117 certain services at the visited domain. The two domains generally 118 have a pre-existing relationship, so that the credentials can be 119 passed from the visited domain to the home domain for verification. 120 The home domain typically responds with a permit / deny response, 121 which may also include authorization parameters which the visited 122 domain is expected to enforce on the user. 124 That is, the "roaming" scenario involves a user visiting, or 125 "roaming" to a non-home domain, and requesting the use of services at 126 that visted domain. 128 Interested parties have included the following: 130 * Regional Internet Service Providers (ISPs) operating within a 131 particular state or province, looking to combine their efforts 132 with those of other regional providers to offer dialup service 133 over a wider area. 135 * Telecommunications companies who wish to combine their 136 operations with those of one or more companies in another areas or 137 nations, in order to offer more comprehensive network access 138 service in areas where there is no native service. e.g. In 139 another country. 141 * Wireless LAN hotspots providing service to one or more ISPs. 143 * Businesses desiring to offer their employees a comprehensive 144 package of dialup services on a global basis. Those services may 145 include Internet access as well as secure access to corporate 146 intranets via a VPN, enabled by tunneling protocols such as the 147 Point-to-Point Tunneling Protocol (PPTP) [RFC2637], the Layer 2 148 Forwarding (L2F) protocol [RFC2341], the Layer 2 Tunneling 149 Protocol (L2TP) [RFC2661], and the IPsec tunnel mode [RFC4301]. 151 * Other protocols which are interested in leveraging the users 152 credentials in order to take advantage of an existing 153 authentication framework. 155 In order to enhance the interoperability of these services, it is 156 necessary to have a standardized method for identifying users. This 157 document defines syntax for the Network Access Identifier (NAI). 158 Examples of implementations that use the NAI, and descriptions of its 159 semantics, can be found in [RFC2194]. 161 When the NAI was defined for network access, it had the side effect 162 of defining an identifier which could be used in non-AAA systems. 163 Some non-AAA systems defined identifiers which were compatible with 164 the NAI, and deployments used the NAI. This process simplified the 165 management of credentials, by re-using the same credential in 166 multiple situations. Protocols that re-use the same credential or 167 the same identifier format can benefit from this management 168 simplicity. The alternative is to have protocol-specific credentials 169 or identifier formats, which increases cost to both the user and the 170 administrator. 172 There are privacy implications to using one identifier across 173 multiple protocols. See Section 2.7 and Section 4 for further 174 discussion of this topic. 176 The goal of this document is to define the format of an identifier 177 which can be used in many protocols. A protocol may transport an 178 encoded version of the NAI (e.g. '.' as %2E). However, the 179 definition of the NAI is protocol independent. The goal of this 180 document is to encourage the wide-spread adoption of the NAI format. 181 This adoption will decrease work required to leverage identification 182 and authentication in other protocols. It will also decrease the 183 complexity of non-AAA systems for end users and administrators. 185 This document only suggests that the NAI format be used, but does not 186 require such use. Many protocols already define their own identifier 187 formats. Some of these are incompatible with the NAI, while others 188 allow the NAI in addition to non-NAI identifiers. The definition of 189 the NAI in this document has no requirements on protocol 190 specifications, implementations, or deployments. 192 However, this document suggests that using one standard identifier 193 format is preferable to using multiple incompatible identifier 194 formats. Where identifiers need to be used in new protocols and/or 195 specifications, it is RECOMMENDED that the format of the NAI be used. 196 That is, the interpretation of the identifier is context-specific, 197 while the format of the identifier remains the same. These issues 198 are discussed in more detail in Section 2.8, below. 200 The recommendation for a standard identifier format is not a 201 recommendation that each user have one universal identifier. In 202 contrast, this document allows for the use of multiple identifiers, 203 and recommends the use of anonymous identifiers where those 204 identifiers are publicly visible. 206 This document is a revised version of [RFC4282], which originally 207 defined internationalized NAIs. Differences and enhancements 208 compared to that document are listed in Appendix A. 210 1.1. Terminology 212 This document frequently uses the following terms: 214 "Local" or "localized" text 216 Text which is either in non-UTF-8, or in non-normalized form. The 217 character set, encoding, and locale are (in general) unknown to 218 Authentication, Authorization, and Accounting (AAA) network 219 protocols. The client which "knows" the locale may have a 220 different concept of this text than other AAA entities, which do 221 not know the same locale. 223 Network Access Identifier 225 The Network Access Identifier (NAI) is a common format for user 226 identifiers submitted by a client during authentication. The 227 purpose of the NAI is to allow a user to be associated with an 228 account name, as well as to assist in the routing of the 229 authentication request across multiple domains. Please note that 230 the NAI may not necessarily be the same as the user's email 231 address or the user identifier submitted in an application layer 232 authentication. 234 Network Access Server 236 The Network Access Server (NAS) is the device that clients connect 237 to in order to get access to the network. In PPTP terminology, 238 this is referred to as the PPTP Access Concentrator (PAC), and in 239 L2TP terminology, it is referred to as the L2TP Access 240 Concentrator (LAC). In IEEE 802.11, it is referred to as an 241 Access Point. 243 Roaming Capability 245 Roaming capability can be loosely defined as the ability to use 246 any one of multiple Internet Service Providers (ISPs), while 247 maintaining a formal, customer-vendor relationship with only one. 248 Examples of cases where roaming capability might be required 249 include ISP "confederations" and ISP-provided corporate network 250 access support. 252 Normalization or Canonicalization 254 These terms are defined in [RFC6365] Section 4. Those definitions 255 are incorporated here by reference. 257 Locale 259 This term is defined in [RFC6365] Section 8. Those definitions 260 are incorporated here by reference. 262 Tunneling Service 264 A tunneling service is any network service enabled by tunneling 265 protocols such as PPTP, L2F, L2TP, and IPsec tunnel mode. One 266 example of a tunneling service is secure access to corporate 267 intranets via a Virtual Private Network (VPN). 269 1.2. Requirements Language 271 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 272 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 273 "OPTIONAL" in this document are to be interpreted as described in 274 [RFC2119]. 276 1.3. Purpose 278 As described in [RFC2194], there are a number of providers offering 279 network access services, and essentially all Internet Service 280 Providers are involved in roaming consortia. 282 In order to be able to offer roaming capability, one of the 283 requirements is to be able to identify the user's home authentication 284 server. For use in roaming, this function is accomplished via the 285 Network Access Identifier (NAI) submitted by the user to the NAS in 286 the initial network authentication. It is also expected that NASes 287 will use the NAI as part of the process of opening a new tunnel, in 288 order to determine the tunnel endpoint. 290 This document suggests that other protocols can take advantage of the 291 NAI format. Many protocols include authentication capabilities, 292 including defining their own identifier formats. These identifiers 293 can then end up being transported in AAA protocols, so that the 294 originating protocols can leverage AAA for user authentication. 295 There is therefore a need for a definition of a user identifier which 296 can be used in multiple protocols. 298 While the NAI is defined herein, it should be noted that existing 299 protocols and deployments do not always use it. AAA systems MUST 300 therefore be able to handle user identifiers which are not in the NAI 301 format. The process by which that is done is outside of the scope of 302 this document. 304 Non-AAA systems can accept user identifiers in forms other than the 305 NAI. This specification does not forbid that practice. It only 306 codifies the format and interpretation of the NAI. This document 307 cannot change existing protocols or practices. It can, however, 308 suggest that using a consistent form for a user identifier is of a 309 benefit to the community. 311 This document does not make any protocol-specific definitions for an 312 identifier format, and it does not make changes to any existing 313 protocol. Instead, it defines a protocol-independent form for the 314 NAI. It is hoped that the NAI is a user identifier which can be used 315 in multiple protocols. 317 Using a common identifier format implifies protocols requiring 318 authentication, as they no longer need to specify protocol-specific 319 format for user identifiers. It increases security, as it multiple 320 identifier formats allow attackers to make contradictory claims 321 without being detected (see Section 4.2 for further discussion of 322 this topic). It simplifies deployments, as a user can have one 323 identifier in multiple contexts, which allows them to be uniquely 324 identified, so long as that identifier is itself protected against 325 unauthorized access. 327 In short, having a standard is better than having no standard at all. 329 1.4. Motivation 331 The changes from [RFC4282] are listed in detail in Appendix A. 332 However, some additional discussion is appropriate to motivate those 333 changes. 335 The motivation to revise [RFC4282] began with internationalization 336 concerns raised in the context of [EDUROAM]. Section 2.1 of 337 [RFC4282] defines ABNF for realms which limits the realm grammar to 338 English letters, digits, and the hyphen "-" character. The intent 339 appears to have been to encode, compare, and transport realms with 340 the Punycode [RFC3492] encoding form as described in [RFC5891] There 341 are a number of problems with this approach: 343 * The [RFC4282] ABNF is not aligned with internationalization of DNS. 345 * The requirement in [RFC4282] Section 2.1 that realms are ASCII 346 conflicts with the Extensible Authentication Protocol (EAP) 347 defined in [RFC3748], and RADIUS, which are both 8-bit clean, and 348 which both recommend the use of UTF-8 for identitifiers. 350 * [RFC4282] Section 2.4 required mappings that are 351 language-specific, and which are nearly impossible for 352 intermediate nodes to perform correctly without information about 353 that language. 355 * [RFC4282] Section 2.4 requires normalization of user names, 356 which may conflict with local system or administrative 357 requirements. 359 * The recommendations in RFC4282] Section 2.4 for treatment of 360 bidirectional characters have proven to be unworkable. 362 * The prohibition against use of unassigned code points in 363 RFC4282] Section 2.4 effectively prohibits support for new 364 scripts. 366 * No Authentication, Authorization, and Accounting (AAA) 367 client, proxy, or server has implemented any of the requirements 368 in [RFC4282] Section 2.4, among other sections. 370 With international roaming growing in popularity, it is important for 371 these issues to be corrected in order to provide robust and inter- 372 operable network services. 374 Furthermore, this document was motivated by a desire to codify 375 existing practice related to the use of the NAI format and to 376 encourage widespread use of the format. 378 2. NAI Definition 380 2.1. UTF-8 Syntax and Normalization 382 UTF-8 characters can be defined in terms of octets using the 383 following ABNF [RFC5234], taken from [RFC3629]: 385 UTF8-xtra-char = UTF8-2 / UTF8-3 / UTF8-4 387 UTF8-2 = %xC2-DF UTF8-tail 389 UTF8-3 = %xE0 %xA0-BF UTF8-tail / 390 %xE1-EC 2(UTF8-tail) / 391 %xED %x80-9F UTF8-tail / 392 %xEE-EF 2(UTF8-tail) 394 UTF8-4 = %xF0 %x90-BF 2( UTF8-tail ) / 395 %xF1-F3 3( UTF8-tail ) / 396 %xF4 %x80-8F 2( UTF8-tail ) 398 UTF8-tail = %x80-BF 400 These are normatively defined in [RFC3629], but are repeated in this 401 document for reasons of convenience. 403 See [RFC5198] and section 2.6 of this specification for a discussion 404 of normalization. Strings which are not in Normal Form Composed (NFC) 405 are not valid NAIs and SHOULD NOT be treated as such. 406 Implementations which expect to receive a NAI, but which instead 407 receive non-normalised (but otherwise valid) UTF-8 strings instead 408 SHOULD attempt to create a local version of the NAI, which is 409 normalized from the input identifier. This local version can then be 410 used for local processing. This local version of the identifier MUST 411 NOT be used outside of the local context. 413 Where protocols carry identifiers which are expected to be 414 transported over an AAA protocol, it is RECOMMENDED that the 415 identifiers be in NAI format. Where the identifiers are not in the 416 NAI format, it is up to the AAA systems to discover this, and to 417 process them. This document does not suggest how that is done. 418 However, existing practice indicates that it is possible. 420 As internationalized domain names become more widely used, existing 421 practices are likely to become inadequate. This document therefore 422 defines the NAI, which is a user identifier format that can correctly 423 deal with internationalized identifiers. 425 2.2. Formal Syntax 427 The grammar for the NAI is given below, described in Augmented 428 Backus-Naur Form (ABNF) as documented in [RFC5234]. 430 nai = utf8-username 431 nai =/ "@" utf8-realm 432 nai =/ utf8-username "@" utf8-realm 434 utf8-username = dot-string 436 dot-string = string *("." string) 437 string = 1*utf8-atext 439 utf8-atext = ALPHA / DIGIT / 440 "!" / "#" / 441 "$" / "%" / 442 "&" / "'" / 443 "*" / "+" / 444 "-" / "/" / 445 "=" / "?" / 446 "^" / "_" / 447 "`" / "{" / 448 "|" / "}" / 449 "~" / 450 UTF8-xtra-char 452 utf8-realm = 1*( label "." ) label 454 label = utf8-rtext *(ldh-str) 455 ldh-str = *( utf8-rtext / "-" ) utf8-rtext 456 utf8-rtext = ALPHA / DIGIT / UTF8-xtra-char 458 2.3. NAI Length Considerations 460 Devices handling NAIs MUST support an NAI length of at least 72 461 octets. Devices SHOULD support an NAI length of 253 octets. 462 However, the following implementation issues should be considered: 464 * NAI octet length constraints may impose a more severe constraint 465 on the number of UTF-8 characters. 467 * NAIs are often transported in the User-Name attribute of the 468 Remote Authentication Dial-In User Service (RADIUS) protocol. 469 Unfortunately, RFC 2865 [RFC2865], Section 5.1, states that "the 470 ability to handle at least 63 octets is recommended." As a 471 result, it may not be possible to transfer NAIs beyond 63 octets 472 through all devices. In addition, since only a single User-Name 473 attribute may be included in a RADIUS message and the maximum 474 attribute length is 253 octets, RADIUS is unable to support NAI 475 lengths beyond 253 octets. 477 * NAIs can also be transported in the User-Name attribute of 478 Diameter [RFC6733], which supports content lengths up to 2^24 - 9 479 octets. As a result, NAIs processed only by Diameter nodes can be 480 very long. However, an NAI transported over Diameter may 481 eventually be translated to RADIUS, in which case the above 482 limitations will apply. 484 * NAIs may be transported in other protocols. Each protocol 485 can have its own limitations on maximum NAI length. 486 The above criteria should permit the widest use, and widest possible 487 inter-operability of the NAI. 489 2.4. Support for Username Privacy 491 Interpretation of the username part of the NAI depends on the realm 492 in question. Therefore, the utf8-username portion SHOULD be treated 493 as opaque data when processed by nodes that are not a part of the 494 home domain for that realm. 496 That is, the only domain which is capable of interpreting the meaning 497 of the utf8-username portion of the NAI is the home domain. Any 498 third-party domains cannot form any conclusions about the 499 utf8-username, and cannot decode it into sub-fields. For example, it 500 may be used as "firstname.lastname", or it may be entirely digits, or 501 it may be a random hex identifier. There is simply no way (and no 502 reason) for any other domain to interpret the utf8-username field as 503 having any meaning whatsoever. 505 In some situations, NAIs are used together with a separate 506 authentication method that can transfer the username part in a more 507 secure manner to increase privacy. In this case, NAIs MAY be 508 provided in an abbreviated form by omitting the username part. 509 Omitting the username part is RECOMMENDED over using a fixed username 510 part, such as "anonymous", since including a fixed username part is 511 ambiguous as to whether or not the NAI refers to a single user. 512 However, current practice is to use the username "anonymous" instead 513 of omitting the username part. This behavior is also permitted. 515 The most common use-case of omitting or obfuscating the username part 516 is with TLS-based EAP methods such as TTLS [RFC5281]. Those methods 517 allow for an "outer" identifier, which is typically an anonymous 518 "@realm". This outer identifier allows the authentication request to 519 be routed from a visited domain to a home domain. At the same time, 520 the username part is kept confidential from the visited network. The 521 protocol provides for an "inner" authentication exchange, in which a 522 full identifier is used to authenticate a user. 524 That scenario offers the best of both worlds. An anonymous NAI can 525 be used to route authentication to the home domain, and the home 526 domain has sufficient information to identify and authenticate users. 528 However, some protocols do not support authenticate methods which 529 allow for "inner" and "outer" exchanges. Those protocols are limited 530 to using an identifier which is publicly visible. It is therefore 531 RECOMMENDED that such protocols use ephemeral identifiers. We 532 recognize that this practice is not currently used, and will likely 533 be difficult to implement. 535 Similarly to the anonymous user, there may be situations where 536 portions of the realm are sensitive. For those situations, it is 537 RECOMMENDED that the sensitive portion of the realm also be omitted. 538 e.g. To use "@example.com" instead of "@sensitive.example.com", or 539 "anonymous@sensitive.example.com". The home domain is authoritative 540 for users in all subdomains, and can (if necessary) route the 541 authentication request to the appropriate subsystem within the home 542 domain. 544 For roaming purposes, it is typically necessary to locate the 545 appropriate backend authentication server for the given NAI before 546 the authentication conversation can proceed. As a result, 547 authentication routing is impossible unless the realm portion is 548 available, and in a well-known format. 550 2.5. International Character Sets 552 This specification allows both international usernames and realms. 553 International usernames are based on the use of Unicode characters, 554 encoded as UTF-8. Internationalization of the username portion of 555 the NAI is based on the "Internationalized Email Headers" [RFC6532] 556 extensions to the "local-part" portion of email addresses [RFC5322]. 558 In order to ensure a canonical representation, characters of the 559 realm portion in an NAI MUST match the ABNF in this specification as 560 well as the requirements specified in [RFC5891]. In practice, these 561 requirements consist of the following item: 563 * Realms MUST be of the form that can be registered as a 564 Fully Qualified Domain Name (FQDN) within the DNS. 566 This list is significantly shorter and simpler than the list in 567 Section 2.4 of [RFC4282]. The form suggested in [RFC4282] depended 568 on intermediate nodes performing canonicalizations based on 569 insufficient information, which meant that the form was not 570 canonical. 572 Specifying the realm requirement as above means that the requirements 573 depend on specifications that are referenced here, rather than copied 574 here. This allows the realm definition to be updated when the 575 referenced documents change, without requiring a revision of this 576 specification. 578 One caveat on the above recommendation is the issues noted in 579 [RFC6912]. That document notes that there are additional 580 restrictions around DNS registration which forbid some code points 581 from being valid in a DNS U-label. These restrictions cannot be 582 expressed algorithmically. 584 For this specification, that caveat means the following. Realms not 585 matching the above ABNF are not valid NAIs. However, some realms 586 which do match the ABNF are still invalid NAIs. That is, matching 587 the ABNF is a necessary, but not sufficient, requirement for an NAI. 589 In general, the above requirement means following the requirements 590 specified in [RFC5891]. 592 2.6. The Normalization Process 594 Conversion to Unicode as well as normalization SHOULD be performed by 595 edge systems (e.g. laptops, desktops, smart phones, etc.) that take 596 "local" text as input. These edge systems are best suited to 597 determine the users intent, and can best convert from "local" text to 598 a normalized form. 600 Other AAA systems such as proxies do not have access to locale and 601 character set information that is available to edge systems. 602 Therefore, they may not always be able to convert local input to 603 Unicode. 605 That is, all processing of NAIs from "local" character sets and 606 locales to UTF-8 SHOULD be performed by edge systems, prior to the 607 NAIs entering the AAA system. Inside of an AAA system, NAIs are sent 608 over the wire in their canonical form, and this canonical form is 609 used for all NAI and/or realm comparisons. 611 Copying of localized text into fields that can subsequently be placed 612 into the RADIUS User-Name attribute is problematic. This practice 613 can result in a AAA proxy encountering non-UTF8 characters within 614 what it expects to be an NAI. An example of this requirement is 615 [RFC3579] Section 2.1, which states: 617 the NAS MUST copy the contents of the Type-Data field of the 618 EAP-Response/Identity received from the peer into the User-Name 619 attribute 621 As a result, AAA proxies expect the contents of the EAP- 622 Response/Identity sent by an EAP supplicant to consist of UTF-8 623 characters, not localized text. Using localized text in AAA username 624 or identity fields means that realm routing becomes difficult or 625 impossible. 627 In contrast to [RFC4282] Section 2.4, AAA systems are now expected to 628 perform NAI comparisons, matching, and AAA routing based on the NAI 629 as it is received. This specification provides a canonical 630 representation, ensures that intermediate AAA systems such as proxies 631 are not required to perform translations, and can be expected to work 632 through AAA systems that are unaware of international character sets. 634 In an ideal world, the following requirements would be widely 635 implemented: 637 * Edge systems using "localized" text SHOULD normalize the NAI 638 prior to it being used as an identifier in an authentication 639 protocol. 641 * AAA systems SHOULD NOT normalize the NAI, as they may not have 642 sufficient information to perform the normalization. 644 There are issues with this approach, however. 646 2.6.1. Issues with the Normalization Process 648 The requirements in the preceding section are not implemented today. 649 For example, most EAP implementations use a user identifier which is 650 passed to them from some other local system. This identifier is 651 treated as an opaque blob, and is placed as-is into the EAP Identity 652 field. Any subsequent system which receives that identifier is 653 assumed to be able to understand and process it. 655 This opaque blob unfortunately can contain localized text, which 656 means that the AAA systems have to process that text. 658 These limitations have the following theoretical and practical 659 implications. 661 * edge systems used today generally do not normalize the NAI 663 * Therefore AAA systems SHOUD attempt to normalize the NAI 665 The suggestion in the above sentence contradicts the suggestion in 666 the previous section. This is the reality of imperfect protocols. 668 Where the user identifier can be normalized, or determined to be in 669 normal form, the normal form MUST be used as the NAI. In all other 670 circumstances, the user identifier MUST NOT be treated as an NAI. 671 That data is still, however, a user identifier. AAA systems MUST NOT 672 fail authentication simply because the user identifier is not an NAI. 674 That is, when the realm portion of the NAI is not recognized by an 675 AAA server, it SHOULD try to normalize the NAI into NFC form. That 676 normalized form can then be used to see if the realm matches a known 677 realm. If no match is found, the original form of the NAI SHOULD be 678 used in all subsequent processing. 680 The AAA server may also convert realms to punycode, and perform all 681 realm comparisons on the resulting punycode strings. This conversion 682 follows the recommendations above, but may have different operational 683 effects and failure modes. 685 2.7. Use in Other Protocols 687 As noted earlier, the NAI format can be used in other, non-AAA 688 protocols. It is RECOMMENDED that the definition given here be used 689 unchanged. Using other definitions for user identifiers may hinder 690 interoperability, along with the users ability to authenticate 691 successfully. It is RECOMMENDED that protocols requiring the use of 692 a user identifier use the NAI format. 694 This document cannot require other protocols to use the NAI format 695 for user identifiers. Their needs are unknown, and at this time 696 unknowable. This document suggests that interoperability and inter- 697 domain authentication is useful, and should be encouraged. 699 Where a protocol is 8-bit clean, it can likely transport the NAI as- 700 is, without further modification. 702 Where a protocol is not 8-bit clean, it cannot transport the NAI as- 703 is. Instead, this document presumes that a protocol-specific 704 transport layer takes care of encoding the NAI on input to the 705 protocol, and decoding it when the NAI exits the protocol. The 706 encoded or escaped version of the NAI is not a valid NAI, and MUST 707 NOT be presented to the AAA system. 709 For example, HTTP carries user identifiers, but escapes the '.' 710 character as "%2E" (among others). When HTTP is used to transport 711 the NAI "fred@example.com", the data as transported will be in the 712 form "fred@example%2Ecom". That data exists only within HTTP, and 713 has no relevance to any AAA system. 715 Any comparison, validation, or use of the NAI MUST be done on its un- 716 escaped (i.e. utf8-clean) form. 718 2.8. Using the NAI format for other identifiers 720 As discussed in Section 1, above, is RECOMMENDED that the NAI format 721 be used as the standard format for user identifiers. This section 722 discusses that use in more detail. 724 It is often useful to create new identifiers for use in specific 725 contexts. These identifiers may have a number of different 726 properties, most of which are unimportant to this document. The goal 727 of this document is to create identifiers which are to be in a well- 728 known format, and to have namespaces. The NAI format fits these 729 requirements. 731 One example of such use is the "private user identity", which is an 732 identifier defined by the 3rd-Generation Partnership Project (3GPP). 733 That identifier is used to uniquely identify the user to the network. 734 The identifier is used for authorization, authentication, accounting, 735 administation, etc. The "private user identity" is globally unique, 736 and is defined by the home network operator. The format of the 737 identifier is explicitly the NAI, as stated by Section 13.3 of 738 [3GPP]: 740 The private user identity shall take the form of an NAI, and shall 741 have the form username@realm as specified in clause 2.1 of IETF 742 RFC 4282 744 For 3GPP, the "username" portion is a unique identifier which is 745 derived from device-specific information. The "realm" portion is 746 composed of information about the home network, followed by the base 747 string "3gppnetwork.org". e.g. 748 234150999999999@ims.mnc015.mcc234.3gppnetwork.org. 750 This format as defiend by 3GPP ensures that the identifier is 751 globally unique, as it is based off of the "3gppnetwork.org" domain. 752 It ensures that the "realm" portion is specific to a particular home 753 network (or organization), via the "ims.mnc015.mcc234" prefix to the 754 realm. Finally, it ensures that the "username" portion follows a 755 well-known format. 757 This document suggests that the NAI format be used for all new 758 specifications and/or protocols where a user identifier is required. 759 Where the username portions need to be created with subfields, a 760 well-known and documented method as has been done with 3GPP is 761 preferred to ad-hoc methods. 763 3. Routing inside of AAA Systems 765 Many AAA systems use the "utf8-realm" portion of the NAI to route 766 requests within a AAA proxy network. The semantics of this operation 767 involves a logical AAA routing table, where the "utf8-realm" portion 768 acts as a key, and the values stored in the table are one or more 769 "next hop" AAA servers. 771 Intermediate nodes MUST use the "utf8-realm" portion of the NAI 772 without modification to perform this lookup. As noted earlier, 773 intermediate nodes may not have access to the same locale information 774 as the system which injected the NAI into the AAA routing systems. 775 Therefore, almost all "case insensitive" comparisons can be wrong. 776 Where the "utf8-realm" is entirely ASCII, current AAA systems 777 sometimes perform case-insensitive matching on realms. This method 778 MAY be continued, as it has been shown to work in practice. 780 Many existing non-AAA systems have user identifiers which are similar 781 in format to the NAI, but which are not compliant with this 782 specification. For example, they may use non-NFC form, or they may 783 have multiple "@" characters in the user identifier. Intermediate 784 nodes SHOULD normalize non-NFC identifiers to NFC, prior to looking 785 up the "utf8-realm" in the logical routing table. Intermediate nodes 786 MUST NOT modify the identifiers that they forward. The data as 787 entered by the user is inviolate. 789 The "utf8-realm" provisioned in the logical AAA routing table SHOULD 790 be provisioned to the proxy prior to it receiving any AAA traffic. 791 The "utf8-realm" SHOULD be supplied by the "next hop" or "home" 792 system that also supplies the routing information necessary for 793 packets to reach the next hop. 795 This "next hop" information may be any of, or all of, the following 796 information: IP address; port; RADIUS shared secret; TLS certificate; 797 DNS host name; or instruction to use dyanmic DNS discovery (i.e. look 798 up a record in the "utf8-realm" domain). This list is not 799 exhaustive, and my be extended by future specifications. 801 It is RECOMMENDED to use the entirety of the "utf8-realm" for the 802 routing decisions. However, AAA systems MAY use a portion of the 803 "utf8-realm" portion, so long as that portion is a valid 804 "utf8-realm", and that portion is handled as above. For example, 805 routing "fred@example.com" to a "com" destination is forbidden, 806 because "com" is not a valid "utf8-realm". However, routing 807 "fred@sales.example.com" to the "example.com" destination is 808 permissible. 810 Another reason to forbid the use of a single label (e.g. 811 "fred@sales") is that many non-AAA systems treat a single label as 812 being a local identifier within their realm. That is, a user logging 813 in as "fred@sales" to a domain "example.com", would be treated as if 814 the NAI was instead "fred@sales.example.com". Permitting the use of 815 a single label would mean changing the interpretation and meaning of 816 a single label, which cannot be done. 818 3.1. Compatibility with Email Usernames 820 As proposed in this document, the Network Access Identifier is of the 821 form "user@realm". Please note that while the user portion of the NAI 822 is based on the "Internet Message Format" [RFC5322] "local-part" 823 portion of an email address as extended by "Internationalized Email 824 Headers" [RFC6532], it has been modified for the purposes of Section 825 2.2. It does not permit quoted text along with "folding" or "non- 826 folding" whitespace that is commonly used in email addresses. As 827 such, the NAI is not necessarily equivalent to usernames used in e- 828 mail. 830 However, it is a common practice to use email addresses as user 831 identifiers in AAA systems. The ABNF in Section 2.2 is defined to be 832 close to the "addr-spec" portion of [RFC5322] as extended by 833 [RFC6532], while still being compatible with [RFC4282]. 835 In contrast to [RFC4282] Section 2.5, this document state that the 836 internationalization requirements for NAIs and email addresses are 837 substantially similar. The NAI and email identifiers may be the 838 same, and both need to be entered by the user and/or the operator 839 supplying network access to that user. There is therefore good 840 reason for the internationalization requirements to be similar. 842 3.2. Compatibility with DNS 844 The "utf8-realm" portion of the NAI is intended to be compatible with 845 Internationalized Domain Names (IDNs) [RFC5890]. As defined above, 846 the "utf8-realm" portion as transported within an 8-bit clean 847 protocol such as RADIUS and EAP can contain any valid UTF8 character. 848 There is therefore no reason for a NAS to convert the "utf8-realm" 849 portion of an NAI into Punycode encoding form [RFC3492] prior to 850 placing the NAI into a RADIUS User-Name attribute. 852 The NAI does not make a distinction between A-labels and U-labels, as 853 those are terms specific to DNS. It is instead an IDNA-valid label, 854 as per the first item in Section 2.3.2.1 of [RFC5890]. As noted in 855 that section, the term "IDNA-valid label" encompases both of the 856 terms A-label and U-label. 858 When the realm portion of the NAI is used as the basis for name 859 resolution, it may be necessary to convert internationalized realm 860 names to Punycode [RFC3492] encoding form as described in [RFC5891]. 861 As noted in [RFC6055] Section 2, resolver Application Programming 862 Interfaces (APIs) are not necessarily DNS-specific, so conversion to 863 Punycode needs to be done carefully: 865 Applications which convert an IDN to A-label form before calling (for 866 example) getaddrinfo() will result in name resolution failures if the 867 Punycode name is directly used in such protocols. Having libraries 868 or protocols to convert from A-labels to the encoding scheme defined 869 by the protocol (e.g., UTF-8) would require changes to APIs and/or 870 servers, which IDNA was intended to avoid. 872 As a result, applications SHOULD NOT assume that non-ASCII names are 873 resolvable using the public DNS and blindly convert them to A-labels 874 without knowledge of what protocol will be selected by the name 875 resolution library. 877 3.3. Realm Construction 879 The home realm usually appears in the "utf8-realm" portion of the 880 NAI, but in some cases a different realm can be used. This may be 881 useful, for instance, when the home realm is reachable only via 882 intermediate proxies. 884 Such usage may prevent interoperability unless the parties involved 885 have a mutual agreement that the usage is allowed. In particular, 886 NAIs MUST NOT use a different realm than the home realm unless the 887 sender has explicit knowledge that (a) the specified other realm is 888 available and (b) the other realm supports such usage. The sender 889 may determine the fulfillment of these conditions through a database, 890 dynamic discovery, or other means not specified here. Note that the 891 first condition is affected by roaming, as the availability of the 892 other realm may depend on the user's location or the desired 893 application. 895 The use of the home realm MUST be the default unless otherwise 896 configured. 898 3.3.1. Historical Practices 900 Some AAA systems have historically used NAI modifications with 901 multiple "prefix" and "suffix" decorations to perform explicit 902 routing through multiple proxies inside of a AAA network. 904 In RADIUS based environment, the use of decorated NAI is NOT 905 RECOMMENDED for the following reasons: 907 * Using explicit routing paths is fragile, and is unresponsive to 908 changes in the network due to servers going up or down, or to 909 changing business relationships. 911 * There is no RADIUS routing protocol, meaning that routing paths 912 have to be communicated "out of band" to all intermediate AAA 913 nodes, and also to all edge systems (e.g. supplicants) expecting 914 to obtain network access. 916 * Using explicit routing paths requires thousands, if not 917 millions of edge systems to be updated with new path information 918 when a AAA routing path changes. This adds huge expense for 919 updates that would be better done at only a few AAA systems in the 920 network. 922 * Manual updates to RADIUS paths are expensive, time-consuming, 923 and prone to error. 925 * Creating compatible formats for the NAI is difficult 926 when locally-defined "prefixes" and "suffixes" conflict with 927 similar practices elsewhere in the network. These conflicts mean 928 that connecting two networks may be impossible in some cases, as 929 there is no way for packets to be routed properly in a way that 930 meets all requirements at all intermediate proxies. 932 * Leveraging the DNS name system for realm names establishes 933 a globally unique name space for realms. 935 In summary, network practices and capabilities have changed 936 significantly since NAIs were first overloaded to define AAA routes 937 through a network. While manually managed explicit path routing was 938 once useful, the time has come for better methods to be used. 940 Notwithstanding the above recommendations, the above practice is 941 widely used for Diameter routing [RFC5729]. The routes described 942 there are managed automatically, for both credential provisioning and 943 routing updates. Those routes also exist within a particular 944 framework (typically 3G), where membership is controlled and system 945 behavior is standardized. There are no known issues with using 946 explicit routing in such an environment. 948 However, if decorated identifiers are used, such as: 950 homerealm.example.org!user@otherrealm.example.net 952 Then the part before the (non-escaped) '!' MUST be a "utf8-realm" as 953 defined in the ABNF in Section 2.2. When receiving such an 954 identifier, the "otherrealm.example.net" system MUST convert the 955 identifier to "user@homerealm.example.org" before forwarding the 956 request. The forwarding system MUST then apply normal AAA routing 957 for the transaction, based on the updated identifier. 959 3.4. Examples 961 Examples of valid Network Access Identifiers include the following: 963 bob 964 joe@example.com 965 fred@foo-9.example.com 966 jack@3rd.depts.example.com 967 fred.smith@example.com 968 fred_smith@example.com 969 fred$@example.com 970 fred=?#$&*+-/^smith@example.com 971 nancy@eng.example.net 972 eng.example.net!nancy@example.net 973 eng%nancy@example.net 974 @privatecorp.example.net 975 \(user\)@example.net 977 An additional valid NAI is the following, given as a hex string, as 978 this document can only contain ASCII characters. 980 626f 6240 ceb4 cebf ceba ceb9 cebc ceae 2e63 6f6d 982 Examples of invalid Network Access Identifiers include the following: 984 fred@example 985 fred@example_9.com 986 fred@example.net@example.net 987 fred.@example.net 988 eng:nancy@example.net 989 eng;nancy@example.net 990 (user)@example.net 991 @example.net 993 One example given in [RFC4282] is still permitted by the ABNF, but it 994 is NOT RECOMMMENDED because of the use of the Punycode [RFC3492] 995 encoding form for what is now a valid UTF-8 string. 997 alice@xn--tmonesimerkki-bfbb.example.net 999 4. Security Considerations 1001 Since an NAI reveals the home affiliation of a user, it may assist an 1002 attacker in further probing the username space. Typically, this 1003 problem is of most concern in protocols that transmit the username in 1004 clear-text across the Internet, such as in RADIUS, described in 1005 [RFC2865] and [RFC2866]. In order to prevent snooping of the 1006 username, protocols may use confidentiality services provided by 1007 protocols transporting them, such as RADIUS protected by IPsec 1008 [RFC3579] or Diameter protected by TLS [RFC6733]. 1010 This specification adds the possibility of hiding the username part 1011 in the NAI, by omitting it. As discussed in Section 2.4, this is 1012 possible only when NAIs are used together with a separate 1013 authentication method that can transfer the username in a secure 1014 manner. In some cases, application-specific privacy mechanism have 1015 also been used with NAIs. For instance, some EAP methods apply 1016 method-specific pseudonyms in the username part of the NAI [RFC3748]. 1017 While neither of these approaches can protect the realm part, their 1018 advantage over transport protection is that privacy of the username 1019 is protected, even through intermediate nodes such as NASes. 1021 4.1. Correlation of Identities over Time and Protocols 1023 The recommendations in Section 2.7 and Section 2.8 for using the NAI 1024 in other protocols has implications for privacy. Any attacker who is 1025 capable of observing traffic containing the NAI can track the user, 1026 and correlate his activity across time and across multiple protocols. 1027 The authentication credentials therefore SHOULD be transported over 1028 channels which permit private communications, or multiple identifiers 1029 SHOULD be used, so that user tracking is impossible. 1031 It is RECOMMENDED that user privacy be enhanced by configuring 1032 multiple identifiers for one user. These identifiers can be changed 1033 over time, in order to make user tracking more difficult for a 1034 malicous observer. However, provisioning and management of the 1035 identifiers may be difficult in to do in practice, which is likely 1036 why multiple identifiers are rarely used today. 1038 4.2. Multiple Identifiers 1040 Section 1.3 states that multiple identifier formats allow attackers 1041 to make contradictory claims without being detected. This statement 1042 deserves further discussion. 1044 Section 2.4 discussed "inner" and "outer" identifiers in the context 1045 of TTLS [RFC5281]. A close reading of that specification shows there 1046 is no requirement that the inner and outer identifiers be in any way 1047 related. That is, it is perfectly valid to use "@example.com" for an 1048 outer identifier, and "user@example.org" as an inner identifier. The 1049 authentication request will then be routed to "example.com", which 1050 will likely be unable to authenticate "user@example.org". 1052 Even worse, a misconfiguration of "example.com" means that it may in 1053 turn proxy the inner authentication request to the "example.org" 1054 domain. Such cross-domain authentication is highly problematic, and 1055 there are few good reasons to allow it. 1057 It is therefore RECOMMENDED that systems which permit anonymous 1058 "outer" identifiers require that the "inner" domain be the same as, 1059 or a sub-domain of the "outer" domain. An authentication request 1060 using disparate realms is a security violation, and the request 1061 SHOULD be rejected. 1063 The situation gets worse when multiple protocols are involved. The 1064 TTLS protocol permits MS-CHAP [RFC2433] to be carried inside of the 1065 TLS tunnel. MS-CHAP defines its own identifier which is encapsulated 1066 inside of the MS-CHAP exchange. That identifier is not required to 1067 be any particular format, is not required to be in UTF-8, and in 1068 practice, can be one of many unknown character sets. There is no way 1069 in practice to determine which character set was used for that 1070 identifier. 1072 The result is that the "outer" EAP Identity carried by TTLS is likely 1073 to not even share the same character set as the "inner" identifier 1074 used by MS-CHAP. The two identifiers are entirely independent, and 1075 fundamentally incomparable. 1077 Such protocol design is NOT RECOMMENDED. 1079 5. Administration of Names 1081 In order to avoid creating any new administrative procedures, 1082 administration of the NAI realm namespace piggybacks on the 1083 administration of the DNS namespace. 1085 NAI realm names are required to be unique, and the rights to use a 1086 given NAI realm for roaming purposes are obtained coincident with 1087 acquiring the rights to use a particular Fully Qualified Domain Name 1088 (FQDN). Those wishing to use an NAI realm name should first acquire 1089 the rights to use the corresponding FQDN. Administrators MUST NOT 1090 publicly use an NAI realm without first owning the corresponding 1091 FQDN. Private use of unowned NAI realms within an administative 1092 domain is allowed, though it is RECOMMENDED that example names be 1093 used, such as "example.com". 1095 Note that the use of an FQDN as the realm name does not require use 1096 of the DNS for location of the authentication server. While Diameter 1097 [RFC6733] supports the use of DNS for location of authentication 1098 servers, existing RADIUS implementations typically use proxy 1099 configuration files in order to locate authentication servers within 1100 a domain and perform authentication routing. The implementations 1101 described in [RFC2194] did not use DNS for location of the 1102 authentication server within a domain. Similarly, existing 1103 implementations have not found a need for dynamic routing protocols 1104 or propagation of global routing information. Note also that there 1105 is no requirement that the NAI represent a valid email address. 1107 6. IANA Considerations 1109 This document has no actions for IANA. 1111 7. References 1113 7.1. Normative References 1115 [RFC2119] 1116 Bradner, S., "Key words for use in RFCs to Indicate Requirement 1117 Levels", RFC 2119, March, 1997. 1119 [RFC3629] 1120 Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, 1121 RFC 3629, November 2003. 1123 [RFC5198] 1124 Klensin J., and Padlipsky M., "Unicode Format for Network 1125 Interchange", RFC 5198, March 2008 1127 [RFC5234] 1128 Crocker, D. and P. Overell, "Augmented BNF for Syntax 1129 Specifications: ABNF", RFC 5234, January 2008. 1131 [RFC5890] 1132 Faltstrom, P., Hoffman, P., and A. Costello, "Internationalizing 1133 Domain Names in Applications (IDNA)", RFC 5890, August 2010 1135 [RFC5891] 1136 Klensin, J., "Internationalized Domain Names in Applications 1137 (IDNA): Protocol", RFC 5891, August 2010 1139 [RFC6365] 1140 Hoffman, P., and Klensin, J., "Terminology Used in 1141 Internationalization in the IETF", RFC 6365, September 2011 1143 7.2. Informative References 1145 [RFC2194] 1146 Aboba, B., Lu, J., Alsop, J., Ding, J., and W. Wang, "Review of 1147 Roaming Implementations", RFC 2194, September 1997. 1149 [RFC2341] 1150 Valencia, A., Littlewood, M., and T. Kolar, "Cisco Layer Two 1151 Forwarding (Protocol) "L2F"", RFC 2341, May 1998. 1153 [RFC2433] 1154 Zorn G., and Cobb, S. "Microsoft PPP CHAP Extensions", RFC 2433, 1155 October 1998. 1157 [RFC2637] 1158 Hamzeh, K., Pall, G., Verthein, W., Taarud, J., Little, W., and G. 1159 Zorn, "Point-to-Point Tunneling Protocol", RFC 2637, July 1999. 1161 [RFC2661] 1162 Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G., and B. 1163 Palter, "Layer Two Tunneling Protocol "L2TP"", RFC 2661, August 1164 1999. 1166 [RFC2865] 1167 Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote 1168 Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. 1170 [RFC2866] 1171 Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. 1173 [RFC3492] 1174 Costello, A., "Punycode: A Bootstring encoding of Unicode for 1175 Internationalized Domain Names in Applications (IDNA)", RFC 3492, 1176 March 2003. 1178 [RFC3579] 1179 Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial In 1180 User Service) Support For Extensible Authentication Protocol 1181 (EAP)", RFC 3579, September 2003. 1183 [RFC3748] 1184 Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 1185 Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, 1186 June 2004. 1188 [RFC4282] 1189 Aboba, B. et al., "The Network Access Identifier", RFC 4282, 1190 December 2005. 1192 [RFC4301] 1193 Kent, S. and S. Keo, "Security Architecture for the Internet 1194 Protocol", RFC 4301, December 2005. 1196 [RFC5281] 1197 Funk, P., and Blake-Wilson, S., "Extensible Authentication Protocol 1198 Tunneled Transport Layer Security Authenticated Protocol Version 0 1199 (EAP-TTLSv0)", RFC 5281, August 2008. 1201 [RFC5322] 1202 Resnick, P. (Ed), "Internet Message Format", RFC 5322, October 1203 2008. 1205 [RFC5335] 1206 Y. Abel, Ed., "Internationalized Email Headers", RFC 5335, 1207 September 2008. 1209 [RFC5729] 1210 Korhohen, J. (Ed) et. al., "Clarifications on the Routing of 1211 Diameter Requests Based on the Username and the Realm", RFC 5729, 1212 December 2009 1214 [RFC6055] 1215 Thaler, D., et al, "IAB Thoughts on Encodings for Internationalized 1216 Domain Names", RFC 6055, February 2011. 1218 [RFC6532] 1219 Yang, A., et al, "Internationalized Email Headers", RFC 6532, 1220 February 2012. 1222 [RFC6733] 1223 V. Fajardo, Ed., et al, "Diameter Base Protocol", RFC 6733, October 1224 2012. 1226 [RFC6912] 1227 Sullivan, A., et al, "Principles for Unicode Code Point Inclusion 1228 in Labels in the DNS", RFC 6912, April 2013. 1230 [EDUROAM] 1231 http://eduroam.org, "eduroam (EDUcational ROAMing)" 1233 [3GPP] 1234 3GPP, "TS 23.003 Numbering, addressing, and Identification (Release 1235 12)", July 2014, 1236 ftp://ftp.3gpp.org/Specs/archive/23_series/23.003/. 1238 Acknowledgments 1240 The initial text for this document was [RFC4282], which was then 1241 heavily edited. The original authors of [RFC4282] were Bernard 1242 Aboba, Mark A. Beadles, Jari Arkko, and Pasi Eronen. 1244 The ABNF validator at http://www.apps.ietf.org/abnf.html was used to 1245 verify the syntactic correctness of the ABNF in Section 2. 1247 Appendix A - Changes from RFC4282 1249 This document contains the following updates with respect to the 1250 previous NAI definition in RFC 4282 [RFC4282]: 1252 * The formal syntax in Section 2.1 has been updated to forbid 1253 non-UTF8 characters. e.g. characters with the "high bit" set. 1255 * The formal syntax in Section 2.1 has been updated to allow 1256 UTF-8 in the "realm" portion of the NAI. 1258 * The formal syntax in [RFC4282] Section 2.1 applied to the 1259 NAI after it was "internationalized" via the ToAscii function. 1260 The contents of the NAI before it was "internationalized" were 1261 left indeterminate. This document updates the formal syntax to 1262 define an internationalized form of the NAI, and forbids the use 1263 of the ToAscii function for NAI "internationalization". 1265 * The grammar for the user and realm portion is based on a 1266 combination 1267 of the "nai" defined in [RFC4282] Section 2.1, and the "utf8-addr- 1268 spec" defined in [RFC5335] Section 4.4. 1270 * All use of the ToAscii function has been moved to normal 1271 requirements on DNS implementations when realms are used as the 1272 basis for DNS lookups. This involves no changes to the existing 1273 DNS infrastructure. 1275 * The discussions on internationalized character sets in Section 2.4 1276 have been updated. The suggestion to use the ToAscii function for 1277 realm comparisons has been removed. No AAA system has implemented 1278 these suggestions, so this change should have no operational 1279 impact. 1281 * The section "Routing inside of AAA Systems" section is new in this 1282 document. The concept of a "local AAA routing table" is also new, 1283 although it accurately describes the functionality of wide-spread 1284 implementations. 1286 * The "Compatibility with EMail Usernames" and "Compatibility 1287 with DNS" sections have been revised and updated. The Punycode 1288 transformation is suggested to be used only when a realm name is 1289 used for DNS lookups, and even then the function is only used by a 1290 resolving API on the local system, and even then it is recommended 1291 that only the home network perform this conversion. 1293 * The "Realm Construction" section has been updated to note 1294 that editing of the NAI is NOT RECOMMENDED. 1296 * The "Examples" section has been updated to remove the instance 1297 of the IDN being converted to ASCII. This behavior is now 1298 forbidden. 1300 Authors' Addresses 1302 Alan DeKok 1303 The FreeRADIUS Server Project 1305 Email: aland@freeradius.org