idnits 2.17.1 draft-ietf-radext-nai-04.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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC4282]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (17 October 2013) is 3843 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 3588 (Obsoleted by RFC 6733) -- Obsolete informational reference (is this intentional?): RFC 4282 (Obsoleted by RFC 7542) -- Obsolete informational reference (is this intentional?): RFC 5335 (Obsoleted by RFC 6532) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group DeKok, Alan 3 INTERNET-DRAFT FreeRADIUS 4 Obsoletes: 4282 5 Category: Standards Track 6 7 17 October 2013 9 The Network Access Identifier 10 draft-ietf-radext-nai-04 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 others users. This document defines the syntax for the 17 Network Access Identifier (NAI), the user identity submitted by the 18 client prior to accessing network resources. This document is a 19 revised version of RFC 4282 [RFC4282], which addresses issues with 20 international character sets, as well as a number of other 21 corrections to the 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 16, 2014. 46 Copyright Notice 48 Copyright (c) 2013 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 3. ........................................................... 3 76 Appendix A - Changes from RFC4282 ............................ 3 77 1. Introduction ............................................. 4 78 1.1. Terminology ......................................... 5 79 1.2. Requirements Language ............................... 6 80 1.3. Purpose ............................................. 7 81 1.4. Motivation .......................................... 7 82 2. NAI Definition ........................................... 8 83 2.1. UTF-8 Syntax and Normalization ...................... 8 84 2.2. Formal Syntax ....................................... 9 85 2.3. NAI Length Considerations ........................... 10 86 2.4. Support for Username Privacy ........................ 11 87 2.5. International Character Sets ........................ 11 88 2.6. The Normalization Process ........................... 12 89 2.6.1. Issues with the Normalization Process .......... 13 90 2.7. Use in Other Protocols .............................. 14 91 3. ........................................................... 14 92 3.1. Compatibility with Email Usernames .................. 16 93 3.2. Compatibility with DNS .............................. 16 94 3.3. Realm Construction .................................. 17 95 3.3.1. Historical Practices ........................... 17 96 3.4. Examples ............................................ 18 97 4. Security Considerations .................................. 19 98 5. IANA Considerations ...................................... 19 99 6. References ............................................... 20 100 6.1. Normative References ................................ 20 101 6.2. Informative References .............................. 20 102 Appendix A - Changes from RFC4282 ............................ 23 103 1. Introduction 105 Considerable interest exists for a set of features that fit within 106 the general category of inter-domain authentiction, or "roaming 107 capability" for network access, including dialup Internet users, 108 Virtual Private Network (VPN) usage, wireless LAN authentication, and 109 other applications. Interested parties have included the following: 111 * Regional Internet Service Providers (ISPs) operating within a 112 particular state or province, looking to combine their efforts 113 with those of other regional providers to offer dialup service 114 over a wider area. 116 * National ISPs wishing to combine their operations with those of 117 one or more ISPs in another nation to offer more comprehensive 118 dialup service in a group of countries or on a continent. 120 * Wireless LAN hotspots providing service to one or more ISPs. 122 * Businesses desiring to offer their employees a comprehensive 123 package of dialup services on a global basis. Those services may 124 include Internet access as well as secure access to corporate 125 intranets via a VPN, enabled by tunneling protocols such as the 126 Point-to-Point Tunneling Protocol (PPTP) [RFC2637], the Layer 2 127 Forwarding (L2F) protocol [RFC2341], the Layer 2 Tunneling 128 Protocol (L2TP) [RFC2661], and the IPsec tunnel mode [RFC4301]. 130 * Other protocols which are interested in leveraging the users 131 credentials in order to take advantage of an existing 132 authentication framework. 134 In order to enhance the interoperability of these services, it is 135 necessary to have a standardized method for identifying users. This 136 document defines syntax for the Network Access Identifier (NAI). 137 Examples of implementations that use the NAI, and descriptions of its 138 semantics, can be found in [RFC2194]. 140 When the NAI was defined for network access, it had the side effect 141 of defining an identifier which could be used in non-AAA systems. 142 Some systems defined identifiers which were compatible with the NAI, 143 and deployments used the NAI. This process simplified the management 144 of credentials, by re-using the same credential in multiple 145 situations. We suggest that this re-use is good practice. The 146 alternative is to have protocol-specific identifiers, which increases 147 cost to both user and administrator. 149 The goal of this document is to define the format of an identifier 150 which can be used in many protocols. A protocol may transport an 151 encoded version of the NAI (e.g. '.' as %2E). However, the 152 definition of the NAI is protocol independent. We hope to encourage 153 the wide-spread adoption of the NAI as an identifier. This adoption 154 will decrease work required to leverage identification and 155 authentication in other protocols. It will also decrease the 156 complexity of systems for end users and administrators. 158 We note that this document only suggest that the NAI be used, but 159 does not require it. Many protocols already define their own 160 identifier formats. Some of these are incompatible with the NAI, 161 while others allow the NAI in addition to non-NAI identifiers. This 162 definition of the NAI has no requirements on protocol specifications, 163 implementations, or deployments. We suggest that using a standard 164 identifier format is preferable to using multiple incompatible 165 identifier formats. 167 This document is a revised version of [RFC4282], which originally 168 defined internationalized NAIs. Differences and enhancements 169 compared to that document are listed in Appendix A. 171 1.1. Terminology 173 This document frequently uses the following terms: 175 "Local" or "localized" text 177 Text which is either in non-UTF-8, or in non-normalized form. The 178 character set, encoding, and locale are (in general) unknown to 179 Authentication, Authorization, and Accounting (AAA) network 180 protocols. The client which "knows" the locale may have a 181 different concept of this text than other AAA entities, which do 182 not know the same locale. 184 Network Access Identifier 186 The Network Access Identifier (NAI) is the user identity submitted 187 by the client during network access authentication. The purpose 188 of the NAI is to identify the user as well as to assist in the 189 routing of the authentication request. Please note that the NAI 190 may not necessarily be the same as the user's email address or the 191 user identity submitted in an application layer authentication. 193 Network Access Server 195 The Network Access Server (NAS) is the device that clients connect 196 to in order to get access to the network. In PPTP terminology, 197 this is referred to as the PPTP Access Concentrator (PAC), and in 198 L2TP terminology, it is referred to as the L2TP Access 199 Concentrator (LAC). In IEEE 802.11, it is referred to as an 200 Access Point. 202 Roaming Capability 204 Roaming capability can be loosely defined as the ability to use 205 any one of multiple Internet Service Providers (ISPs), while 206 maintaining a formal, customer-vendor relationship with only one. 207 Examples of cases where roaming capability might be required 208 include ISP "confederations" and ISP-provided corporate network 209 access support. 211 Normalization Canonicalization 213 These terms are defined in [RFC6365] Section 4. We incorporate 214 the definitions here by reference. 216 Locale 218 This term is defined in [RFC6365] Section 8. We incorporate the 219 definition here by reference. 221 Tunneling Service 223 A tunneling service is any network service enabled by tunneling 224 protocols such as PPTP, L2F, L2TP, and IPsec tunnel mode. One 225 example of a tunneling service is secure access to corporate 226 intranets via a Virtual Private Network (VPN). 228 1.2. Requirements Language 230 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 231 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 232 document are to be interpreted as described in [RFC2119]. 234 1.3. Purpose 236 As described in [RFC2194], there are a number of providers offering 237 network access services, and the number of Internet Service Providers 238 involved in roaming consortia is increasing rapidly. 240 In order to be able to offer roaming capability, one of the 241 requirements is to be able to identify the user's home authentication 242 server. For use in roaming, this function is accomplished via the 243 Network Access Identifier (NAI) submitted by the user to the NAS in 244 the initial network authentication. It is also expected that NASes 245 will use the NAI as part of the process of opening a new tunnel, in 246 order to determine the tunnel endpoint. 248 We also hope that other protocols can take advantage of the NAI. 249 Many protocols include authentication capabilities, including 250 defining their own identifier formats. These identifiers can then 251 end up being transported in AAA protocols, when those systems want to 252 leverage AAA for user authentication. There is therefore a need for 253 a definition of a user identifier which can be used in multiple 254 protocols. 256 While we define the NAI here, we recognize that existing protocols 257 and deployments do not always use it. AAA systems MUST therefore be 258 able to handle user identifiers which are not in the NAI format. The 259 process by which that is done is outside of the scope of this 260 document. 262 We note that this document does not make any protocol-specific 263 definitions for an identifier format, and it does not make changes to 264 any existing protocol. Instead, it defines a protocol-independent 265 form for the NAI. It is hoped that the NAI is a user identifier 266 which can be used in multiple protocols. 268 Using a common identifier simplifies deployments, as there is no need 269 to maintain multiple identifiers for one user. It simplifies 270 protocols requiring authentication, as they no longer need to specify 271 protocol-specific format for user identifiers. It increases 272 security, as it multiple identifiers allow attackers to make 273 contradictory claims without being detected. 275 In short, having a standard is better than having no standard at all. 277 1.4. Motivation 279 The changes from [RFC4282] are listed in detail in Appendix A. 280 However, some additional discussion is appropriate to motivate those 281 changes. 283 The motivation to revise [RFC4282] began with internationalization 284 concerns raised in the context of [EDUROAM]. Section 2.1 of 285 [RFC4282] defines ABNF for realms which limits the realm grammar to 286 English letters, digits, and the hyphen "-" character. The intent 287 appears to have been to encode, compare, and transport realms with 288 the ToASCII operation defined in [RFC5890]. There are a number of 289 problems with this approach: 291 * The [RFC4282] ABNF is not aligned with internationalization of DNS. 293 * The requirement in Section 2.1 that realms are ASCII conflicts 294 with the Extensible Authentication Protocol (EAP) and RADIUS, 295 which are both 8-bit clean, and which both recommend the use of 296 UTF-8 for identitifiers. 298 * Section 2.4 required mappings that are language-specific, 299 and which are nearly impossible for intermediate nodes to perform 300 correctly without information about that language. 302 * Section 2.4 requires normalization of user names, which 303 may conflict with local system or administrative requirements. 305 * The recommendations in Section 2.4 for treatment of 306 bidirectional characters have proven to be unworkable. 308 * The prohibition against use of unassigned code points in 309 Section 2.4 effectively prohibits support for new scripts. 311 * No Authentication, Authorization, and Accounting (AAA) 312 client, proxy, or server has implemented any of the requirements 313 in [RFC4282] Section 2.4, among other sections. 315 With international roaming growing in popularity, it is important for 316 these issues to be corrected in order to provide robust and inter- 317 operable network services. 319 2. NAI Definition 321 2.1. UTF-8 Syntax and Normalization 323 UTF-8 characters can be defined in terms of octets using the 324 following ABNF [RFC5234], taken from [RFC3629]: 326 UTF8-xtra-char = UTF8-2 / UTF8-3 / UTF8-4 328 UTF8-2 = %xC2-DF UTF8-tail 329 UTF8-3 = %xE0 %xA0-BF UTF8-tail / 330 %xE1-EC 2(UTF8-tail) / 331 %xED %x80-9F UTF8-tail / 332 %xEE-EF 2(UTF8-tail) 334 UTF8-4 = %xF0 %x90-BF 2( UTF8-tail ) / 335 %xF1-F3 3( UTF8-tail ) / 336 %xF4 %x80-8F 2( UTF8-tail ) 338 UTF8-tail = %x80-BF 340 These are normatively defined in [RFC3629], but are repeated in this 341 document for reasons of convenience. 343 See [RFC5198] and section 2.6 of this specification for a discussion 344 of normalization. Strings which are not in Normal Form Composed (NFC) 345 are not valid NAIs and SHOULD NOT be treated as such. 346 Implementations which expect to receive a NAI, but get non-normalised 347 (but otherwise valid) UTF-8 strings instead SHOULD attempt to create 348 a local version of the NAI, which is normalized from the input 349 identifier. This local version can then be used for local 350 processing. 352 Systems MAY accept user identifiers in forms other than the NAI. 353 This specification does not forbid that practice. It only codifies 354 the format and interpretation of the NAI. We cannot expect to change 355 existing protocols or practices. We can, however, suggest that using 356 a consistent form for a user identifier is of a benefit to the 357 community. 359 Where protocols carry identifiers which are expected to be 360 transported over an AAA protocol, it is RECOMMENDED that the 361 identifiers be in NAI format. Where the identifiers are not in the 362 NAI format, it is up to the AAA systems to discover this, and to 363 process them. This document does not suggest how that is done. 364 However, existing practice indicates that it is possible. 366 We expect that with wider use of internationalized domain names, 367 existing practices will be inadequate. We therefore define the NAI, 368 which is a user identifier that can correctly deal with 369 internationalized identifiers. 371 2.2. Formal Syntax 373 The grammar for the NAI is given below, described in Augmented 374 Backus-Naur Form (ABNF) as documented in [RFC5234]. 376 nai = utf8-username 377 nai =/ "@" utf8-realm 378 nai =/ utf8-username "@" utf8-realm 380 utf8-username = dot-string 381 dot-string = string 382 dot-string =/ dot-string "." string 383 string = utf8-atext 384 string =/ string utf8-atext 386 utf8-atext = ALPHA / DIGIT / 387 "!" / "#" / 388 "$" / "%" / 389 "&" / "'" / 390 "*" / "+" / 391 "-" / "/" / 392 "=" / "?" / 393 "^" / "_" / 394 "`" / "{" / 395 "|" / "}" / 396 "~" / 397 UTF8-xtra-char 399 utf8-realm = 1*( label "." ) label 401 label = utf8-rtext *(ldh-str) 402 ldh-str = *( utf8-rtext / "-" ) utf8-rtext 403 utf8-rtext = ALPHA / DIGIT / UTF8-xtra-char 405 2.3. NAI Length Considerations 407 Devices handling NAIs MUST support an NAI length of at least 72 408 octets. Devices SHOULD support an NAI length of 253 octets. 409 However, the following implementation issues should be considered: 411 * NAI octet length constraints may impose a more severe constraint 412 on the number of UTF-8 characters. 414 * NAIs are often transported in the User-Name attribute of the 415 Remote Authentication Dial-In User Service (RADIUS) protocol. 416 Unfortunately, RFC 2865 [RFC2865], Section 5.1, states that "the 417 ability to handle at least 63 octets is recommended." As a 418 result, it may not be possible to transfer NAIs beyond 63 octets 419 through all devices. In addition, since only a single User-Name 420 attribute may be included in a RADIUS message and the maximum 421 attribute length is 253 octets; RADIUS is unable to support NAI 422 lengths beyond 253 octets. 424 * NAIs can also be transported in the User-Name attribute of 425 Diameter [RFC3588], which supports content lengths up to 2^24 - 9 426 octets. As a result, NAIs processed only by Diameter nodes can be 427 very long. However, an NAI transported over Diameter may 428 eventually be translated to RADIUS, in which case the above 429 limitations will apply. 431 * NAIs may be transported in other protocols. Each protocol 432 can have its own limitations on maximum NAI length. 433 The above criteria should permit the widest use, and widest possible 434 inter-operability of the NAI. 436 2.4. Support for Username Privacy 438 Interpretation of the username part of the NAI depends on the realm 439 in question. Therefore, the utf8-username portion SHOULD be treated 440 as opaque data when processed by nodes that are not a part of the 441 authoritative domain (in the sense of Section 4) for that realm. 443 In some situations, NAIs are used together with a separate 444 authentication method that can transfer the username part in a more 445 secure manner to increase privacy. In this case, NAIs MAY be 446 provided in an abbreviated form by omitting the username part. 447 Omitting the username part is RECOMMENDED over using a fixed username 448 part, such as "anonymous", since it provides an unambiguous way to 449 determine whether the username is intended to uniquely identify a 450 single user. However, current practice is to use the username 451 "anonymous" instead of omitting the username part. This behavior is 452 also permitted. 454 For roaming purposes, it is typically necessary to locate the 455 appropriate backend authentication server for the given NAI before 456 the authentication conversation can proceed. As a result, the realm 457 portion is typically required in order for the authentication 458 exchange to be routed to the appropriate server. 460 2.5. International Character Sets 462 This specification allows both international usernames and realms. 463 International usernames are based on the use of Unicode characters, 464 encoded as UTF-8. Internationalization of the realm portion of the 465 NAI is based on "Internationalized Email Headers" [RFC5335]. 467 In order to ensure a canonical representation, characters of the 468 username portion in an NAI MUST match the ABNF in this specification 469 as well as the requirements specified in [RFC5891]. In practice, 470 these requirements consist of the following item: 472 * Realms MUST be of the form that can be registered as a 473 Fully Qualified Domain Name (FQDN) within the DNS. 475 This list is significantly shorter and simpler than the list in 476 Section 2.4 of [RFC4282]. The form suggested in [RFC4282] depended 477 on intermediate nodes performing canonicalizations based on 478 insufficient information, which meant that the form was not 479 canonical. 481 Specifying the realm requirement as above means that the requirements 482 depend on specifications that are referenced here, rather than copied 483 here. This allows the realm definition to be updated when the 484 referenced documents change, without requiring a revision of this 485 specification. 487 One caveat on the above recommendation is the issues noted in 488 [CODEPOINTS]. That document notes that there are additional 489 restrictions around DNS registration which forbid some code points 490 from being valid in a DNS U-label. These restrictions cannot be 491 expressed algorithmically. 493 For this specification, that caveat means the following. Realms not 494 matching the above ABNF are not valid NAIs. However, some realms 495 which do match the ABNF are still invalid NAIs. That is, matching 496 the ABNF is a necessary, but not sufficient, requirement for an NAI. 498 In general, the above requirement means following the requirements 499 specified in [RFC5891]. 501 2.6. The Normalization Process 503 Conversion to Unicode as well as normalization is expected to be 504 performed by end systems that take "local" text as input. Other AAA 505 systems such as proxies do not have access to locale and character 506 set information that is available to end systems. Therefore, they 507 are typically incapable of converting local input to Unicode. 509 That is, all processing of NAIs from "local" character sets and 510 locales to UTF-8 SHOULD BE performed by edge systems, prior to the 511 NAIs entering the AAA system. Inside of an AAA system, NAIs are sent 512 over the wire in their canonical form, and this canonical form is 513 used for all NAI and/or realm comparisons. 515 Copying of localized text into fields that can subsequently be placed 516 into the RADIUS User-Name attribute is problematic. This practice 517 can result in a AAA proxy encountering non-UTF8 characters within 518 what it expects to be an NAI. An example of this requirement is 519 [RFC3579] Section 2.1, which states: 521 the NAS MUST copy the contents of the Type-Data field of the 522 EAP-Response/Identity received from the peer into the User-Name 523 attribute 525 As a result, AAA proxies expect the contents of the EAP- 526 Response/Identity sent by an EAP supplicant to consist of UTF-8 527 characters, not localized text. Using localized text in AAA username 528 or identity fields means that realm routing becomes difficult or 529 impossible. 531 In contrast to [RFC4282] Section 2.4, we expect AAA systems to 532 perform NAI comparisons, matching, and AAA routing based on the NAI 533 as it is received. This specification provides a canonical 534 representation, ensures that intermediate systems such as AAA proxies 535 do not need to perform translations, and can be expected to work 536 through systems that are unaware of international character sets. 538 In short, 540 * End systems using "localized" text SHOULD normalize the NAI 541 prior to it being used as an identifier in an authentication 542 protocol. 544 * AAA systems SHOULD NOT normalize the NAI, as they may not have 545 sufficient information to perform the normalization. 547 For example, much of the common realm routing can be done on the 548 "utf8-realm" portion of NAI, through simple checks for equality. 549 This routing can be done even if the AAA proxy is unaware of 550 internalized domain names. All that is required is for the AAA proxy 551 to be able to enter, store, and compare 8-bit data. 553 2.6.1. Issues with the Normalization Process 555 We recognize that the requirements in the preceding section are not 556 implemented today. For example, most EAP implementations use a user 557 identifier which is passed to them from some other local system. 558 This identifier is treated as an opaque blob, and is placed as-is 559 into the EAP Identity field. Any subsequent system which receives 560 that identifier is assumed to be able to understand and process it. 562 This opaque blob unfortunately contains localized text, which means 563 that the AAA systems have to process that text. 565 These limitations have the following theoretical and practical 566 implications. 568 * "local" systems used today generally do not normalize the NAI 569 * Therefore AAA systems SHOUD attempt to normalize the NAI 571 Where the user identifier can be normalized, or determined to be in 572 normal form, the normal form MUST be used as the NAI. In all other 573 circumstances, the user identifier MUST NOT be treated as an NAI. 574 That data is still, however, a user identifier. AAA systems MUST NOT 575 fail authentication simply because the user identifier is not an NAI. 577 2.7. Use in Other Protocols 579 As noted earlier, the NAI MAY be used in other, non-AAA protocols. 580 It is RECOMMENDED that the definition given here be used unchanged. 581 Using other definitions for user identifiers may hinder 582 interoperability, along with the users ability to authenticate 583 successfully. It is RECOMMENDED that protocols requiring the use of 584 a user identifier reference this specification, and suggest that the 585 use of an NAI is RECOMMENDED. 587 We cannot require other protocols to use the NAI for user 588 identifiers. Their needs are unknown, and unknowable. We simply 589 suggest that interoperability and inter-domain authentication is 590 useful, and should be encouraged. 592 Where a protocol is 8-bit clean, it can likely transport the NAI as- 593 is, without further modification. 595 Where a protocol is not 8-bit clean, it cannot transport the NAI as- 596 is. Instead, we presume that a protocol-specific transport layer 597 takes care of encoding the NAI on input to the protocol, and decoding 598 it when the NAI exits the protocol. The encoded or escaped version 599 of the NAI is not a valid NAI, and MUST NOT be presented to the AAA 600 system. 602 For example, HTTP carries user identifiers, but escapes the '.' 603 character as "%2E" (among others). When we desire HTTP to transport 604 the NAI "fred@example.com", the data as transported will be in the 605 form "fred@example%2Ecom". That data exists only within HTTP, and 606 has no relevance to any AAA system. 608 Any comparison, validation, or use of the NAI MUST be done on its un- 609 escaped (i.e. utf8-clean) form. 611 3. 613 Many AAA systems use the "utf8-realm" portion of the NAI to route 614 requests within a AAA proxy network. The semantics of this operation 615 involves a logical AAA routing table, where the "utf8-realm" portion 616 acts as a key, and the values stored in the table are one or more 617 "next hop" AAA servers. 619 Intermediate nodes MUST use the "utf8-realm" portion of the NAI 620 without modification to perform this lookup. As noted earlier, 621 intermediate nodes may not have access to the same locale information 622 as the system which injected the NAI into the AAA routing systems. 623 Therefore, almost all "case insensitive" comparisons will be wrong. 624 Where the "utf8-realm" is entirely ASCII, current systems sometimes 625 perform case-insensitive matching on realms. This practice MAY be 626 continued, as it has been shown to work in practice. 628 We also note that many existing systems have user identifiers which 629 are similar in format to the NAI, but which are not compliant with 630 this specification. For example, they may use non-NFC form, or they 631 may have multiple "@" characters in the user identifier. 632 Intermediate nodes SHOULD normalize non-NFC identifiers to NFC, prior 633 to looking up the "utf8-realm" in the logical routing table. 634 Intermediate nodes MUST NOT modify the identifiers that they forward. 635 The data as entered by the user is inviolate. 637 The "utf8-realm" provisioned in the logical AAA routing table SHOULD 638 be provisioned to the proxy prior to it receiving any AAA traffic. 639 The "utf8-realm" SHOULD be supplied by the "next hop" or "home" 640 system that also supplies the routing information necessary for 641 packets to reach the next hop. 643 This "next hop" information may be any of, or all of, the following 644 information: IP address; port; RADIUS shared secret; TLS certificate; 645 DNS host name; or instruction to use dyanmic DNS discovery (i.e. look 646 up a record in the "utf8-realm" domain). This list is not 647 exhaustive, and my be extended by future specifications. 649 It is RECOMMENDED to use the entirety of the "utf8-realm" for the 650 routing decisions. However, systems MAY use a portion of the 651 "utf8-realm" portion, so long as that portion is a valid 652 "utf8-realm", and that portion is handled as above. For example, 653 routing "fred@example.com" to a "com" destination is forbidden, 654 because "com" is not a valid "utf8-realm". However, routing 655 "fred@sales.example.com" to the "example.com" destination is 656 permissible. 658 Another reason to forbid the use of a single label (e.g. 659 "fred@sales") is that many systems treat a single label as being a 660 local identifier within their realm. That is, a user logging in as 661 "fred@sales" to a domain "example.com", would be treated as if the 662 NAI was instead "fred@sales.example.com". Permitting the use of a 663 single label would mean changing the interpretation and meaning of a 664 single label, which cannot be done. 666 3.1. Compatibility with Email Usernames 668 As proposed in this document, the Network Access Identifier is of the 669 form "user@realm". Please note that while the user portion of the 670 NAI is based on the BNF described in [RFC5198], it has been modified 671 for the purposes of Section 2.2. It does not permit quoted text 672 along with "folding" or "non-folding" whitespace that is commonly 673 used in email addresses. As such, the NAI is not necessarily 674 equivalent to usernames used in e-mail. 676 However, it is a common practice to use email addresses as user 677 identifiers in AAA systems. The ABNF in Section 2.2 is defined to be 678 close to the "utf8-addr-spec" portion of [RFC5335], while still being 679 compatible with [RFC4282]. 681 In contrast to [RFC4282] Section 2.5, we state that the 682 internationalization requirements for NAIs and email addresses are 683 substantially similar. The NAI and email identifiers may be the 684 same, and both need to be entered by the user and/or the operator 685 supplying network access to that user. There is therefore good 686 reason for the internationalization requirements to be similar. 688 3.2. Compatibility with DNS 690 The "utf8-realm" portion of the NAI is intended to be compatible with 691 Internationalized Domain Names (IDNs) [RFC5890]. As defined above, 692 the "utf8-realm" portion as transported within an 8-bit clean 693 protocol such as RADIUS and EAP can contain any valid UTF8 character. 694 There is therefore no reason for a NAS to apply the ToAscii function 695 to the "utf8-realm" portion of an NAI, prior to placing the NAI into 696 a RADIUS User-Name attribute. 698 The NAI does not make a distinction between A-labels and U-labels, as 699 those are terms specific to DNS. It is instead an IDNA-valid label, 700 as per the first item in Section 2.3.2.1 of [RFC5890]. As noted in 701 that section, the term "IDNA-valid label" encompases both of the 702 terms A-label and U-label. 704 When the realm portion of the NAI is used as the basis for name 705 resolution, it may be necessary to convert internationalized realm 706 names to ASCII using the ToASCII operation defined in [RFC5890]. As 707 noted in [RFC6055] Section 2, resolver Application Programming 708 Interfaces (APIs) are not necessarily DNS-specific, so that the 709 ToASCII operation needs to be applied carefully: 711 Applications which convert an IDN to A-label form before calling (for 712 example) getaddrinfo() will result in name resolution failures if the 713 Punycode name is directly used in such protocols. Having libraries 714 or protocols to convert from A-labels to the encoding scheme defined 715 by the protocol (e.g., UTF-8) would require changes to APIs and/or 716 servers, which IDNA was intended to avoid. 718 As a result, applications SHOULD NOT assume that non-ASCII names are 719 resolvable using the public DNS and blindly convert them to A-labels 720 without knowledge of what protocol will be selected by the name 721 resolution library. 723 3.3. Realm Construction 725 The home realm usually appears in the "utf8-realm" portion of the 726 NAI, but in some cases a different realm can be used. This may be 727 useful, for instance, when the home realm is reachable only via 728 intermediate proxies. 730 Such usage may prevent interoperability unless the parties involved 731 have a mutual agreement that the usage is allowed. In particular, 732 NAIs MUST NOT use a different realm than the home realm unless the 733 sender has explicit knowledge that (a) the specified other realm is 734 available and (b) the other realm supports such usage. The sender 735 may determine the fulfillment of these conditions through a database, 736 dynamic discovery, or other means not specified here. Note that the 737 first condition is affected by roaming, as the availability of the 738 other realm may depend on the user's location or the desired 739 application. 741 The use of the home realm MUST be the default unless otherwise 742 configured. 744 3.3.1. Historical Practices 746 Some systems have historically used NAI modifications with multiple 747 "prefix" and "suffix" decorations to perform explicit routing through 748 multiple proxies inside of a AAA network. This practice is NOT 749 RECOMMENDED for the following reasons: 751 * Using explicit routing paths is fragile, and is unresponsive to 752 changes in the network due to servers going up or down, or to 753 changing business relationships. 755 * There is no RADIUS routing protocol, meaning that routing paths 756 have to be communicated "out of band" to all intermediate AAA 757 nodes, and also to all end-user systems (supplicants) expecting to 758 obtain network access. 760 * Using explicit routing paths requires thousands, if not 761 millions of end-user systems to be updated with new path 762 information when a AAA routing path changes. This adds huge 763 expense for updates that would be better done at only a few AAA 764 systems in the network. 766 * Manual updates to RADIUS paths are expensive, time-consuming, 767 and prone to error. 769 * Creating compatible formats for the NAI is difficult 770 when locally-defined "prefixes" and "suffixes" conflict with 771 similar practices elsewhere in the network. These conflicts mean 772 that connecting two networks may be impossible in some cases, as 773 there is no way for packets to be routed properly in a way that 774 meets all requirements at all intermediate proxies. 776 * Leveraging the DNS name system for realm names establishes 777 a globally unique name space for realms. 779 In summary, network practices and capabilities have changed 780 significantly since NAIs were first overloaded to define AAA routes 781 through a network. While explicit path routing was once useful, the 782 time has come for better methods to be used. 784 3.4. Examples 786 Examples of valid Network Access Identifiers include the following: 788 bob 789 joe@example.com 790 fred@foo-9.example.com 791 jack@3rd.depts.example.com 792 fred.smith@example.com 793 fred_smith@example.com 794 fred$@example.com 795 fred=?#$&*+-/^smith@example.com 796 nancy@eng.example.net 797 eng.example.net!nancy@example.net 798 eng%nancy@example.net 799 @privatecorp.example.net 800 \(user\)@example.net 802 An additional valid NAI is the following, given as a hex string, as 803 this document can only contain ASCII characters. 805 626f 6240 ceb4 cebf ceba ceb9 cebc ceae 2e63 6f6d 807 Examples of invalid Network Access Identifiers include the following: 809 fred@example 810 fred@example_9.com 811 fred@example.net@example.net 812 fred.@example.net 813 eng:nancy@example.net 814 eng;nancy@example.net 815 (user)@example.net 816 @example.net 818 One example given in [RFC4282] is still permitted by the ABNF, but it 819 is NOT RECOMMMENDED because of the use of the ToAscii function to 820 create an ASCII encoding from what is now a valid UTF-8 string. 822 alice@xn--tmonesimerkki-bfbb.example.net 824 4. Security Considerations 826 Since an NAI reveals the home affiliation of a user, it may assist an 827 attacker in further probing the username space. Typically, this 828 problem is of most concern in protocols that transmit the username in 829 clear-text across the Internet, such as in RADIUS, described in 830 [RFC2865] and [RFC2866]. In order to prevent snooping of the 831 username, protocols may use confidentiality services provided by 832 protocols transporting them, such as RADIUS protected by IPsec 833 [RFC3579] or Diameter protected by TLS [RFC3588]. 835 This specification adds the possibility of hiding the username part 836 in the NAI, by omitting it. As discussed in Section 2.4, this is 837 possible only when NAIs are used together with a separate 838 authentication method that can transfer the username in a secure 839 manner. In some cases, application-specific privacy mechanism have 840 also been used with NAIs. For instance, some EAP methods apply 841 method-specific pseudonyms in the username part of the NAI [RFC3748]. 842 While neither of these approaches can protect the realm part, their 843 advantage over transport protection is that privacy of the username 844 is protected, even through intermediate nodes such as NASes. 846 5. IANA Considerations 848 In order to avoid creating any new administrative procedures, 849 administration of the NAI realm namespace piggybacks on the 850 administration of the DNS namespace. 852 NAI realm names are required to be unique, and the rights to use a 853 given NAI realm for roaming purposes are obtained coincident with 854 acquiring the rights to use a particular Fully Qualified Domain Name 855 (FQDN). Those wishing to use an NAI realm name should first acquire 856 the rights to use the corresponding FQDN. Using an NAI realm without 857 ownership of the corresponding FQDN creates the possibility of 858 conflict and is therefore discouraged. 860 Note that the use of an FQDN as the realm name does not require use 861 of the DNS for location of the authentication server. While Diameter 862 [RFC3588] supports the use of DNS for location of authentication 863 servers, existing RADIUS implementations typically use proxy 864 configuration files in order to locate authentication servers within 865 a domain and perform authentication routing. The implementations 866 described in [RFC2194] did not use DNS for location of the 867 authentication server within a domain. Similarly, existing 868 implementations have not found a need for dynamic routing protocols 869 or propagation of global routing information. Note also that there 870 is no requirement that the NAI represent a valid email address. 872 6. References 874 6.1. Normative References 876 [RFC2119] 877 Bradner, S., "Key words for use in RFCs to Indicate Requirement 878 Levels", RFC 2119, March, 1997. 880 [RFC3629] 881 Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, 882 RFC 3629, November 2003. 884 [RFC5198] 885 Klensin J., and Padlipsky M., "Unicode Format for Network 886 Interchange", RFC 5198, March 2008 888 [RFC5234] 889 Crocker, D. and P. Overell, "Augmented BNF for Syntax 890 Specifications: ABNF", RFC 5234, January 2008. 892 [RFC5890] 893 Faltstrom, P., Hoffman, P., and A. Costello, "Internationalizing 894 Domain Names in Applications (IDNA)", RFC 5890, August 2010 896 [RFC6365] 897 Hoffman, P., and Klensin, J., "Terminology Used in 898 Internationalization in the IETF", RFC 6365, September 2011 900 6.2. Informative References 902 [RFC2194] 903 Aboba, B., Lu, J., Alsop, J., Ding, J., and W. Wang, "Review of 904 Roaming Implementations", RFC 2194, September 1997. 906 [RFC2341] 907 Valencia, A., Littlewood, M., and T. Kolar, "Cisco Layer Two 908 Forwarding (Protocol) "L2F"", RFC 2341, May 1998. 910 [RFC2637] 911 Hamzeh, K., Pall, G., Verthein, W., Taarud, J., Little, W., and G. 912 Zorn, "Point-to-Point Tunneling Protocol", RFC 2637, July 1999. 914 [RFC2661] 915 Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G., and B. 916 Palter, "Layer Two Tunneling Protocol "L2TP"", RFC 2661, August 917 1999. 919 [RFC2865] 920 Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote 921 Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. 923 [RFC2866] 924 Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. 926 [RFC3579] 927 Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial In 928 User Service) Support For Extensible Authentication Protocol 929 (EAP)", RFC 3579, September 2003. 931 [RFC3588] 932 Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, 933 "Diameter Base Protocol", RFC 3588, September 2003. 935 [RFC3748] 936 Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 937 Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, 938 June 2004. 940 [RFC4282] 941 Aboba, B. et al., "The Network Access Identifier", RFC 4282, 942 December 2005. 944 [RFC4301] 945 Kent, S. and S. Keo, "Security Architecture for the Internet 946 Protocol", RFC 4301, December 2005. 948 [RFC5335] 949 Y. Abel, Ed., "Internationalized Email Headers", RFC 5335, 950 September 2008. 952 [EDUROAM] 953 http://eduroam.org, "eduroam (EDUcational ROAMing)" 955 [RFC5891] 956 Klensin, J., "Internationalized Domain Names in Applications 957 (IDNA): Protocol", RFC 5891 959 [RFC6055] 960 Thaler, D., et al, "IAB Thoughts on Encodings for Internationalized 961 Domain Names", RFC 6055, February 2011. 963 [CODEPOINTS] 964 Sullivan, A., et al, "Principles for Unicode Code Point Inclusion 965 in Labels in the DNS", draft-iab-dns-zone-codepoint-pples, work in 966 progress. 968 Acknowledgments 970 The initial text for this document was [RFC4282], which was then 971 heavily edited. The original authors of [RFC4282] were Bernard 972 Aboba, Mark A. Beadles, Jari Arkko, and Pasi Eronen. 974 The ABNF validator at http://www.apps.ietf.org/abnf.html was used to 975 verify the syntactic correctness of the ABNF in Section 2. 977 Appendix A - Changes from RFC4282 979 This document contains the following updates with respect to the 980 previous NAI definition in RFC 4282 [RFC4282]: 982 * The formal syntax in Section 2.1 has been updated to forbid 983 non-UTF8 characters. e.g. characters with the "high bit" set. 985 * The formal syntax in Section 2.1 has been updated to allow 986 UTF-8 in the "realm" portion of the NAI. 988 * The formal syntax in [RFC4282] Section 2.1 applied to the 989 NAI after it was "internationalized" via the ToAscii function. 990 The contents of the NAI before it was "internationalized" were 991 left indeterminate. This document updates the formal syntax to 992 define an internationalized form of the NAI, and forbids the use 993 of the ToAscii function for NAI "internationalization". 995 * The grammar for the user and realm portion is based on a 996 combination 997 of the "nai" defined in [RFC4282] Section 2.1, and the "utf8-addr- 998 spec" defined in [RFC5335] Section 4.4. 1000 * All use of the ToAscii function has been moved to normal 1001 requirements on DNS implementations when realms are used as the 1002 basis for DNS lookups. This involves no changes to the existing 1003 DNS infrastructure. 1005 * The discussions on internationalized character sets in Section 2.4 1006 have been updated. The suggestion to use the ToAscii function for 1007 realm comparisons has been removed. No AAA system has implemented 1008 these suggestions, so this change should have no operational 1009 impact. 1011 * The section "Routing inside of AAA Systems" section is new in this 1012 document. The concept of a "local AAA routing table" is also new, 1013 although it accurately describes the functionality of wide-spread 1014 implementations. 1016 * The "Compatibility with EMail Usernames" and "Compatibility 1017 with DNS" sections have been revised and updated. We now note 1018 that the ToAscii function is suggested to be used only when a 1019 realm name is used for DNS lookups, and even then the function is 1020 only used by a resolving API on the local system, and even then we 1021 recommend that only the home network perform this conversion. 1023 * The "Realm Construction" section has been updated to note 1024 that editing of the NAI is NOT RECOMMENDED. 1026 * The "Examples" section has been updated to remove the instance 1027 of the IDN being converted to ASCII. This behavior is now 1028 forbidden. 1030 Authors' Addresses 1032 Alan DeKok 1033 The FreeRADIUS Server Project 1035 Email: aland@freeradius.org