idnits 2.17.1 draft-ietf-radext-nai-12.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 (3 December 2014) is 3432 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 3 December 2014 9 The Network Access Identifier 10 draft-ietf-radext-nai-12 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 03, 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 ........................... 20 96 3.4. Examples ............................................ 21 97 4. Security Considerations .................................. 22 98 4.1. Correlation of Identities over Time and Protocols ... 22 99 4.2. Multiple Identifiers ................................ 23 100 5. Administration of Names .................................. 24 101 6. IANA Considerations ...................................... 24 102 7. References ............................................... 24 103 7.1. Normative References ................................ 24 104 7.2. Informative References .............................. 25 105 Appendix A - Changes from RFC4282 ............................ 28 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", we mean situations where a user has 115 authentication credentials at one "home" domain, but is able to 116 present them at a second "visited" domain to access certain services 117 at the visited domain. The two domains generally have a pre-existing 118 relationship, so that the credentials can be passed from the visited 119 domain to the home domain for verification. The home domain 120 typically responds with a permit / deny response, which may also 121 include authorization parameters which the visited domain is expected 122 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. We suggest that this re-use is good practice, 167 so long as privacy issues are dealt with. The alternative is to have 168 protocol-specific identifiers, which increases cost to both the user 169 and the administrator. 171 There are privacy implications to using one identifier across 172 multiple protocols. See Section 2.7 and Section 4 for further 173 discussion of this topic. 175 The goal of this document is to define the format of an identifier 176 which can be used in many protocols. A protocol may transport an 177 encoded version of the NAI (e.g. '.' as %2E). However, the 178 definition of the NAI is protocol independent. We hope to encourage 179 the wide-spread adoption of the NAI as an identifier. This adoption 180 will decrease work required to leverage identification and 181 authentication in other protocols. It will also decrease the 182 complexity of non-AAA systems for end users and administrators. 184 We note that this document only suggest that the NAI be used, but 185 does not require such use. Many protocols already define their own 186 identifier formats. Some of these are incompatible with the NAI, 187 while others allow the NAI in addition to non-NAI identifiers. The 188 definition of the NAI in this document has no requirements on 189 protocol specifications, implementations, or deployments. 191 However, we suggest that using one standard identifier format is 192 preferable to using multiple incompatible identifier formats. Where 193 identifiers need to be used in new protocols and/or specifications, 194 it is RECOMMENDED that the format of the NAI be used. That is, the 195 interpretation of the identifier is context-specific, while the 196 format of the identifier remains the same. These issues are 197 discussed in more detail in Section 2.8, below. 199 The recommendation for a standard identifier format is not a 200 recommendation that each user have one universal identifier. In 201 contrast, this document allows for the use of multiple identifiers, 202 and recommends the use of anonymous identifiers where those 203 identifiers are publicly visible. 205 This document is a revised version of [RFC4282], which originally 206 defined internationalized NAIs. Differences and enhancements 207 compared to that document are listed in Appendix A. 209 1.1. Terminology 211 This document frequently uses the following terms: 213 "Local" or "localized" text 215 Text which is either in non-UTF-8, or in non-normalized form. The 216 character set, encoding, and locale are (in general) unknown to 217 Authentication, Authorization, and Accounting (AAA) network 218 protocols. The client which "knows" the locale may have a 219 different concept of this text than other AAA entities, which do 220 not know the same locale. 222 Network Access Identifier 224 The Network Access Identifier (NAI) is a common format for user 225 identifiers submitted by a client during authentication. The 226 purpose of the NAI is to allow a user to be associated with an 227 account name, as well as to assist in the routing of the 228 authentication request across multiple domains. Please note that 229 the NAI may not necessarily be the same as the user's email 230 address or the user identifier submitted in an application layer 231 authentication. 233 Network Access Server 235 The Network Access Server (NAS) is the device that clients connect 236 to in order to get access to the network. In PPTP terminology, 237 this is referred to as the PPTP Access Concentrator (PAC), and in 238 L2TP terminology, it is referred to as the L2TP Access 239 Concentrator (LAC). In IEEE 802.11, it is referred to as an 240 Access Point. 242 Roaming Capability 244 Roaming capability can be loosely defined as the ability to use 245 any one of multiple Internet Service Providers (ISPs), while 246 maintaining a formal, customer-vendor relationship with only one. 247 Examples of cases where roaming capability might be required 248 include ISP "confederations" and ISP-provided corporate network 249 access support. 251 Normalization or Canonicalization 253 These terms are defined in [RFC6365] Section 4. We incorporate 254 the definitions here by reference. 256 Locale 258 This term is defined in [RFC6365] Section 8. We incorporate the 259 definition here by reference. 261 Tunneling Service 263 A tunneling service is any network service enabled by tunneling 264 protocols such as PPTP, L2F, L2TP, and IPsec tunnel mode. One 265 example of a tunneling service is secure access to corporate 266 intranets via a Virtual Private Network (VPN). 268 1.2. Requirements Language 270 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 271 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 272 "OPTIONAL" in this document are to be interpreted as described in 273 [RFC2119]. 275 1.3. Purpose 277 As described in [RFC2194], there are a number of providers offering 278 network access services, and essentially all Internet Service 279 Providers are involved in roaming consortia. 281 In order to be able to offer roaming capability, one of the 282 requirements is to be able to identify the user's home authentication 283 server. For use in roaming, this function is accomplished via the 284 Network Access Identifier (NAI) submitted by the user to the NAS in 285 the initial network authentication. It is also expected that NASes 286 will use the NAI as part of the process of opening a new tunnel, in 287 order to determine the tunnel endpoint. 289 We also hope that other protocols can take advantage of the NAI. 290 Many protocols include authentication capabilities, including 291 defining their own identifier formats. These identifiers can then 292 end up being transported in AAA protocols, so that the originating 293 protocols can leverage AAA for user authentication. There is 294 therefore a need for a definition of a user identifier which can be 295 used in multiple protocols. 297 While we define the NAI here, we recognize that existing protocols 298 and deployments do not always use it. AAA systems MUST therefore be 299 able to handle user identifiers which are not in the NAI format. The 300 process by which that is done is outside of the scope of this 301 document. 303 Non-AAA systems MAY accept user identifiers in forms other than the 304 NAI. This specification does not forbid that practice. It only 305 codifies the format and interpretation of the NAI. We cannot expect 306 to change existing protocols or practices. We can, however, suggest 307 that using a consistent form for a user identifier is of a benefit to 308 the community. 310 We note that this document does not make any protocol-specific 311 definitions for an identifier format, and it does not make changes to 312 any existing protocol. Instead, it defines a protocol-independent 313 form for the NAI. It is hoped that the NAI is a user identifier 314 which can be used in multiple protocols. 316 Using a common identifier format implifies protocols requiring 317 authentication, as they no longer need to specify protocol-specific 318 format for user identifiers. It increases security, as it multiple 319 identifier formats allow attackers to make contradictory claims 320 without being detected (see Section 4.2 for further discussion of 321 this topic). It simplifies deployments, as a user can have one 322 identifier in multiple contexts, which allows them to be uniquely 323 identified, so long as that identifier is itself kept private. 325 In short, having a standard is better than having no standard at all. 327 1.4. Motivation 329 The changes from [RFC4282] are listed in detail in Appendix A. 330 However, some additional discussion is appropriate to motivate those 331 changes. 333 The motivation to revise [RFC4282] began with internationalization 334 concerns raised in the context of [EDUROAM]. Section 2.1 of 335 [RFC4282] defines ABNF for realms which limits the realm grammar to 336 English letters, digits, and the hyphen "-" character. The intent 337 appears to have been to encode, compare, and transport realms with 338 the ToASCII operation defined in [RFC5890]. There are a number of 339 problems with this approach: 341 * The [RFC4282] ABNF is not aligned with internationalization of DNS. 343 * The requirement in [RFC4282] Section 2.1 that realms are ASCII 344 conflicts with the Extensible Authentication Protocol (EAP) 345 defined in [RFC3748], and RADIUS, which are both 8-bit clean, and 346 which both recommend the use of UTF-8 for identitifiers. 348 * [RFC4282] Section 2.4 required mappings that are 349 language-specific, and which are nearly impossible for 350 intermediate nodes to perform correctly without information about 351 that language. 353 * [RFC4282] Section 2.4 requires normalization of user names, 354 which may conflict with local system or administrative 355 requirements. 357 * The recommendations in RFC4282] Section 2.4 for treatment of 358 bidirectional characters have proven to be unworkable. 360 * The prohibition against use of unassigned code points in 361 RFC4282] Section 2.4 effectively prohibits support for new 362 scripts. 364 * No Authentication, Authorization, and Accounting (AAA) 365 client, proxy, or server has implemented any of the requirements 366 in [RFC4282] Section 2.4, among other sections. 368 With international roaming growing in popularity, it is important for 369 these issues to be corrected in order to provide robust and inter- 370 operable network services. 372 2. NAI Definition 374 2.1. UTF-8 Syntax and Normalization 376 UTF-8 characters can be defined in terms of octets using the 377 following ABNF [RFC5234], taken from [RFC3629]: 379 UTF8-xtra-char = UTF8-2 / UTF8-3 / UTF8-4 381 UTF8-2 = %xC2-DF UTF8-tail 383 UTF8-3 = %xE0 %xA0-BF UTF8-tail / 384 %xE1-EC 2(UTF8-tail) / 385 %xED %x80-9F UTF8-tail / 386 %xEE-EF 2(UTF8-tail) 388 UTF8-4 = %xF0 %x90-BF 2( UTF8-tail ) / 389 %xF1-F3 3( UTF8-tail ) / 390 %xF4 %x80-8F 2( UTF8-tail ) 392 UTF8-tail = %x80-BF 394 These are normatively defined in [RFC3629], but are repeated in this 395 document for reasons of convenience. 397 See [RFC5198] and section 2.6 of this specification for a discussion 398 of normalization. Strings which are not in Normal Form Composed (NFC) 399 are not valid NAIs and SHOULD NOT be treated as such. 400 Implementations which expect to receive a NAI, but which instead 401 receive non-normalised (but otherwise valid) UTF-8 strings instead 402 SHOULD attempt to create a local version of the NAI, which is 403 normalized from the input identifier. This local version can then be 404 used for local processing. 406 Where protocols carry identifiers which are expected to be 407 transported over an AAA protocol, it is RECOMMENDED that the 408 identifiers be in NAI format. Where the identifiers are not in the 409 NAI format, it is up to the AAA systems to discover this, and to 410 process them. This document does not suggest how that is done. 411 However, existing practice indicates that it is possible. 413 We expect that with wider use of internationalized domain names, 414 existing practices will be inadequate. We therefore define the NAI, 415 which is a user identifier that can correctly deal with 416 internationalized identifiers. 418 2.2. Formal Syntax 420 The grammar for the NAI is given below, described in Augmented 421 Backus-Naur Form (ABNF) as documented in [RFC5234]. 423 nai = utf8-username 424 nai =/ "@" utf8-realm 425 nai =/ utf8-username "@" utf8-realm 427 utf8-username = dot-string 429 dot-string = string *("." string) 430 string = 1*utf8-atext 432 utf8-atext = ALPHA / DIGIT / 433 "!" / "#" / 434 "$" / "%" / 435 "&" / "'" / 436 "*" / "+" / 437 "-" / "/" / 438 "=" / "?" / 439 "^" / "_" / 440 "`" / "{" / 441 "|" / "}" / 442 "~" / 443 UTF8-xtra-char 445 utf8-realm = 1*( label "." ) label 447 label = utf8-rtext *(ldh-str) 448 ldh-str = *( utf8-rtext / "-" ) utf8-rtext 449 utf8-rtext = ALPHA / DIGIT / UTF8-xtra-char 451 2.3. NAI Length Considerations 453 Devices handling NAIs MUST support an NAI length of at least 72 454 octets. Devices SHOULD support an NAI length of 253 octets. 455 However, the following implementation issues should be considered: 457 * NAI octet length constraints may impose a more severe constraint 458 on the number of UTF-8 characters. 460 * NAIs are often transported in the User-Name attribute of the 461 Remote Authentication Dial-In User Service (RADIUS) protocol. 462 Unfortunately, RFC 2865 [RFC2865], Section 5.1, states that "the 463 ability to handle at least 63 octets is recommended." As a 464 result, it may not be possible to transfer NAIs beyond 63 octets 465 through all devices. In addition, since only a single User-Name 466 attribute may be included in a RADIUS message and the maximum 467 attribute length is 253 octets, RADIUS is unable to support NAI 468 lengths beyond 253 octets. 470 * NAIs can also be transported in the User-Name attribute of 471 Diameter [RFC6733], which supports content lengths up to 2^24 - 9 472 octets. As a result, NAIs processed only by Diameter nodes can be 473 very long. However, an NAI transported over Diameter may 474 eventually be translated to RADIUS, in which case the above 475 limitations will apply. 477 * NAIs may be transported in other protocols. Each protocol 478 can have its own limitations on maximum NAI length. 479 The above criteria should permit the widest use, and widest possible 480 inter-operability of the NAI. 482 2.4. Support for Username Privacy 484 Interpretation of the username part of the NAI depends on the realm 485 in question. Therefore, the utf8-username portion SHOULD be treated 486 as opaque data when processed by nodes that are not a part of the 487 home domain for that realm. 489 That is, the only domain which is capable of interpreting the meaning 490 of the utf8-username portion of the NAI is the home domain. Any 491 third-party domains cannot form any conclusions about the 492 utf8-username, and cannot decode it into sub-fields. For example, it 493 may be used as "firstname.lastname", or it may be entirely digits, or 494 it may be a random hex identifier. There is simply no way (and no 495 reason) for any other domain to interpret the utf8-username field as 496 having any meaning whatsoever. 498 In some situations, NAIs are used together with a separate 499 authentication method that can transfer the username part in a more 500 secure manner to increase privacy. In this case, NAIs MAY be 501 provided in an abbreviated form by omitting the username part. 502 Omitting the username part is RECOMMENDED over using a fixed username 503 part, such as "anonymous", since it provides an unambiguous way to 504 determine whether the username is intended to uniquely identify a 505 single user. However, current practice is to use the username 506 "anonymous" instead of omitting the username part. This behavior is 507 also permitted. 509 The most common use-case of such behavior is with TLS-based EAP 510 methods such as TTLS [RFC5281]. Those methods allow for an "outer" 511 identifier, which is typically an anonymous "@realm". This outer 512 identifier allows the authentication request to be routed from a 513 visited domain to a home domain. At the same time, user privacy is 514 preserved. The protocol provides for an "inner" authentication 515 exchange, in which a full identifier is used to authenticate a user. 517 That scenario offers the best of both worlds. An anonymous NAI can 518 be used to route authentication to the home domain, and the home 519 domain has sufficient information to identify and authenticate users. 521 However, some protocols do not support authenticate methods which 522 allow for "inner" and "outer" exchanges. Those protocols are limited 523 to using an identifier which is publicly visible. It is therefore 524 RECOMMENDED that such protocols use ephemeral identifiers. We 525 recognize that this practice is not currently used, and will likely 526 be difficult to implement. 528 Similarly to the anonymous user, there may be situations where 529 portions of the realm are sensitive. For those situations, it is 530 RECOMMENDED that the sensitive portion of the realm also be omitted. 531 e.g. To use "@example.com" instead of "@sensitive.example.com", or 532 "anonymous@sensitive.example.com". The home domain is authoritative 533 for users in all subdomains, and can (if necessary) route the 534 authentication request to the appropriate subsystem within the home 535 domain. 537 For roaming purposes, it is typically necessary to locate the 538 appropriate backend authentication server for the given NAI before 539 the authentication conversation can proceed. As a result, 540 authentication routing is impossible unless the realm portion is 541 available, and in a well-known format. 543 2.5. International Character Sets 545 This specification allows both international usernames and realms. 546 International usernames are based on the use of Unicode characters, 547 encoded as UTF-8. Internationalization of the realm portion of the 548 NAI is based on "Internationalized Email Headers" [RFC5335]. 550 In order to ensure a canonical representation, characters of the 551 username portion in an NAI MUST match the ABNF in this specification 552 as well as the requirements specified in [RFC5891]. In practice, 553 these requirements consist of the following item: 555 * Realms MUST be of the form that can be registered as a 556 Fully Qualified Domain Name (FQDN) within the DNS. 558 This list is significantly shorter and simpler than the list in 559 Section 2.4 of [RFC4282]. The form suggested in [RFC4282] depended 560 on intermediate nodes performing canonicalizations based on 561 insufficient information, which meant that the form was not 562 canonical. 564 Specifying the realm requirement as above means that the requirements 565 depend on specifications that are referenced here, rather than copied 566 here. This allows the realm definition to be updated when the 567 referenced documents change, without requiring a revision of this 568 specification. 570 One caveat on the above recommendation is the issues noted in 571 [RFC6912]. That document notes that there are additional 572 restrictions around DNS registration which forbid some code points 573 from being valid in a DNS U-label. These restrictions cannot be 574 expressed algorithmically. 576 For this specification, that caveat means the following. Realms not 577 matching the above ABNF are not valid NAIs. However, some realms 578 which do match the ABNF are still invalid NAIs. That is, matching 579 the ABNF is a necessary, but not sufficient, requirement for an NAI. 581 In general, the above requirement means following the requirements 582 specified in [RFC5891]. 584 2.6. The Normalization Process 586 Conversion to Unicode as well as normalization SHOULD be performed by 587 edge systems (e.g. laptops, desktops, smart phones, etc.) that take 588 "local" text as input. These edge systems are best suited to 589 determine the users intent, and can best convert from "local" text to 590 a normalized form. 592 Other AAA systems such as proxies do not have access to locale and 593 character set information that is available to edge systems. 594 Therefore, they may not always be able to convert local input to 595 Unicode. 597 That is, all processing of NAIs from "local" character sets and 598 locales to UTF-8 SHOULD be performed by edge systems, prior to the 599 NAIs entering the AAA system. Inside of an AAA system, NAIs are sent 600 over the wire in their canonical form, and this canonical form is 601 used for all NAI and/or realm comparisons. 603 Copying of localized text into fields that can subsequently be placed 604 into the RADIUS User-Name attribute is problematic. This practice 605 can result in a AAA proxy encountering non-UTF8 characters within 606 what it expects to be an NAI. An example of this requirement is 607 [RFC3579] Section 2.1, which states: 609 the NAS MUST copy the contents of the Type-Data field of the 610 EAP-Response/Identity received from the peer into the User-Name 611 attribute 613 As a result, AAA proxies expect the contents of the EAP- 614 Response/Identity sent by an EAP supplicant to consist of UTF-8 615 characters, not localized text. Using localized text in AAA username 616 or identity fields means that realm routing becomes difficult or 617 impossible. 619 In contrast to [RFC4282] Section 2.4, we expect AAA systems to 620 perform NAI comparisons, matching, and AAA routing based on the NAI 621 as it is received. This specification provides a canonical 622 representation, ensures that intermediate AAA systems such as proxies 623 are not required to perform translations, and can be expected to work 624 through AAA systems that are unaware of international character sets. 626 In an ideal world, the following requirements would be widely 627 implemented: 629 * Edge systems using "localized" text SHOULD normalize the NAI 630 prior to it being used as an identifier in an authentication 631 protocol. 633 * AAA systems SHOULD NOT normalize the NAI, as they may not have 634 sufficient information to perform the normalization. 636 There are issues with this approach, however. 638 2.6.1. Issues with the Normalization Process 640 We recognize that the requirements in the preceding section are not 641 implemented today. For example, most EAP implementations use a user 642 identifier which is passed to them from some other local system. 643 This identifier is treated as an opaque blob, and is placed as-is 644 into the EAP Identity field. Any subsequent system which receives 645 that identifier is assumed to be able to understand and process it. 647 This opaque blob unfortunately can contain localized text, which 648 means that the AAA systems have to process that text. 650 These limitations have the following theoretical and practical 651 implications. 653 * edge systems used today generally do not normalize the NAI 655 * Therefore AAA systems SHOUD attempt to normalize the NAI 657 The suggestion in the above sentence contradicts the suggestion in 658 the previous section. This is the reality of imperfect protocols. 660 Where the user identifier can be normalized, or determined to be in 661 normal form, the normal form MUST be used as the NAI. In all other 662 circumstances, the user identifier MUST NOT be treated as an NAI. 663 That data is still, however, a user identifier. AAA systems MUST NOT 664 fail authentication simply because the user identifier is not an NAI. 666 That is, when the realm portion of the NAI is not recognized by an 667 AAA server, it SHOULD try to normalize the NAI into NFC form. That 668 normalized form can then be used to see if the realm matches a known 669 realm. If no match is found, the original form of the NAI SHOULD be 670 used in all subsequent processing. 672 The AAA server may also convert realms to punycode, and perform all 673 realm comparisons on the resulting punycode strings. This conversion 674 follows the recommendations above, but may have different operational 675 effects and failure modes. 677 2.7. Use in Other Protocols 679 As noted earlier, the NAI MAY be used in other, non-AAA protocols. 680 It is RECOMMENDED that the definition given here be used unchanged. 681 Using other definitions for user identifiers may hinder 682 interoperability, along with the users ability to authenticate 683 successfully. It is RECOMMENDED that protocols requiring the use of 684 a user identifier reference this specification, and suggest that the 685 use of an NAI is RECOMMENDED. 687 We cannot require other protocols to use the NAI for user 688 identifiers. Their needs are unknown, and unknowable. We simply 689 suggest that interoperability and inter-domain authentication is 690 useful, and should be encouraged. 692 Where a protocol is 8-bit clean, it can likely transport the NAI as- 693 is, without further modification. 695 Where a protocol is not 8-bit clean, it cannot transport the NAI as- 696 is. Instead, we presume that a protocol-specific transport layer 697 takes care of encoding the NAI on input to the protocol, and decoding 698 it when the NAI exits the protocol. The encoded or escaped version 699 of the NAI is not a valid NAI, and MUST NOT be presented to the AAA 700 system. 702 For example, HTTP carries user identifiers, but escapes the '.' 703 character as "%2E" (among others). When we desire HTTP to transport 704 the NAI "fred@example.com", the data as transported will be in the 705 form "fred@example%2Ecom". That data exists only within HTTP, and 706 has no relevance to any AAA system. 708 Any comparison, validation, or use of the NAI MUST be done on its un- 709 escaped (i.e. utf8-clean) form. 711 2.8. Using the NAI format for other identifiers 713 As discussed in Section 1, above, is RECOMMENDED that the NAI format 714 be used as the standard format for user identifiers. This section 715 discusses that use in more detail. 717 It is often useful to create new identifiers for use in specific 718 contexts. These identifiers may have a number of different 719 properties, most of which are unimportant to this document. For our 720 purposes, we are interested in identifiers which need to be in a 721 well-known format, and to have namespaces. The NAI format fits these 722 requirements. 724 One example of such use is the "private user identity", which is an 725 identifier defined by the 3rd-Generation Partnership Project (3GPP). 726 That identifier is used to uniquely identify the user to the network. 727 The identifier is used for authorization, authentication, accounting, 728 administation, etc. The "private user identity" is globally unique, 729 and is defined by the home network operator. The format of the 730 identifier is explicitly the NAI, as stated by Section 13.3 of 731 [3GPP]: 733 The private user identity shall take the form of an NAI, and shall 734 have the form username@realm as specified in clause 2.1 of IETF 735 RFC 4282 737 For 3GPP, the "username" portion is a unique identifier which is 738 derived from device-specific information. The "realm" portion is 739 composed of information about the home network, followed by the base 740 string "3gppnetwork.org". e.g. 741 234150999999999@ims.mnc015.mcc234.3gppnetwork.org. 743 This format ensures that the identifier is globally unique, as it is 744 based off of the "3gppnetwork.org" domain. It ensures that the 745 "realm" portion is specific to a particular home network (or 746 organization), via the "ims.mnc015.mcc234" prefix to the realm. 747 Finally, it ensures that the "username" portion follows a well-known 748 format. 750 We suggest that the NAI format be used for all new specifications 751 and/or protocols where a user identifier is required. It is 752 RECOMMENDED that methods similar to that described above for 3GPP be 753 used to derive the identifier. 755 3. Routing inside of AAA Systems 757 Many AAA systems use the "utf8-realm" portion of the NAI to route 758 requests within a AAA proxy network. The semantics of this operation 759 involves a logical AAA routing table, where the "utf8-realm" portion 760 acts as a key, and the values stored in the table are one or more 761 "next hop" AAA servers. 763 Intermediate nodes MUST use the "utf8-realm" portion of the NAI 764 without modification to perform this lookup. As noted earlier, 765 intermediate nodes may not have access to the same locale information 766 as the system which injected the NAI into the AAA routing systems. 767 Therefore, almost all "case insensitive" comparisons can be wrong. 768 Where the "utf8-realm" is entirely ASCII, current AAA systems 769 sometimes perform case-insensitive matching on realms. This method 770 MAY be continued, as it has been shown to work in practice. 772 We also note that many existing non-AAA systems have user identifiers 773 which are similar in format to the NAI, but which are not compliant 774 with this specification. For example, they may use non-NFC form, or 775 they may have multiple "@" characters in the user identifier. 776 Intermediate nodes SHOULD normalize non-NFC identifiers to NFC, prior 777 to looking up the "utf8-realm" in the logical routing table. 778 Intermediate nodes MUST NOT modify the identifiers that they forward. 779 The data as entered by the user is inviolate. 781 The "utf8-realm" provisioned in the logical AAA routing table SHOULD 782 be provisioned to the proxy prior to it receiving any AAA traffic. 783 The "utf8-realm" SHOULD be supplied by the "next hop" or "home" 784 system that also supplies the routing information necessary for 785 packets to reach the next hop. 787 This "next hop" information may be any of, or all of, the following 788 information: IP address; port; RADIUS shared secret; TLS certificate; 789 DNS host name; or instruction to use dyanmic DNS discovery (i.e. look 790 up a record in the "utf8-realm" domain). This list is not 791 exhaustive, and my be extended by future specifications. 793 It is RECOMMENDED to use the entirety of the "utf8-realm" for the 794 routing decisions. However, AAA systems MAY use a portion of the 795 "utf8-realm" portion, so long as that portion is a valid 796 "utf8-realm", and that portion is handled as above. For example, 797 routing "fred@example.com" to a "com" destination is forbidden, 798 because "com" is not a valid "utf8-realm". However, routing 799 "fred@sales.example.com" to the "example.com" destination is 800 permissible. 802 Another reason to forbid the use of a single label (e.g. 804 "fred@sales") is that many non-AAA systems treat a single label as 805 being a local identifier within their realm. That is, a user logging 806 in as "fred@sales" to a domain "example.com", would be treated as if 807 the NAI was instead "fred@sales.example.com". Permitting the use of 808 a single label would mean changing the interpretation and meaning of 809 a single label, which cannot be done. 811 3.1. Compatibility with Email Usernames 813 As proposed in this document, the Network Access Identifier is of the 814 form "user@realm". Please note that while the user portion of the 815 NAI is based on the BNF described in [RFC5198], it has been modified 816 for the purposes of Section 2.2. It does not permit quoted text 817 along with "folding" or "non-folding" whitespace that is commonly 818 used in email addresses. As such, the NAI is not necessarily 819 equivalent to usernames used in e-mail. 821 However, it is a common practice to use email addresses as user 822 identifiers in AAA systems. The ABNF in Section 2.2 is defined to be 823 close to the "utf8-addr-spec" portion of [RFC5335], while still being 824 compatible with [RFC4282]. 826 In contrast to [RFC4282] Section 2.5, we state that the 827 internationalization requirements for NAIs and email addresses are 828 substantially similar. The NAI and email identifiers may be the 829 same, and both need to be entered by the user and/or the operator 830 supplying network access to that user. There is therefore good 831 reason for the internationalization requirements to be similar. 833 3.2. Compatibility with DNS 835 The "utf8-realm" portion of the NAI is intended to be compatible with 836 Internationalized Domain Names (IDNs) [RFC5890]. As defined above, 837 the "utf8-realm" portion as transported within an 8-bit clean 838 protocol such as RADIUS and EAP can contain any valid UTF8 character. 839 There is therefore no reason for a NAS to apply the ToAscii function 840 to the "utf8-realm" portion of an NAI, prior to placing the NAI into 841 a RADIUS User-Name attribute. 843 The NAI does not make a distinction between A-labels and U-labels, as 844 those are terms specific to DNS. It is instead an IDNA-valid label, 845 as per the first item in Section 2.3.2.1 of [RFC5890]. As noted in 846 that section, the term "IDNA-valid label" encompases both of the 847 terms A-label and U-label. 849 When the realm portion of the NAI is used as the basis for name 850 resolution, it may be necessary to convert internationalized realm 851 names to ASCII using the ToASCII operation defined in [RFC5890]. As 852 noted in [RFC6055] Section 2, resolver Application Programming 853 Interfaces (APIs) are not necessarily DNS-specific, so that the 854 ToASCII operation needs to be applied carefully: 856 Applications which convert an IDN to A-label form before calling (for 857 example) getaddrinfo() will result in name resolution failures if the 858 Punycode name is directly used in such protocols. Having libraries 859 or protocols to convert from A-labels to the encoding scheme defined 860 by the protocol (e.g., UTF-8) would require changes to APIs and/or 861 servers, which IDNA was intended to avoid. 863 As a result, applications SHOULD NOT assume that non-ASCII names are 864 resolvable using the public DNS and blindly convert them to A-labels 865 without knowledge of what protocol will be selected by the name 866 resolution library. 868 3.3. Realm Construction 870 The home realm usually appears in the "utf8-realm" portion of the 871 NAI, but in some cases a different realm can be used. This may be 872 useful, for instance, when the home realm is reachable only via 873 intermediate proxies. 875 Such usage may prevent interoperability unless the parties involved 876 have a mutual agreement that the usage is allowed. In particular, 877 NAIs MUST NOT use a different realm than the home realm unless the 878 sender has explicit knowledge that (a) the specified other realm is 879 available and (b) the other realm supports such usage. The sender 880 may determine the fulfillment of these conditions through a database, 881 dynamic discovery, or other means not specified here. Note that the 882 first condition is affected by roaming, as the availability of the 883 other realm may depend on the user's location or the desired 884 application. 886 The use of the home realm MUST be the default unless otherwise 887 configured. 889 3.3.1. Historical Practices 891 Some AAA systems have historically used NAI modifications with 892 multiple "prefix" and "suffix" decorations to perform explicit 893 routing through multiple proxies inside of a AAA network. This 894 practice is NOT RECOMMENDED for the following reasons: 896 * Using explicit routing paths is fragile, and is unresponsive to 897 changes in the network due to servers going up or down, or to 898 changing business relationships. 900 * There is no RADIUS routing protocol, meaning that routing paths 901 have to be communicated "out of band" to all intermediate AAA 902 nodes, and also to all edge systems (e.g. supplicants) expecting 903 to obtain network access. 905 * Using explicit routing paths requires thousands, if not 906 millions of edge systems to be updated with new path information 907 when a AAA routing path changes. This adds huge expense for 908 updates that would be better done at only a few AAA systems in the 909 network. 911 * Manual updates to RADIUS paths are expensive, time-consuming, 912 and prone to error. 914 * Creating compatible formats for the NAI is difficult 915 when locally-defined "prefixes" and "suffixes" conflict with 916 similar practices elsewhere in the network. These conflicts mean 917 that connecting two networks may be impossible in some cases, as 918 there is no way for packets to be routed properly in a way that 919 meets all requirements at all intermediate proxies. 921 * Leveraging the DNS name system for realm names establishes 922 a globally unique name space for realms. 924 In summary, network practices and capabilities have changed 925 significantly since NAIs were first overloaded to define AAA routes 926 through a network. While explicit path routing was once useful, the 927 time has come for better methods to be used. 929 3.4. Examples 931 Examples of valid Network Access Identifiers include the following: 933 bob 934 joe@example.com 935 fred@foo-9.example.com 936 jack@3rd.depts.example.com 937 fred.smith@example.com 938 fred_smith@example.com 939 fred$@example.com 940 fred=?#$&*+-/^smith@example.com 941 nancy@eng.example.net 942 eng.example.net!nancy@example.net 943 eng%nancy@example.net 944 @privatecorp.example.net 945 \(user\)@example.net 947 An additional valid NAI is the following, given as a hex string, as 948 this document can only contain ASCII characters. 950 626f 6240 ceb4 cebf ceba ceb9 cebc ceae 2e63 6f6d 952 Examples of invalid Network Access Identifiers include the following: 954 fred@example 955 fred@example_9.com 956 fred@example.net@example.net 957 fred.@example.net 958 eng:nancy@example.net 959 eng;nancy@example.net 960 (user)@example.net 961 @example.net 963 One example given in [RFC4282] is still permitted by the ABNF, but it 964 is NOT RECOMMMENDED because of the use of the ToAscii function to 965 create an ASCII encoding from what is now a valid UTF-8 string. 967 alice@xn--tmonesimerkki-bfbb.example.net 969 4. Security Considerations 971 Since an NAI reveals the home affiliation of a user, it may assist an 972 attacker in further probing the username space. Typically, this 973 problem is of most concern in protocols that transmit the username in 974 clear-text across the Internet, such as in RADIUS, described in 975 [RFC2865] and [RFC2866]. In order to prevent snooping of the 976 username, protocols may use confidentiality services provided by 977 protocols transporting them, such as RADIUS protected by IPsec 978 [RFC3579] or Diameter protected by TLS [RFC6733]. 980 This specification adds the possibility of hiding the username part 981 in the NAI, by omitting it. As discussed in Section 2.4, this is 982 possible only when NAIs are used together with a separate 983 authentication method that can transfer the username in a secure 984 manner. In some cases, application-specific privacy mechanism have 985 also been used with NAIs. For instance, some EAP methods apply 986 method-specific pseudonyms in the username part of the NAI [RFC3748]. 987 While neither of these approaches can protect the realm part, their 988 advantage over transport protection is that privacy of the username 989 is protected, even through intermediate nodes such as NASes. 991 4.1. Correlation of Identities over Time and Protocols 993 The recommendations in Section 2.7 and Section 2.8 for using the NAI 994 in other protocols has implications for privacy. Any attacker who is 995 capable of observing traffic containing the NAI can track the user, 996 and correlate his activity across time and across multiple protocols. 997 The authentication credentials therefore SHOULD be transported over 998 channels which permit private communications, or multiple identifiers 999 SHOULD be used, so that user tracking is impossible. 1001 It is RECOMMENDED that user privacy be enhanced by configuring 1002 multiple identifiers for one user. These identifiers can be changed 1003 over time, in order to make user tracking more difficult for a 1004 malicous observer. However, we recognise that provisioning and 1005 management of the identifiers may be difficult in to do in practice, 1006 which is likely why multiple identifiers are rarely used today. 1008 4.2. Multiple Identifiers 1010 Section 1.3 states that multiple identifier formats allow attackers 1011 to make contradictory claims without being detected. This statement 1012 deserves further discussion. 1014 Section 2.4 discussed "inner" and "outer" identifiers in the context 1015 of TTLS [RFC5281]. A close reading of that specification shows there 1016 is no requirement that the inner and outer identifiers be in any way 1017 related. That is, it is perfectly valid to use "@example.com" for an 1018 outer identifier, and "user@example.org" as an inner identifier. The 1019 authentication request will then be routed to "example.com", which 1020 will likely be unable to authenticate "user@example.org". 1022 Even worse, a misconfiguration of "example.com" means that it may in 1023 turn proxy the inner authentication request to the "example.org" 1024 domain. Such cross-domain authentication is highly problematic, and 1025 there are few good reasons to allow it. 1027 It is therefore RECOMMENDED that systems which permit anonymous 1028 "outer" identifiers require that the both the "outer" and "inner" 1029 identifiers use the same realm. An authentication request using 1030 different realms is a security violation, and the request SHOULD be 1031 rejected. 1033 The situation gets worse when multiple protocols are involved. The 1034 TTLS protocol permits MS-CHAP [RFC2433] to be carried inside of the 1035 TLS tunnel. MS-CHAP defines its own identifier which is encapsulated 1036 inside of the MS-CHAP exchange. That identifier is not required to 1037 be UTF-8, and in practice, can be one of many unknown character sets. 1038 There is no way in practice to determine which character set was used 1039 for that identifier. 1041 The result is that the "outer" EAP Identity carried by TTLS is likely 1042 to not even share the same character set as the "inner" identifier 1043 used by MS-CHAP. The two identifiers are entirely independent, and 1044 fundamentally incomparable. 1046 Such protocol design is NOT RECOMMENDED. 1048 5. Administration of Names 1050 In order to avoid creating any new administrative procedures, 1051 administration of the NAI realm namespace piggybacks on the 1052 administration of the DNS namespace. 1054 NAI realm names are required to be unique, and the rights to use a 1055 given NAI realm for roaming purposes are obtained coincident with 1056 acquiring the rights to use a particular Fully Qualified Domain Name 1057 (FQDN). Those wishing to use an NAI realm name should first acquire 1058 the rights to use the corresponding FQDN. Administrators MUST NOT 1059 publicly use an NAI realm without first owning the corresponding 1060 FQDN. Private use of unowned NAI realms within an administative 1061 domain is allowed, though it is RECOMMENDED that example names be 1062 used, such as "example.com". 1064 Note that the use of an FQDN as the realm name does not require use 1065 of the DNS for location of the authentication server. While Diameter 1066 [RFC6733] supports the use of DNS for location of authentication 1067 servers, existing RADIUS implementations typically use proxy 1068 configuration files in order to locate authentication servers within 1069 a domain and perform authentication routing. The implementations 1070 described in [RFC2194] did not use DNS for location of the 1071 authentication server within a domain. Similarly, existing 1072 implementations have not found a need for dynamic routing protocols 1073 or propagation of global routing information. Note also that there 1074 is no requirement that the NAI represent a valid email address. 1076 6. IANA Considerations 1078 This document has no actions for IANA. 1080 7. References 1082 7.1. Normative References 1084 [RFC2119] 1085 Bradner, S., "Key words for use in RFCs to Indicate Requirement 1086 Levels", RFC 2119, March, 1997. 1088 [RFC3629] 1089 Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, 1090 RFC 3629, November 2003. 1092 [RFC5198] 1093 Klensin J., and Padlipsky M., "Unicode Format for Network 1094 Interchange", RFC 5198, March 2008 1096 [RFC5234] 1097 Crocker, D. and P. Overell, "Augmented BNF for Syntax 1098 Specifications: ABNF", RFC 5234, January 2008. 1100 [RFC5890] 1101 Faltstrom, P., Hoffman, P., and A. Costello, "Internationalizing 1102 Domain Names in Applications (IDNA)", RFC 5890, August 2010 1104 [RFC6365] 1105 Hoffman, P., and Klensin, J., "Terminology Used in 1106 Internationalization in the IETF", RFC 6365, September 2011 1108 7.2. Informative References 1110 [RFC2194] 1111 Aboba, B., Lu, J., Alsop, J., Ding, J., and W. Wang, "Review of 1112 Roaming Implementations", RFC 2194, September 1997. 1114 [RFC2341] 1115 Valencia, A., Littlewood, M., and T. Kolar, "Cisco Layer Two 1116 Forwarding (Protocol) "L2F"", RFC 2341, May 1998. 1118 [RFC2433] 1119 Zorn G., and Cobb, S. "Microsoft PPP CHAP Extensions", RFC 2433, 1120 October 1998. 1122 [RFC2637] 1123 Hamzeh, K., Pall, G., Verthein, W., Taarud, J., Little, W., and G. 1124 Zorn, "Point-to-Point Tunneling Protocol", RFC 2637, July 1999. 1126 [RFC2661] 1127 Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G., and B. 1128 Palter, "Layer Two Tunneling Protocol "L2TP"", RFC 2661, August 1129 1999. 1131 [RFC2865] 1132 Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote 1133 Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. 1135 [RFC2866] 1136 Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. 1138 [RFC3579] 1139 Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial In 1140 User Service) Support For Extensible Authentication Protocol 1141 (EAP)", RFC 3579, September 2003. 1143 [RFC3748] 1144 Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 1145 Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, 1146 June 2004. 1148 [RFC4282] 1149 Aboba, B. et al., "The Network Access Identifier", RFC 4282, 1150 December 2005. 1152 [RFC4301] 1153 Kent, S. and S. Keo, "Security Architecture for the Internet 1154 Protocol", RFC 4301, December 2005. 1156 [RFC5335] 1157 Y. Abel, Ed., "Internationalized Email Headers", RFC 5335, 1158 September 2008. 1160 [EDUROAM] 1161 http://eduroam.org, "eduroam (EDUcational ROAMing)" 1163 [RFC5281] 1164 Funk, P., and Blake-Wilson, S., "Extensible Authentication Protocol 1165 Tunneled Transport Layer Security Authenticated Protocol Version 0 1166 (EAP-TTLSv0)", RFC 5281, August 2008/ 1168 [RFC5891] 1169 Klensin, J., "Internationalized Domain Names in Applications 1170 (IDNA): Protocol", RFC 5891, August 2010 1172 [RFC6055] 1173 Thaler, D., et al, "IAB Thoughts on Encodings for Internationalized 1174 Domain Names", RFC 6055, February 2011. 1176 [RFC6733] 1177 V. Fajardo, Ed., et al, "Diameter Base Protocol", RFC 6733, October 1178 2012. 1180 [RFC6912] 1181 Sullivan, A., et al, "Principles for Unicode Code Point Inclusion 1182 in Labels in the DNS", RFC 6912, April 2013. 1184 [3GPP] 1185 3GPP, "TS 23.003 Numbering, addressing, and Identification (Release 1186 12)", July 2014, 1187 ftp://ftp.3gpp.org/Specs/archive/23_series/23.003/. 1189 Acknowledgments 1191 The initial text for this document was [RFC4282], which was then 1192 heavily edited. The original authors of [RFC4282] were Bernard 1193 Aboba, Mark A. Beadles, Jari Arkko, and Pasi Eronen. 1195 The ABNF validator at http://www.apps.ietf.org/abnf.html was used to 1196 verify the syntactic correctness of the ABNF in Section 2. 1198 Appendix A - Changes from RFC4282 1200 This document contains the following updates with respect to the 1201 previous NAI definition in RFC 4282 [RFC4282]: 1203 * The formal syntax in Section 2.1 has been updated to forbid 1204 non-UTF8 characters. e.g. characters with the "high bit" set. 1206 * The formal syntax in Section 2.1 has been updated to allow 1207 UTF-8 in the "realm" portion of the NAI. 1209 * The formal syntax in [RFC4282] Section 2.1 applied to the 1210 NAI after it was "internationalized" via the ToAscii function. 1211 The contents of the NAI before it was "internationalized" were 1212 left indeterminate. This document updates the formal syntax to 1213 define an internationalized form of the NAI, and forbids the use 1214 of the ToAscii function for NAI "internationalization". 1216 * The grammar for the user and realm portion is based on a 1217 combination 1218 of the "nai" defined in [RFC4282] Section 2.1, and the "utf8-addr- 1219 spec" defined in [RFC5335] Section 4.4. 1221 * All use of the ToAscii function has been moved to normal 1222 requirements on DNS implementations when realms are used as the 1223 basis for DNS lookups. This involves no changes to the existing 1224 DNS infrastructure. 1226 * The discussions on internationalized character sets in Section 2.4 1227 have been updated. The suggestion to use the ToAscii function for 1228 realm comparisons has been removed. No AAA system has implemented 1229 these suggestions, so this change should have no operational 1230 impact. 1232 * The section "Routing inside of AAA Systems" section is new in this 1233 document. The concept of a "local AAA routing table" is also new, 1234 although it accurately describes the functionality of wide-spread 1235 implementations. 1237 * The "Compatibility with EMail Usernames" and "Compatibility 1238 with DNS" sections have been revised and updated. We now note 1239 that the ToAscii function is suggested to be used only when a 1240 realm name is used for DNS lookups, and even then the function is 1241 only used by a resolving API on the local system, and even then we 1242 recommend that only the home network perform this conversion. 1244 * The "Realm Construction" section has been updated to note 1245 that editing of the NAI is NOT RECOMMENDED. 1247 * The "Examples" section has been updated to remove the instance 1248 of the IDN being converted to ASCII. This behavior is now 1249 forbidden. 1251 Authors' Addresses 1253 Alan DeKok 1254 The FreeRADIUS Server Project 1256 Email: aland@freeradius.org