idnits 2.17.1 draft-ietf-radext-nai-10.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 (29 October 2014) is 3466 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 29 October 2014 9 The Network Access Identifier 10 draft-ietf-radext-nai-10 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 identity 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 April 29, 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 ......................................... 5 78 1.2. Requirements Language ............................... 6 79 1.3. Purpose ............................................. 7 80 1.4. Motivation .......................................... 8 81 2. NAI Definition ........................................... 9 82 2.1. UTF-8 Syntax and Normalization ...................... 9 83 2.2. Formal Syntax ....................................... 10 84 2.3. NAI Length Considerations ........................... 10 85 2.4. Support for Username Privacy ........................ 11 86 2.5. International Character Sets ........................ 11 87 2.6. The Normalization Process ........................... 12 88 2.6.1. Issues with the Normalization Process .......... 13 89 2.7. Use in Other Protocols .............................. 14 90 2.8. Using the NAI format for other identifiers .......... 15 91 3. Routing inside of AAA Systems ............................ 16 92 3.1. Compatibility with Email Usernames .................. 17 93 3.2. Compatibility with DNS .............................. 17 94 3.3. Realm Construction .................................. 18 95 3.3.1. Historical Practices ........................... 19 96 3.4. Examples ............................................ 19 97 4. Security Considerations .................................. 20 98 5. Administration of Names .................................. 21 99 6. IANA Considerations ...................................... 21 100 7. References ............................................... 21 101 7.1. Normative References ................................ 21 102 7.2. Informative References .............................. 22 103 Appendix A - Changes from RFC4282 ............................ 25 104 1. Introduction 106 Considerable interest exists for a set of features that fit within 107 the general category of inter-domain authentication, or "roaming 108 capability" for network access, including dialup Internet users, 109 Virtual Private Network (VPN) usage, wireless LAN authentication, and 110 other applications. Interested parties have included the following: 112 * Regional Internet Service Providers (ISPs) operating within a 113 particular state or province, looking to combine their efforts 114 with those of other regional providers to offer dialup service 115 over a wider area. 117 * National ISPs wishing to combine their operations with those of 118 one or more ISPs in another nation to offer more comprehensive 119 dialup service in a group of countries or on a continent. 121 * Wireless LAN hotspots providing service to one or more ISPs. 123 * Businesses desiring to offer their employees a comprehensive 124 package of dialup services on a global basis. Those services may 125 include Internet access as well as secure access to corporate 126 intranets via a VPN, enabled by tunneling protocols such as the 127 Point-to-Point Tunneling Protocol (PPTP) [RFC2637], the Layer 2 128 Forwarding (L2F) protocol [RFC2341], the Layer 2 Tunneling 129 Protocol (L2TP) [RFC2661], and the IPsec tunnel mode [RFC4301]. 131 * Other protocols which are interested in leveraging the users 132 credentials in order to take advantage of an existing 133 authentication framework. 135 In order to enhance the interoperability of these services, it is 136 necessary to have a standardized method for identifying users. This 137 document defines syntax for the Network Access Identifier (NAI). 138 Examples of implementations that use the NAI, and descriptions of its 139 semantics, can be found in [RFC2194]. 141 When the NAI was defined for network access, it had the side effect 142 of defining an identifier which could be used in non-AAA systems. 143 Some non-AAA systems defined identifiers which were compatible with 144 the NAI, and deployments used the NAI. This process simplified the 145 management of credentials, by re-using the same credential in 146 multiple situations. We suggest that this re-use is good practice. 147 The alternative is to have protocol-specific identifiers, which 148 increases cost to both user and administrator. 150 The goal of this document is to define the format of an identifier 151 which can be used in many protocols. A protocol may transport an 152 encoded version of the NAI (e.g. '.' as %2E). However, the 153 definition of the NAI is protocol independent. We hope to encourage 154 the wide-spread adoption of the NAI as an identifier. This adoption 155 will decrease work required to leverage identification and 156 authentication in other protocols. It will also decrease the 157 complexity of non-AAA systems for end users and administrators. 159 We note that this document only suggest that the NAI be used, but 160 does not require such use. Many protocols already define their own 161 identifier formats. Some of these are incompatible with the NAI, 162 while others allow the NAI in addition to non-NAI identifiers. The 163 definition of the NAI in this document has no requirements on 164 protocol specifications, implementations, or deployments. 166 However, we suggest that using one standard identifier format is 167 preferable to using multiple incompatible identifier formats. Where 168 identifiers need to be used in new protocols and/or specifications, 169 it is RECOMMENDED that the format of the NAI be used. That is, the 170 interpretation of the identifier is context-specific, while the 171 format of the identifier remains the same. These issues are 172 discussed in more detail in Section 2.8, below. 174 This document is a revised version of [RFC4282], which originally 175 defined internationalized NAIs. Differences and enhancements 176 compared to that document are listed in Appendix A. 178 1.1. Terminology 180 This document frequently uses the following terms: 182 "Local" or "localized" text 184 Text which is either in non-UTF-8, or in non-normalized form. The 185 character set, encoding, and locale are (in general) unknown to 186 Authentication, Authorization, and Accounting (AAA) network 187 protocols. The client which "knows" the locale may have a 188 different concept of this text than other AAA entities, which do 189 not know the same locale. 191 Network Access Identifier 193 The Network Access Identifier (NAI) is the user identity submitted 194 by a client during authentication. The purpose of the NAI is to 195 identify the user as well as to assist in the routing of the 196 authentication request. Please note that the NAI may not 197 necessarily be the same as the user's email address or the user 198 identity submitted in an application layer authentication. 200 Network Access Server 202 The Network Access Server (NAS) is the device that clients connect 203 to in order to get access to the network. In PPTP terminology, 204 this is referred to as the PPTP Access Concentrator (PAC), and in 205 L2TP terminology, it is referred to as the L2TP Access 206 Concentrator (LAC). In IEEE 802.11, it is referred to as an 207 Access Point. 209 Roaming Capability 211 Roaming capability can be loosely defined as the ability to use 212 any one of multiple Internet Service Providers (ISPs), while 213 maintaining a formal, customer-vendor relationship with only one. 214 Examples of cases where roaming capability might be required 215 include ISP "confederations" and ISP-provided corporate network 216 access support. 218 Normalization or Canonicalization 220 These terms are defined in [RFC6365] Section 4. We incorporate 221 the definitions here by reference. 223 Locale 225 This term is defined in [RFC6365] Section 8. We incorporate the 226 definition here by reference. 228 Tunneling Service 230 A tunneling service is any network service enabled by tunneling 231 protocols such as PPTP, L2F, L2TP, and IPsec tunnel mode. One 232 example of a tunneling service is secure access to corporate 233 intranets via a Virtual Private Network (VPN). 235 1.2. Requirements Language 237 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 238 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 239 "OPTIONAL" in this document are to be interpreted as described in 240 [RFC2119]. 242 1.3. Purpose 244 As described in [RFC2194], there are a number of providers offering 245 network access services, and the number of Internet Service Providers 246 involved in roaming consortia is increasing rapidly. 248 In order to be able to offer roaming capability, one of the 249 requirements is to be able to identify the user's home authentication 250 server. For use in roaming, this function is accomplished via the 251 Network Access Identifier (NAI) submitted by the user to the NAS in 252 the initial network authentication. It is also expected that NASes 253 will use the NAI as part of the process of opening a new tunnel, in 254 order to determine the tunnel endpoint. 256 We also hope that other protocols can take advantage of the NAI. 257 Many protocols include authentication capabilities, including 258 defining their own identifier formats. These identifiers can then 259 end up being transported in AAA protocols, so that the originating 260 protocols can leverage AAA for user authentication. There is 261 therefore a need for a definition of a user identifier which can be 262 used in multiple protocols. 264 While we define the NAI here, we recognize that existing protocols 265 and deployments do not always use it. AAA systems MUST therefore be 266 able to handle user identifiers which are not in the NAI format. The 267 process by which that is done is outside of the scope of this 268 document. 270 Non-AAA systems MAY accept user identifiers in forms other than the 271 NAI. This specification does not forbid that practice. It only 272 codifies the format and interpretation of the NAI. We cannot expect 273 to change existing protocols or practices. We can, however, suggest 274 that using a consistent form for a user identifier is of a benefit to 275 the community. 277 We note that this document does not make any protocol-specific 278 definitions for an identifier format, and it does not make changes to 279 any existing protocol. Instead, it defines a protocol-independent 280 form for the NAI. It is hoped that the NAI is a user identifier 281 which can be used in multiple protocols. 283 Using a common identifier simplifies deployments, as there is no need 284 to maintain multiple identifiers for one user. It simplifies 285 protocols requiring authentication, as they no longer need to specify 286 protocol-specific format for user identifiers. It increases 287 security, as it multiple identifiers allow attackers to make 288 contradictory claims without being detected. 290 In short, having a standard is better than having no standard at all. 292 1.4. Motivation 294 The changes from [RFC4282] are listed in detail in Appendix A. 295 However, some additional discussion is appropriate to motivate those 296 changes. 298 The motivation to revise [RFC4282] began with internationalization 299 concerns raised in the context of [EDUROAM]. Section 2.1 of 300 [RFC4282] defines ABNF for realms which limits the realm grammar to 301 English letters, digits, and the hyphen "-" character. The intent 302 appears to have been to encode, compare, and transport realms with 303 the ToASCII operation defined in [RFC5890]. There are a number of 304 problems with this approach: 306 * The [RFC4282] ABNF is not aligned with internationalization of DNS. 308 * The requirement in [RFC4282] Section 2.1 that realms are ASCII 309 conflicts with the Extensible Authentication Protocol (EAP) and 310 RADIUS, which are both 8-bit clean, and which both recommend the 311 use of UTF-8 for identitifiers. 313 * [RFC4282] Section 2.4 required mappings that are 314 language-specific, and which are nearly impossible for 315 intermediate nodes to perform correctly without information about 316 that language. 318 * [RFC4282] Section 2.4 requires normalization of user names, 319 which may conflict with local system or administrative 320 requirements. 322 * The recommendations in RFC4282] Section 2.4 for treatment of 323 bidirectional characters have proven to be unworkable. 325 * The prohibition against use of unassigned code points in 326 RFC4282] Section 2.4 effectively prohibits support for new 327 scripts. 329 * No Authentication, Authorization, and Accounting (AAA) 330 client, proxy, or server has implemented any of the requirements 331 in [RFC4282] Section 2.4, among other sections. 333 With international roaming growing in popularity, it is important for 334 these issues to be corrected in order to provide robust and inter- 335 operable network services. 337 2. NAI Definition 339 2.1. UTF-8 Syntax and Normalization 341 UTF-8 characters can be defined in terms of octets using the 342 following ABNF [RFC5234], taken from [RFC3629]: 344 UTF8-xtra-char = UTF8-2 / UTF8-3 / UTF8-4 346 UTF8-2 = %xC2-DF UTF8-tail 348 UTF8-3 = %xE0 %xA0-BF UTF8-tail / 349 %xE1-EC 2(UTF8-tail) / 350 %xED %x80-9F UTF8-tail / 351 %xEE-EF 2(UTF8-tail) 353 UTF8-4 = %xF0 %x90-BF 2( UTF8-tail ) / 354 %xF1-F3 3( UTF8-tail ) / 355 %xF4 %x80-8F 2( UTF8-tail ) 357 UTF8-tail = %x80-BF 359 These are normatively defined in [RFC3629], but are repeated in this 360 document for reasons of convenience. 362 See [RFC5198] and section 2.6 of this specification for a discussion 363 of normalization. Strings which are not in Normal Form Composed (NFC) 364 are not valid NAIs and SHOULD NOT be treated as such. 365 Implementations which expect to receive a NAI, but which instead 366 receive non-normalised (but otherwise valid) UTF-8 strings instead 367 SHOULD attempt to create a local version of the NAI, which is 368 normalized from the input identifier. This local version can then be 369 used for local processing. 371 Where protocols carry identifiers which are expected to be 372 transported over an AAA protocol, it is RECOMMENDED that the 373 identifiers be in NAI format. Where the identifiers are not in the 374 NAI format, it is up to the AAA systems to discover this, and to 375 process them. This document does not suggest how that is done. 376 However, existing practice indicates that it is possible. 378 We expect that with wider use of internationalized domain names, 379 existing practices will be inadequate. We therefore define the NAI, 380 which is a user identifier that can correctly deal with 381 internationalized identifiers. 383 2.2. Formal Syntax 385 The grammar for the NAI is given below, described in Augmented 386 Backus-Naur Form (ABNF) as documented in [RFC5234]. 388 nai = utf8-username 389 nai =/ "@" utf8-realm 390 nai =/ utf8-username "@" utf8-realm 392 utf8-username = dot-string 393 dot-string = string 394 dot-string =/ dot-string "." string 395 string = utf8-atext 396 string =/ string utf8-atext 398 utf8-atext = ALPHA / DIGIT / 399 "!" / "#" / 400 "$" / "%" / 401 "&" / "'" / 402 "*" / "+" / 403 "-" / "/" / 404 "=" / "?" / 405 "^" / "_" / 406 "`" / "{" / 407 "|" / "}" / 408 "~" / 409 UTF8-xtra-char 411 utf8-realm = 1*( label "." ) label 413 label = utf8-rtext *(ldh-str) 414 ldh-str = *( utf8-rtext / "-" ) utf8-rtext 415 utf8-rtext = ALPHA / DIGIT / UTF8-xtra-char 417 2.3. NAI Length Considerations 419 Devices handling NAIs MUST support an NAI length of at least 72 420 octets. Devices SHOULD support an NAI length of 253 octets. 421 However, the following implementation issues should be considered: 423 * NAI octet length constraints may impose a more severe constraint 424 on the number of UTF-8 characters. 426 * NAIs are often transported in the User-Name attribute of the 427 Remote Authentication Dial-In User Service (RADIUS) protocol. 428 Unfortunately, RFC 2865 [RFC2865], Section 5.1, states that "the 429 ability to handle at least 63 octets is recommended." As a 430 result, it may not be possible to transfer NAIs beyond 63 octets 431 through all devices. In addition, since only a single User-Name 432 attribute may be included in a RADIUS message and the maximum 433 attribute length is 253 octets; RADIUS is unable to support NAI 434 lengths beyond 253 octets. 436 * NAIs can also be transported in the User-Name attribute of 437 Diameter [RFC6733], which supports content lengths up to 2^24 - 9 438 octets. As a result, NAIs processed only by Diameter nodes can be 439 very long. However, an NAI transported over Diameter may 440 eventually be translated to RADIUS, in which case the above 441 limitations will apply. 443 * NAIs may be transported in other protocols. Each protocol 444 can have its own limitations on maximum NAI length. 445 The above criteria should permit the widest use, and widest possible 446 inter-operability of the NAI. 448 2.4. Support for Username Privacy 450 Interpretation of the username part of the NAI depends on the realm 451 in question. Therefore, the utf8-username portion SHOULD be treated 452 as opaque data when processed by nodes that are not a part of the 453 authoritative domain (in the sense of Section 4) for that realm. 455 In some situations, NAIs are used together with a separate 456 authentication method that can transfer the username part in a more 457 secure manner to increase privacy. In this case, NAIs MAY be 458 provided in an abbreviated form by omitting the username part. 459 Omitting the username part is RECOMMENDED over using a fixed username 460 part, such as "anonymous", since it provides an unambiguous way to 461 determine whether the username is intended to uniquely identify a 462 single user. However, current practice is to use the username 463 "anonymous" instead of omitting the username part. This behavior is 464 also permitted. 466 For roaming purposes, it is typically necessary to locate the 467 appropriate backend authentication server for the given NAI before 468 the authentication conversation can proceed. As a result, the realm 469 portion is typically required in order for the authentication 470 exchange to be routed to the appropriate server. 472 2.5. International Character Sets 474 This specification allows both international usernames and realms. 475 International usernames are based on the use of Unicode characters, 476 encoded as UTF-8. Internationalization of the realm portion of the 477 NAI is based on "Internationalized Email Headers" [RFC5335]. 479 In order to ensure a canonical representation, characters of the 480 username portion in an NAI MUST match the ABNF in this specification 481 as well as the requirements specified in [RFC5891]. In practice, 482 these requirements consist of the following item: 484 * Realms MUST be of the form that can be registered as a 485 Fully Qualified Domain Name (FQDN) within the DNS. 487 This list is significantly shorter and simpler than the list in 488 Section 2.4 of [RFC4282]. The form suggested in [RFC4282] depended 489 on intermediate nodes performing canonicalizations based on 490 insufficient information, which meant that the form was not 491 canonical. 493 Specifying the realm requirement as above means that the requirements 494 depend on specifications that are referenced here, rather than copied 495 here. This allows the realm definition to be updated when the 496 referenced documents change, without requiring a revision of this 497 specification. 499 One caveat on the above recommendation is the issues noted in 500 [RFC6912]. That document notes that there are additional 501 restrictions around DNS registration which forbid some code points 502 from being valid in a DNS U-label. These restrictions cannot be 503 expressed algorithmically. 505 For this specification, that caveat means the following. Realms not 506 matching the above ABNF are not valid NAIs. However, some realms 507 which do match the ABNF are still invalid NAIs. That is, matching 508 the ABNF is a necessary, but not sufficient, requirement for an NAI. 510 In general, the above requirement means following the requirements 511 specified in [RFC5891]. 513 2.6. The Normalization Process 515 Conversion to Unicode as well as normalization SHOULD be performed by 516 edge systems such as laptops that take "local" text as input. These 517 edge systems are best suited to determine the users intent, and can 518 best convert from "local" text to a normalized form. 520 Other AAA systems such as proxies do not have access to locale and 521 character set information that is available to edge systems. 522 Therefore, they may not always be able to convert local input to 523 Unicode. 525 That is, all processing of NAIs from "local" character sets and 526 locales to UTF-8 SHOULD be performed by edge systems, prior to the 527 NAIs entering the AAA system. Inside of an AAA system, NAIs are sent 528 over the wire in their canonical form, and this canonical form is 529 used for all NAI and/or realm comparisons. 531 Copying of localized text into fields that can subsequently be placed 532 into the RADIUS User-Name attribute is problematic. This practice 533 can result in a AAA proxy encountering non-UTF8 characters within 534 what it expects to be an NAI. An example of this requirement is 535 [RFC3579] Section 2.1, which states: 537 the NAS MUST copy the contents of the Type-Data field of the 538 EAP-Response/Identity received from the peer into the User-Name 539 attribute 541 As a result, AAA proxies expect the contents of the EAP- 542 Response/Identity sent by an EAP supplicant to consist of UTF-8 543 characters, not localized text. Using localized text in AAA username 544 or identity fields means that realm routing becomes difficult or 545 impossible. 547 In contrast to [RFC4282] Section 2.4, we expect AAA systems to 548 perform NAI comparisons, matching, and AAA routing based on the NAI 549 as it is received. This specification provides a canonical 550 representation, ensures that intermediate AAA systems such as proxies 551 are not required to perform translations, and can be expected to work 552 through AAA systems that are unaware of international character sets. 554 In an ideal world, the following requirements would be widely 555 implemented: 557 * Edge systems using "localized" text SHOULD normalize the NAI 558 prior to it being used as an identifier in an authentication 559 protocol. 561 * AAA systems SHOULD NOT normalize the NAI, as they may not have 562 sufficient information to perform the normalization. 564 There are issues with this approach, however. 566 2.6.1. Issues with the Normalization Process 568 We recognize that the requirements in the preceding section are not 569 implemented today. For example, most EAP implementations use a user 570 identifier which is passed to them from some other local system. 571 This identifier is treated as an opaque blob, and is placed as-is 572 into the EAP Identity field. Any subsequent system which receives 573 that identifier is assumed to be able to understand and process it. 575 This opaque blob unfortunately can contain localized text, which 576 means that the AAA systems have to process that text. 578 These limitations have the following theoretical and practical 579 implications. 581 * edge systems used today generally do not normalize the NAI 583 * Therefore AAA systems SHOUD attempt to normalize the NAI 585 The suggestion in the above sentence contradicts the suggestion in 586 the previous section. This is the reality of imperfect protocols. 588 Where the user identifier can be normalized, or determined to be in 589 normal form, the normal form MUST be used as the NAI. In all other 590 circumstances, the user identifier MUST NOT be treated as an NAI. 591 That data is still, however, a user identifier. AAA systems MUST NOT 592 fail authentication simply because the user identifier is not an NAI. 594 That is, when the realm portion of the NAI is not recognized by an 595 AAA server, it SHOULD try to normalize the NAI into NFC form. That 596 normalized form can then be used to see if the realm matches a known 597 realm. If no match is found, the original form of the NAI SHOULD be 598 used in all subsequent processing. 600 The AAA server may also convert realms to punycode, and perform all 601 realm comparisons on the resulting punycode strings. This conversion 602 follows the recommendations above, but may have different operational 603 effects and failure modes. 605 2.7. Use in Other Protocols 607 As noted earlier, the NAI MAY be used in other, non-AAA protocols. 608 It is RECOMMENDED that the definition given here be used unchanged. 609 Using other definitions for user identifiers may hinder 610 interoperability, along with the users ability to authenticate 611 successfully. It is RECOMMENDED that protocols requiring the use of 612 a user identifier reference this specification, and suggest that the 613 use of an NAI is RECOMMENDED. 615 We cannot require other protocols to use the NAI for user 616 identifiers. Their needs are unknown, and unknowable. We simply 617 suggest that interoperability and inter-domain authentication is 618 useful, and should be encouraged. 620 Where a protocol is 8-bit clean, it can likely transport the NAI as- 621 is, without further modification. 623 Where a protocol is not 8-bit clean, it cannot transport the NAI as- 624 is. Instead, we presume that a protocol-specific transport layer 625 takes care of encoding the NAI on input to the protocol, and decoding 626 it when the NAI exits the protocol. The encoded or escaped version 627 of the NAI is not a valid NAI, and MUST NOT be presented to the AAA 628 system. 630 For example, HTTP carries user identifiers, but escapes the '.' 631 character as "%2E" (among others). When we desire HTTP to transport 632 the NAI "fred@example.com", the data as transported will be in the 633 form "fred@example%2Ecom". That data exists only within HTTP, and 634 has no relevance to any AAA system. 636 Any comparison, validation, or use of the NAI MUST be done on its un- 637 escaped (i.e. utf8-clean) form. 639 2.8. Using the NAI format for other identifiers 641 As discussed in Section 1, above, is RECOMMENDED that the NAI format 642 be used as the standard format for user identifiers. This section 643 discusses that use in more detail. 645 It is often useful to create new identifiers for use in specific 646 contexts. These identifiers may have a number of different 647 properties, most of which are unimportant to this document. For our 648 purposes, we are interested in identifiers which need to be in a 649 well-known format, and to have namespaces. The NAI format fits these 650 requirements. 652 One example of such use is the "private user identity", which is 653 defined by the 3rd-Generation Partnership Project (3GPP). That 654 identity is used to uniquely identify the user to the network. The 655 identity is used for authorization, authentication, accounting, 656 administation, etc. The private user identity is globally unique, 657 and is defined by the home network operator. The format of the 658 identity is explicitly the NAI, as stated by Section 13.3 of [3GPP]: 660 The private user identity shall take the form of an NAI, and shall 661 have the form username@realm as specified in clause 2.1 of IETF 662 RFC 4282 664 For 3GPP, the "username" portion is a unique identifier which is 665 derived from device-specific information. The "realm" portion is 666 composed of information about the home network, followed by the base 667 string "3gppnetwork.org". e.g. 668 234150999999999@ims.mnc015.mcc234.3gppnetwork.org. 670 This format ensures that the identifier is globally unique, as it is 671 based off of the "3gppnetwork.org" domain. It ensures that the 672 "realm" portion is specific to a particular home network (or 673 organization), via the "ims.mnc015.mcc234" prefix to the realm. 674 Finally, it ensures that the "username" portion follows a well-known 675 format. 677 We suggest that the NAI format be used for all new specifications 678 and/or protocols where a user identifier is required. It is 679 RECOMMENDED that methods similar to that described above for 3GPP be 680 used to derive the identifier. 682 3. Routing inside of AAA Systems 684 Many AAA systems use the "utf8-realm" portion of the NAI to route 685 requests within a AAA proxy network. The semantics of this operation 686 involves a logical AAA routing table, where the "utf8-realm" portion 687 acts as a key, and the values stored in the table are one or more 688 "next hop" AAA servers. 690 Intermediate nodes MUST use the "utf8-realm" portion of the NAI 691 without modification to perform this lookup. As noted earlier, 692 intermediate nodes may not have access to the same locale information 693 as the system which injected the NAI into the AAA routing systems. 694 Therefore, almost all "case insensitive" comparisons can be wrong. 695 Where the "utf8-realm" is entirely ASCII, current AAA systems 696 sometimes perform case-insensitive matching on realms. This practice 697 MAY be continued, as it has been shown to work in practice. 699 We also note that many existing non-AAA systems have user identifiers 700 which are similar in format to the NAI, but which are not compliant 701 with this specification. For example, they may use non-NFC form, or 702 they may have multiple "@" characters in the user identifier. 703 Intermediate nodes SHOULD normalize non-NFC identifiers to NFC, prior 704 to looking up the "utf8-realm" in the logical routing table. 705 Intermediate nodes MUST NOT modify the identifiers that they forward. 706 The data as entered by the user is inviolate. 708 The "utf8-realm" provisioned in the logical AAA routing table SHOULD 709 be provisioned to the proxy prior to it receiving any AAA traffic. 710 The "utf8-realm" SHOULD be supplied by the "next hop" or "home" 711 system that also supplies the routing information necessary for 712 packets to reach the next hop. 714 This "next hop" information may be any of, or all of, the following 715 information: IP address; port; RADIUS shared secret; TLS certificate; 716 DNS host name; or instruction to use dyanmic DNS discovery (i.e. look 717 up a record in the "utf8-realm" domain). This list is not 718 exhaustive, and my be extended by future specifications. 720 It is RECOMMENDED to use the entirety of the "utf8-realm" for the 721 routing decisions. However, AAA systems MAY use a portion of the 722 "utf8-realm" portion, so long as that portion is a valid 723 "utf8-realm", and that portion is handled as above. For example, 724 routing "fred@example.com" to a "com" destination is forbidden, 725 because "com" is not a valid "utf8-realm". However, routing 726 "fred@sales.example.com" to the "example.com" destination is 727 permissible. 729 Another reason to forbid the use of a single label (e.g. 730 "fred@sales") is that many non-AAA systems treat a single label as 731 being a local identifier within their realm. That is, a user logging 732 in as "fred@sales" to a domain "example.com", would be treated as if 733 the NAI was instead "fred@sales.example.com". Permitting the use of 734 a single label would mean changing the interpretation and meaning of 735 a single label, which cannot be done. 737 3.1. Compatibility with Email Usernames 739 As proposed in this document, the Network Access Identifier is of the 740 form "user@realm". Please note that while the user portion of the 741 NAI is based on the BNF described in [RFC5198], it has been modified 742 for the purposes of Section 2.2. It does not permit quoted text 743 along with "folding" or "non-folding" whitespace that is commonly 744 used in email addresses. As such, the NAI is not necessarily 745 equivalent to usernames used in e-mail. 747 However, it is a common practice to use email addresses as user 748 identifiers in AAA systems. The ABNF in Section 2.2 is defined to be 749 close to the "utf8-addr-spec" portion of [RFC5335], while still being 750 compatible with [RFC4282]. 752 In contrast to [RFC4282] Section 2.5, we state that the 753 internationalization requirements for NAIs and email addresses are 754 substantially similar. The NAI and email identifiers may be the 755 same, and both need to be entered by the user and/or the operator 756 supplying network access to that user. There is therefore good 757 reason for the internationalization requirements to be similar. 759 3.2. Compatibility with DNS 761 The "utf8-realm" portion of the NAI is intended to be compatible with 762 Internationalized Domain Names (IDNs) [RFC5890]. As defined above, 763 the "utf8-realm" portion as transported within an 8-bit clean 764 protocol such as RADIUS and EAP can contain any valid UTF8 character. 765 There is therefore no reason for a NAS to apply the ToAscii function 766 to the "utf8-realm" portion of an NAI, prior to placing the NAI into 767 a RADIUS User-Name attribute. 769 The NAI does not make a distinction between A-labels and U-labels, as 770 those are terms specific to DNS. It is instead an IDNA-valid label, 771 as per the first item in Section 2.3.2.1 of [RFC5890]. As noted in 772 that section, the term "IDNA-valid label" encompases both of the 773 terms A-label and U-label. 775 When the realm portion of the NAI is used as the basis for name 776 resolution, it may be necessary to convert internationalized realm 777 names to ASCII using the ToASCII operation defined in [RFC5890]. As 778 noted in [RFC6055] Section 2, resolver Application Programming 779 Interfaces (APIs) are not necessarily DNS-specific, so that the 780 ToASCII operation needs to be applied carefully: 782 Applications which convert an IDN to A-label form before calling (for 783 example) getaddrinfo() will result in name resolution failures if the 784 Punycode name is directly used in such protocols. Having libraries 785 or protocols to convert from A-labels to the encoding scheme defined 786 by the protocol (e.g., UTF-8) would require changes to APIs and/or 787 servers, which IDNA was intended to avoid. 789 As a result, applications SHOULD NOT assume that non-ASCII names are 790 resolvable using the public DNS and blindly convert them to A-labels 791 without knowledge of what protocol will be selected by the name 792 resolution library. 794 3.3. Realm Construction 796 The home realm usually appears in the "utf8-realm" portion of the 797 NAI, but in some cases a different realm can be used. This may be 798 useful, for instance, when the home realm is reachable only via 799 intermediate proxies. 801 Such usage may prevent interoperability unless the parties involved 802 have a mutual agreement that the usage is allowed. In particular, 803 NAIs MUST NOT use a different realm than the home realm unless the 804 sender has explicit knowledge that (a) the specified other realm is 805 available and (b) the other realm supports such usage. The sender 806 may determine the fulfillment of these conditions through a database, 807 dynamic discovery, or other means not specified here. Note that the 808 first condition is affected by roaming, as the availability of the 809 other realm may depend on the user's location or the desired 810 application. 812 The use of the home realm MUST be the default unless otherwise 813 configured. 815 3.3.1. Historical Practices 817 Some AAA systems have historically used NAI modifications with 818 multiple "prefix" and "suffix" decorations to perform explicit 819 routing through multiple proxies inside of a AAA network. This 820 practice is NOT RECOMMENDED for the following reasons: 822 * Using explicit routing paths is fragile, and is unresponsive to 823 changes in the network due to servers going up or down, or to 824 changing business relationships. 826 * There is no RADIUS routing protocol, meaning that routing paths 827 have to be communicated "out of band" to all intermediate AAA 828 nodes, and also to all edge systems (e.g. supplicants) expecting 829 to obtain network access. 831 * Using explicit routing paths requires thousands, if not 832 millions of edge systems to be updated with new path information 833 when a AAA routing path changes. This adds huge expense for 834 updates that would be better done at only a few AAA systems in the 835 network. 837 * Manual updates to RADIUS paths are expensive, time-consuming, 838 and prone to error. 840 * Creating compatible formats for the NAI is difficult 841 when locally-defined "prefixes" and "suffixes" conflict with 842 similar practices elsewhere in the network. These conflicts mean 843 that connecting two networks may be impossible in some cases, as 844 there is no way for packets to be routed properly in a way that 845 meets all requirements at all intermediate proxies. 847 * Leveraging the DNS name system for realm names establishes 848 a globally unique name space for realms. 850 In summary, network practices and capabilities have changed 851 significantly since NAIs were first overloaded to define AAA routes 852 through a network. While explicit path routing was once useful, the 853 time has come for better methods to be used. 855 3.4. Examples 857 Examples of valid Network Access Identifiers include the following: 859 bob 860 joe@example.com 861 fred@foo-9.example.com 862 jack@3rd.depts.example.com 863 fred.smith@example.com 864 fred_smith@example.com 865 fred$@example.com 866 fred=?#$&*+-/^smith@example.com 867 nancy@eng.example.net 868 eng.example.net!nancy@example.net 869 eng%nancy@example.net 870 @privatecorp.example.net 871 \(user\)@example.net 873 An additional valid NAI is the following, given as a hex string, as 874 this document can only contain ASCII characters. 876 626f 6240 ceb4 cebf ceba ceb9 cebc ceae 2e63 6f6d 878 Examples of invalid Network Access Identifiers include the following: 880 fred@example 881 fred@example_9.com 882 fred@example.net@example.net 883 fred.@example.net 884 eng:nancy@example.net 885 eng;nancy@example.net 886 (user)@example.net 887 @example.net 889 One example given in [RFC4282] is still permitted by the ABNF, but it 890 is NOT RECOMMMENDED because of the use of the ToAscii function to 891 create an ASCII encoding from what is now a valid UTF-8 string. 893 alice@xn--tmonesimerkki-bfbb.example.net 895 4. Security Considerations 897 Since an NAI reveals the home affiliation of a user, it may assist an 898 attacker in further probing the username space. Typically, this 899 problem is of most concern in protocols that transmit the username in 900 clear-text across the Internet, such as in RADIUS, described in 901 [RFC2865] and [RFC2866]. In order to prevent snooping of the 902 username, protocols may use confidentiality services provided by 903 protocols transporting them, such as RADIUS protected by IPsec 904 [RFC3579] or Diameter protected by TLS [RFC6733]. 906 This specification adds the possibility of hiding the username part 907 in the NAI, by omitting it. As discussed in Section 2.4, this is 908 possible only when NAIs are used together with a separate 909 authentication method that can transfer the username in a secure 910 manner. In some cases, application-specific privacy mechanism have 911 also been used with NAIs. For instance, some EAP methods apply 912 method-specific pseudonyms in the username part of the NAI [RFC3748]. 913 While neither of these approaches can protect the realm part, their 914 advantage over transport protection is that privacy of the username 915 is protected, even through intermediate nodes such as NASes. 917 5. Administration of Names 919 In order to avoid creating any new administrative procedures, 920 administration of the NAI realm namespace piggybacks on the 921 administration of the DNS namespace. 923 NAI realm names are required to be unique, and the rights to use a 924 given NAI realm for roaming purposes are obtained coincident with 925 acquiring the rights to use a particular Fully Qualified Domain Name 926 (FQDN). Those wishing to use an NAI realm name should first acquire 927 the rights to use the corresponding FQDN. Administrators MUST NOT 928 publicly use an NAI realm without first owning the corresponding 929 FQDN. Private use of unowned NAI realms within an administative 930 domain is allowed, though it is RECOMMENDED that example names be 931 used, such as "example.com". 933 Note that the use of an FQDN as the realm name does not require use 934 of the DNS for location of the authentication server. While Diameter 935 [RFC6733] supports the use of DNS for location of authentication 936 servers, existing RADIUS implementations typically use proxy 937 configuration files in order to locate authentication servers within 938 a domain and perform authentication routing. The implementations 939 described in [RFC2194] did not use DNS for location of the 940 authentication server within a domain. Similarly, existing 941 implementations have not found a need for dynamic routing protocols 942 or propagation of global routing information. Note also that there 943 is no requirement that the NAI represent a valid email address. 945 6. IANA Considerations 947 This document has no actions for IANA. 949 7. References 951 7.1. Normative References 953 [RFC2119] 954 Bradner, S., "Key words for use in RFCs to Indicate Requirement 955 Levels", RFC 2119, March, 1997. 957 [RFC3629] 958 Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, 959 RFC 3629, November 2003. 961 [RFC5198] 962 Klensin J., and Padlipsky M., "Unicode Format for Network 963 Interchange", RFC 5198, March 2008 965 [RFC5234] 966 Crocker, D. and P. Overell, "Augmented BNF for Syntax 967 Specifications: ABNF", RFC 5234, January 2008. 969 [RFC5890] 970 Faltstrom, P., Hoffman, P., and A. Costello, "Internationalizing 971 Domain Names in Applications (IDNA)", RFC 5890, August 2010 973 [RFC6365] 974 Hoffman, P., and Klensin, J., "Terminology Used in 975 Internationalization in the IETF", RFC 6365, September 2011 977 7.2. Informative References 979 [RFC2194] 980 Aboba, B., Lu, J., Alsop, J., Ding, J., and W. Wang, "Review of 981 Roaming Implementations", RFC 2194, September 1997. 983 [RFC2341] 984 Valencia, A., Littlewood, M., and T. Kolar, "Cisco Layer Two 985 Forwarding (Protocol) "L2F"", RFC 2341, May 1998. 987 [RFC2637] 988 Hamzeh, K., Pall, G., Verthein, W., Taarud, J., Little, W., and G. 989 Zorn, "Point-to-Point Tunneling Protocol", RFC 2637, July 1999. 991 [RFC2661] 992 Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G., and B. 993 Palter, "Layer Two Tunneling Protocol "L2TP"", RFC 2661, August 994 1999. 996 [RFC2865] 997 Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote 998 Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. 1000 [RFC2866] 1001 Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. 1003 [RFC3579] 1004 Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial In 1005 User Service) Support For Extensible Authentication Protocol 1006 (EAP)", RFC 3579, September 2003. 1008 [RFC3748] 1009 Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 1010 Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, 1011 June 2004. 1013 [RFC4282] 1014 Aboba, B. et al., "The Network Access Identifier", RFC 4282, 1015 December 2005. 1017 [RFC4301] 1018 Kent, S. and S. Keo, "Security Architecture for the Internet 1019 Protocol", RFC 4301, December 2005. 1021 [RFC5335] 1022 Y. Abel, Ed., "Internationalized Email Headers", RFC 5335, 1023 September 2008. 1025 [EDUROAM] 1026 http://eduroam.org, "eduroam (EDUcational ROAMing)" 1028 [RFC5891] 1029 Klensin, J., "Internationalized Domain Names in Applications 1030 (IDNA): Protocol", RFC 5891 1032 [RFC6055] 1033 Thaler, D., et al, "IAB Thoughts on Encodings for Internationalized 1034 Domain Names", RFC 6055, February 2011. 1036 [RFC6733] 1037 V. Fajardo, Ed., et al, "Diameter Base Protocol", RFC 6733, October 1038 2012. 1040 [RFC6912] 1041 Sullivan, A., et al, "Principles for Unicode Code Point Inclusion 1042 in Labels in the DNS", RFC 6912, April 2013. 1044 [3GPP] 1045 3GPP, "TS 23.003 Numbering, addressing, and Identification (Release 1046 12)", July 2014, 1047 ftp://ftp.3gpp.org/Specs/archive/23_series/23.003/. 1049 Acknowledgments 1051 The initial text for this document was [RFC4282], which was then 1052 heavily edited. The original authors of [RFC4282] were Bernard 1053 Aboba, Mark A. Beadles, Jari Arkko, and Pasi Eronen. 1055 The ABNF validator at http://www.apps.ietf.org/abnf.html was used to 1056 verify the syntactic correctness of the ABNF in Section 2. 1058 Appendix A - Changes from RFC4282 1060 This document contains the following updates with respect to the 1061 previous NAI definition in RFC 4282 [RFC4282]: 1063 * The formal syntax in Section 2.1 has been updated to forbid 1064 non-UTF8 characters. e.g. characters with the "high bit" set. 1066 * The formal syntax in Section 2.1 has been updated to allow 1067 UTF-8 in the "realm" portion of the NAI. 1069 * The formal syntax in [RFC4282] Section 2.1 applied to the 1070 NAI after it was "internationalized" via the ToAscii function. 1071 The contents of the NAI before it was "internationalized" were 1072 left indeterminate. This document updates the formal syntax to 1073 define an internationalized form of the NAI, and forbids the use 1074 of the ToAscii function for NAI "internationalization". 1076 * The grammar for the user and realm portion is based on a 1077 combination 1078 of the "nai" defined in [RFC4282] Section 2.1, and the "utf8-addr- 1079 spec" defined in [RFC5335] Section 4.4. 1081 * All use of the ToAscii function has been moved to normal 1082 requirements on DNS implementations when realms are used as the 1083 basis for DNS lookups. This involves no changes to the existing 1084 DNS infrastructure. 1086 * The discussions on internationalized character sets in Section 2.4 1087 have been updated. The suggestion to use the ToAscii function for 1088 realm comparisons has been removed. No AAA system has implemented 1089 these suggestions, so this change should have no operational 1090 impact. 1092 * The section "Routing inside of AAA Systems" section is new in this 1093 document. The concept of a "local AAA routing table" is also new, 1094 although it accurately describes the functionality of wide-spread 1095 implementations. 1097 * The "Compatibility with EMail Usernames" and "Compatibility 1098 with DNS" sections have been revised and updated. We now note 1099 that the ToAscii function is suggested to be used only when a 1100 realm name is used for DNS lookups, and even then the function is 1101 only used by a resolving API on the local system, and even then we 1102 recommend that only the home network perform this conversion. 1104 * The "Realm Construction" section has been updated to note 1105 that editing of the NAI is NOT RECOMMENDED. 1107 * The "Examples" section has been updated to remove the instance 1108 of the IDN being converted to ASCII. This behavior is now 1109 forbidden. 1111 Authors' Addresses 1113 Alan DeKok 1114 The FreeRADIUS Server Project 1116 Email: aland@freeradius.org