idnits 2.17.1 draft-ietf-radext-nai-02.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 (28 January 2013) is 4106 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 28 January 2013 9 The Network Access Identifier 10 draft-ietf-radext-nai-02 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 July 8, 2013. 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 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 .......................................... 7 81 2. NAI Definition ........................................... 8 82 2.1. UTF-8 Syntax and Normalization ...................... 8 83 2.2. Formal Syntax ....................................... 8 84 2.3. NAI Length Considerations ........................... 9 85 2.4. Support for Username Privacy ........................ 10 86 2.5. International Character Sets ........................ 10 87 2.6. The Normalization Process ........................... 11 88 2.7. Use in Other Protocols .............................. 12 89 2.8. Routing inside of AAA Systems ....................... 12 90 2.9. Compatibility with Email Usernames .................. 13 91 2.10. Compatibility with DNS ............................. 14 92 2.11. Realm Construction ................................. 15 93 2.11.1. Historical Practices .......................... 15 94 2.12. Examples ........................................... 16 95 3. Security Considerations .................................. 17 96 4. IANA Considerations ...................................... 17 97 5. References ............................................... 18 98 5.1. Normative References ................................ 18 99 5.2. Informative References .............................. 18 100 Appendix A - Changes from RFC4282 ............................ 21 101 1. Introduction 103 Considerable interest exists for a set of features that fit within 104 the general category of inter-domain authentiction, or "roaming 105 capability" for network access, including dialup Internet users, 106 Virtual Private Network (VPN) usage, wireless LAN authentication, and 107 other applications. Interested parties have included the following: 109 * Regional Internet Service Providers (ISPs) operating within a 110 particular state or province, looking to combine their efforts 111 with those of other regional providers to offer dialup service 112 over a wider area. 114 * National ISPs wishing to combine their operations with those of 115 one or more ISPs in another nation to offer more comprehensive 116 dialup service in a group of countries or on a continent. 118 * Wireless LAN hotspots providing service to one or more ISPs. 120 * Businesses desiring to offer their employees a comprehensive 121 package of dialup services on a global basis. Those services may 122 include Internet access as well as secure access to corporate 123 intranets via a VPN, enabled by tunneling protocols such as the 124 Point-to-Point Tunneling Protocol (PPTP) [RFC2637], the Layer 2 125 Forwarding (L2F) protocol [RFC2341], the Layer 2 Tunneling 126 Protocol (L2TP) [RFC2661], and the IPsec tunnel mode [RFC4301]. 128 * Other protocols which are interested in leveraging the users 129 credentials in order to take advantage of an existing 130 authentication framework. 132 In order to enhance the interoperability of these services, it is 133 necessary to have a standardized method for identifying users. This 134 document defines syntax for the Network Access Identifier (NAI). 135 Examples of implementations that use the NAI, and descriptions of its 136 semantics, can be found in [RFC2194]. 138 The goal of this document is to define the format of an identifier 139 which can be used in many protocols. A protocol may transport an 140 encoded version of the NAI (e.g. '.' as %2E). However, the 141 definition of the NAI is protocol independent. We hope to encourage 142 the wide-spread adoption of the NAI as an identifier. This adoption 143 will decrease work required to leverage identification and 144 authentication in other protocols. It will also decrease the 145 complexity of systems for end users and administrators. 147 This document is a revised version of [RFC4282], which originally 148 defined internationalized NAIs. Differences and enhancements 149 compared to that document are listed in Appendix A. 151 1.1. Terminology 153 This document frequently uses the following terms: 155 "Local" or "localized" text 157 Text which is either in non-UTF-8, or in non-normalized form. The 158 character set, encoding, and locale are (in general) unknown to 159 Authentication, Authorization, and Accounting (AAA) network 160 protocols. The client which "knows" the locale may have a 161 different concept of this text than other AAA entities, which do 162 not know the same locale. 164 Network Access Identifier 166 The Network Access Identifier (NAI) is the user identity submitted 167 by the client during network access authentication. The purpose 168 of the NAI is to identify the user as well as to assist in the 169 routing of the authentication request. Please note that the NAI 170 may not necessarily be the same as the user's email address or the 171 user identity submitted in an application layer authentication. 173 Network Access Server 175 The Network Access Server (NAS) is the device that clients connect 176 to in order to get access to the network. In PPTP terminology, 177 this is referred to as the PPTP Access Concentrator (PAC), and in 178 L2TP terminology, it is referred to as the L2TP Access 179 Concentrator (LAC). In IEEE 802.11, it is referred to as an 180 Access Point. 182 Roaming Capability 184 Roaming capability can be loosely defined as the ability to use 185 any one of multiple Internet Service Providers (ISPs), while 186 maintaining a formal, customer-vendor relationship with only one. 187 Examples of cases where roaming capability might be required 188 include ISP "confederations" and ISP-provided corporate network 189 access support. 191 Tunneling Service 193 A tunneling service is any network service enabled by tunneling 194 protocols such as PPTP, L2F, L2TP, and IPsec tunnel mode. One 195 example of a tunneling service is secure access to corporate 196 intranets via a Virtual Private Network (VPN). 198 1.2. Requirements Language 200 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 201 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 202 document are to be interpreted as described in [RFC2119]. 204 1.3. Purpose 206 As described in [RFC2194], there are a number of providers offering 207 network access services, and the number of Internet Service Providers 208 involved in roaming consortia is increasing rapidly. 210 In order to be able to offer roaming capability, one of the 211 requirements is to be able to identify the user's home authentication 212 server. For use in roaming, this function is accomplished via the 213 Network Access Identifier (NAI) submitted by the user to the NAS in 214 the initial network authentication. It is also expected that NASes 215 will use the NAI as part of the process of opening a new tunnel, in 216 order to determine the tunnel endpoint. 218 We also hope that other protocols can take advantage of the NAI. 219 Many protocols include authentication capabilities. The 220 authentication credentials supplied in those protocols can end up 221 being transported in AAA protocols. It is therefore useful to define 222 a representation of the user credentials which can be shared across 223 multiple protocols. 225 1.4. Motivation 227 The changes from [RFC4282] are listed in detail in Appendix A. 228 However, some additional discussion is appropriate to motivate those 229 changes. 231 The motivation to revise [RFC4282] began with internationalization 232 concerns raised in the context of [EDUROAM]. Section 2.1 of 233 [RFC4282] defines ABNF for realms which limits the realm grammar to 234 English letters, digits, and the hyphen "-" character. The intent 235 appears to have been to encode, compare, and transport realms with 236 the ToASCII operation defined in [RFC5890]. There are a number of 237 problems with this approach: 239 * The [RFC4282] ABNF is not aligned with internationalization of DNS. 241 * The requirement in Section 2.1 that realms are ASCII conflicts 242 with the Extensible Authentication Protocol (EAP) and RADIUS, 243 which are both 8-bit clean, and which both recommend the use of 244 UTF-8 for identities. 246 * Section 2.4 required mappings that are language-specific, 247 and which are nearly impossible for intermediate nodes to perform 248 correctly without information about that language. 250 * Section 2.4 requires normalization of user names, which 251 may conflict with local system or administrative requirements. 253 * The recommendations in Section 2.4 for treatment of 254 bidirectional characters have proven to be unworkable. 256 * The prohibition against use of unassigned code points in 257 Section 2.4 effectively prohibits support for new scripts. 259 * No Authentication, Authorization, and Accounting (AAA) 260 client, proxy, or server has implemented any of the requirements 261 in [RFC4282] Section 2.4, among other sections. 263 With international roaming growing in popularity, it is important for 264 these issues to be corrected in order to provide robust and inter- 265 operable network services. 267 2. NAI Definition 269 2.1. UTF-8 Syntax and Normalization 271 UTF-8 characters can be defined in terms of octets using the 272 following ABNF [RFC5234], taken from [RFC3629]: 274 UTF8-xtra-char = UTF8-2 / UTF8-3 / UTF8-4 276 UTF8-2 = %xC2-DF UTF8-tail 278 UTF8-3 = %xE0 %xA0-BF UTF8-tail / 279 %xE1-EC 2(UTF8-tail) / 280 %xED %x80-9F UTF8-tail / 281 %xEE-EF 2(UTF8-tail) 283 UTF8-4 = %xF0 %x90-BF 2( UTF8-tail ) / 284 %xF1-F3 3( UTF8-tail ) / 285 %xF4 %x80-8F 2( UTF8-tail ) 287 UTF8-tail = %x80-BF 289 These are normatively defined in [RFC3629], but are repeated in this 290 document for reasons of convenience. 292 See [RFC5198] for a discussion of normalization; the use of Normal 293 Form Composed (NFC) is RECOMMENDED. 295 2.2. Formal Syntax 297 The grammar for the NAI is given below, described in Augmented 298 Backus-Naur Form (ABNF) as documented in [RFC5234]. 300 nai = utf8-username 301 nai =/ "@" utf8-realm 302 nai =/ utf8-username "@" utf8-realm 304 utf8-username = dot-string 305 dot-string = string 306 dot-string =/ dot-string "." string 307 string = utf8-atext 308 string =/ string utf8-atext 310 utf8-atext = ALPHA / DIGIT / 311 "!" / "#" / 312 "$" / "%" / 313 "&" / "'" / 314 "*" / "+" / 315 "-" / "/" / 316 "=" / "?" / 317 "^" / "_" / 318 "`" / "{" / 319 "|" / "}" / 320 "~" / 321 UTF8-xtra-char 323 utf8-realm = 1*( label "." ) label 325 label = utf8-rtext *(ldh-str) 326 ldh-str = *( utf8-rtext / "-" ) utf8-rtext 327 utf8-rtext = ALPHA / DIGIT / UTF8-xtra-char 329 2.3. NAI Length Considerations 331 Devices handling NAIs MUST support an NAI length of at least 72 332 octets. Devices SHOULD support an NAI length of 253 octets. 333 However, the following implementation issues should be considered: 335 * NAI octet length constraints may impose a more severe constraint 336 on the number of UTF-8 characters. 338 * NAIs are often transported in the User-Name attribute of the 339 Remote Authentication Dial-In User Service (RADIUS) protocol. 340 Unfortunately, RFC 2865 [RFC2865], Section 5.1, states that "the 341 ability to handle at least 63 octets is recommended." As a 342 result, it may not be possible to transfer NAIs beyond 63 octets 343 through all devices. In addition, since only a single User-Name 344 attribute may be included in a RADIUS message and the maximum 345 attribute length is 253 octets; RADIUS is unable to support NAI 346 lengths beyond 253 octets. 348 * NAIs can also be transported in the User-Name attribute of 349 Diameter [RFC3588], which supports content lengths up to 2^24 - 9 350 octets. As a result, NAIs processed only by Diameter nodes can be 351 very long. However, an NAI transported over Diameter may 352 eventually be translated to RADIUS, in which case the above 353 limitations will apply. 355 * NAIs may be transported in other protocols. Each protocol 356 can have its own limitations on maximum NAI length. 357 The above criteria should permit the widest use, and widest possible 358 inter-operability of the NAI. 360 2.4. Support for Username Privacy 362 Interpretation of the username part of the NAI depends on the realm 363 in question. Therefore, the utf8-username portion SHOULD be treated 364 as opaque data when processed by nodes that are not a part of the 365 authoritative domain (in the sense of Section 4) for that realm. 367 In some situations, NAIs are used together with a separate 368 authentication method that can transfer the username part in a more 369 secure manner to increase privacy. In this case, NAIs MAY be 370 provided in an abbreviated form by omitting the username part. 371 Omitting the username part is RECOMMENDED over using a fixed username 372 part, such as "anonymous", since it provides an unambiguous way to 373 determine whether the username is intended to uniquely identify a 374 single user. However, current practice is to use the username 375 "anonymous" instead of omitting the username part. This behavior is 376 also permitted. 378 For roaming purposes, it is typically necessary to locate the 379 appropriate backend authentication server for the given NAI before 380 the authentication conversation can proceed. As a result, the realm 381 portion is typically required in order for the authentication 382 exchange to be routed to the appropriate server. 384 2.5. International Character Sets 386 This specification allows both international usernames and realms. 387 International usernames are based on the use of Unicode characters, 388 encoded as UTF-8. Internationalization of the realm portion of the 389 NAI is based on "Internationalized Email Headers" [RFC5335]. 391 In order to ensure a canonical representation, characters of the 392 username portion in an NAI MUST match the ABNF in this specification 393 as well as the requirements specified in [RFC5891]. In practice, 394 these requirements consist of the following item: 396 * Realms MUST be of the form that can be registered as a 397 Fully Qualified Domain Name (FQDN) within the DNS. 399 This list is significantly shorter and simpler than the list in 400 Section 2.4 of [RFC4282]. The form suggested in [RFC4282] depended 401 on intermediate nodes performing canonicalizations based on 402 insufficient information, which meant that the form was not 403 canonical. This document instead suggests (Section 2.10) that the 404 realm owner provide a canonical form of the realm, and that all 405 intermediate nodes use that form without modification. 407 Specifying the realm requirement as above means that the requirements 408 depend on specifications that are referenced here, rather than copied 409 here. This allows the realm definition to be updated when the 410 referenced documents change, without requiring a revision of this 411 specification. 413 In general, the above requirement means following the requirements 414 specified in [RFC5891]. 416 2.6. The Normalization Process 418 Conversion to Unicode as well as normalization is expected to be 419 performed by end systems that take "local" text as input. Other AAA 420 systems such as proxies do not have access to locale and character 421 set information that is available to end systems. Therefore, they 422 are typically incapable of converting local input to Unicode. 424 That is, all processing of NAIs from "local" character sets and 425 locales to UTF-8 is performed by edge systems, prior to the NAIs 426 entering the AAA system. Inside of an AAA system, NAIs are sent over 427 the wire in their canonical form, and this canonical form is used for 428 all NAI and/or realm comparisons. 430 Copying of localized text into fields that can subsequently be placed 431 into the RADIUS User-Name attribute is problematic. This practice 432 can result in a AAA proxy encountering non-UTF8 characters within 433 what it expects to be an NAI. An example of this requirement is 434 [RFC3579] Section 2.1, which states: 436 the NAS MUST copy the contents of the Type-Data field of the 437 EAP-Response/Identity received from the peer into the User-Name 438 attribute 440 As a result, AAA proxies expect the contents of the EAP- 441 Response/Identity sent by an EAP supplicant to consist of UTF-8 442 characters, not localized text. Using localized text in AAA username 443 or identity fields means that realm routing becomes difficult or 444 impossible. 446 In contrast to [RFC4282] Section 2.4, we expect AAA systems to 447 perform NAI comparisons, matching, and AAA routing based on the NAI 448 as it is received. This specification provides a canonical 449 representation, ensures that intermediate systems such as AAA proxies 450 do not need to perform translations, and can be expected to work 451 through systems that are unaware of international character sets. 453 For example, much of the common realm routing can be done on the 454 "utf8-realm" portion of NAI, through simple checks for equality. 455 This routing can be done even if the AAA proxy is unaware of 456 internalized domain names. All that is required is for the AAA proxy 457 to be able to enter, store, and compare 8-bit data. 459 2.7. Use in Other Protocols 461 As noted earlier, the NAI MAY be used in other, non-AAA protocols. 462 It is RECOMMENDED that the definition given here be used unchanged. 463 Using other definitions for user identifiers may hinder 464 interoperability, along with the users ability to authenticate 465 successfully. It is RECOMMENDED that protocols requiring the use of 466 a user identifier reference this specification, and suggest that the 467 use of an NAI is RECOMMENDED. 469 We cannot require other protocols to use the NAI for user 470 identifiers. Their needs are unknown, and unknowable. We simply 471 suggest that interoperability and inter-domain authentication is 472 useful, and should be encouraged. 474 Where a protocol is 8-bit clean, it can likely transport the NAI as- 475 is, without further modification. 477 Where a protocol is not 8-bit clean, it MUST NOT affect the 478 definition or handling of the NAI. That is, if a protocol escapes 479 the '.' character as "%2E", then the protocol may have an identifier 480 transported as "fred@example%2Ecom", whereas the NAI for that user is 481 "fred@example.com". Any comparison, validation, or use of the NAI 482 MUST be done on its un-escaped (i.e. utf8-clean) form. 484 2.8. Routing inside of AAA Systems 486 Many AAA systems use the "utf8-realm" portion of the NAI to route 487 requests within a AAA proxy network. The semantics of this operation 488 involves a logical AAA routing table, where the "utf8-realm" portion 489 acts as a key, and the values stored in the table are one or more 490 "next hop" AAA servers. 492 Intermediate nodes MUST use the "utf8-realm" portion of the NAI 493 without modification to perform this lookup. Comparisons between the 494 NAI as given in a AAA packet, and as provisioned in a logical AAA 495 routing table SHOULD be done as a byte-for-byte equality test. As 496 noted earlier, intermediate nodes may not have access to the same 497 locale information as the system which injected the NAI into the AAA 498 routing systems. Therefore, almost all "case insensitive" 499 comparisons will be wrong. Where the "utf8-realm" is entirely ASCII, 500 current systems sometimes perform case-insensitive matching on 501 realms. This practice MAY be continued, as it has been shown to work 502 in practice. 504 The "utf8-realm" provisioned in the logical AAA routing table SHOULD 505 be provisioned to the proxy prior to it receiving any AAA traffic. 506 The "utf8-realm" SHOULD be supplied by the "next hop" system that 507 also supplies the other information, necessary to reach the next hop. 509 This "next hop" information may be any of, or all of, the following 510 information: IP address; port; RADIUS shared secret; TLS certificate; 511 DNS host name; or instruction to use dyanmic DNS discovery (i.e. look 512 up a record in the "utf8-realm" domain). This list is not 513 exhaustive, and my be extended by future specifications. 515 It is RECOMMENDED to use the entirety of the "utf8-realm" for the 516 routing decisions. However, systems MAY use a portion of the 517 "utf8-realm" portion, so long as that portion is a valid 518 "utf8-realm", and that portion is handled as above. For example, 519 routing "fred@example.com" to a "com" destination is forbidden, 520 because "com" is not a valid "utf8-realm". However, routing 521 "fred@sales.example.com" to the "example.com" destination is 522 permissible. 524 Another reason to forbid the use of a single label (e.g. 525 "fred@sales") is that many systems treat a single label as being a 526 local identifier within their realm. That is, a user logging in as 527 "fred@sales" to a domain "example.com", would be treated as if the 528 NAI was instead "fred@sales.example.com". Permitting the use of a 529 single label would mean changing the interpretation and meaning of a 530 single label, which cannot be done. 532 2.9. Compatibility with Email Usernames 534 As proposed in this document, the Network Access Identifier is of the 535 form "user@realm". Please note that while the user portion of the 536 NAI is based on the BNF described in [RFC5198], it has been modified 537 for the purposes of Section 2.2. It does not permit quoted text 538 along with "folding" or "non-folding" whitespace that is commonly 539 used in email addresses. As such, the NAI is not necessarily 540 equivalent to usernames used in e-mail. 542 However, it is a common practice to use email addresses as user 543 identifiers in AAA systems. The ABNF in Section 2.2 is defined to be 544 close to the "utf8-addr-spec" portion of [RFC5335], while still being 545 compatible with [RFC4282]. 547 In contrast to [RFC4282] Section 2.5, we state that the 548 internationalization requirements for NAIs and email addresses are 549 substantially similar. The NAI and email identifiers may be the 550 same, and both need to be entered by the user and/or the operator 551 supplying network access to that user. There is therefore good 552 reason for the internationalization requirements to be similar. 554 2.10. Compatibility with DNS 556 The "utf8-realm" portion of the NAI is intended to be compatible with 557 Internationalized Domain Names (IDNs) [RFC5890]. As defined above, 558 the "utf8-realm" portion as transported within an 8-bit clean 559 protocol such as RADIUS and EAP can contain any valid UTF8 character. 560 There is therefore no reason for a NAS to apply the ToAscii function 561 to the "utf8-realm" portion of an NAI, prior to placing the NAI into 562 a RADIUS User-Name attribute. Unlike DNS, the NAI does not make a 563 distinction between A-labels and U-labels. Is instead an IDNA-valid 564 label, as per Section 2.3.2.1 of [RFC5890]. 566 When the realm portion of the NAI is used as the basis for name 567 resolution, it may be necessary to convert internationalized realm 568 names to ASCII using the ToASCII operation defined in [RFC5890]. As 569 noted in [RFC6055] Section 2, resolver Application Programming 570 Interfaces (APIs) are not necessarily DNS-specific, so that the 571 ToASCII operation needs to be applied carefully: 573 Applications which convert an IDN to A-label form before calling (for 574 example) getaddrinfo() will result in name resolution failures if the 575 Punycode name is directly used in such protocols. Having libraries 576 or protocols to convert from A-labels to the encoding scheme defined 577 by the protocol (e.g., UTF-8) would require changes to APIs and/or 578 servers, which IDNA was intended to avoid. 580 As a result, applications SHOULD NOT assume that non-ASCII names are 581 resolved using the public DNS and blindly convert them to A-labels 582 without knowledge of what protocol will be selected by the name 583 resolution library. 585 There is, however, a problem with this approach. A AAA proxy may not 586 have sufficient information in order to perform the ToAscii 587 conversion properly. We therefore RECOMMEND that only the owner of 588 the realm perform the ToAscii conversion. We RECOMMEND that the 589 owner of the realm pre-provision all proxies with the "utf8-realm" 590 portion of the NAI, along with the value returned from passing the 591 "utf8-realm" to the ToAscii function. This key-value pair can then 592 be placed into the logical AAA routing table discussed above. Having 593 only one entity perform the ToAscii function ensures that the result 594 returned by that function are considered as canonical by all other 595 participants in a AAA network. 597 The paragraph above does not negate all of the benefits of using DNS 598 to automatically discover the location of a "next hop" AAA server. 599 Many AAA proxies require a business or legal relationship prior to 600 routing any traffic. This relationship can be leveraged to bootstrap 601 the DNS information located in the logical AAA routing table. 603 2.11. Realm Construction 605 The home realm usually appears in the "utf8-realm" portion of the 606 NAI, but in some cases a different realm can be used. This may be 607 useful, for instance, when the home realm is reachable only via 608 intermediate proxies. 610 Such usage may prevent interoperability unless the parties involved 611 have a mutual agreement that the usage is allowed. In particular, 612 NAIs MUST NOT use a different realm than the home realm unless the 613 sender has explicit knowledge that (a) the specified other realm is 614 available and (b) the other realm supports such usage. The sender 615 may determine the fulfillment of these conditions through a database, 616 dynamic discovery, or other means not specified here. Note that the 617 first condition is affected by roaming, as the availability of the 618 other realm may depend on the user's location or the desired 619 application. 621 The use of the home realm MUST be the default unless otherwise 622 configured. 624 2.11.1. Historical Practices 626 Some systems have historically used NAI modifications with multiple 627 "prefix" and "suffix" decorations to perform explicit routing through 628 multiple proxies inside of a AAA network. This practice is NOT 629 RECOMMENDED for the following reasons: 631 * Using explicit routing paths is fragile, and is unresponsive to 632 changes in the network due to servers going up or down, or to 633 changing business relationships. 635 * There is no RADIUS routing protocol, meaning that routing paths 636 have to be communicated "out of band" to all intermediate AAA 637 nodes, and also to all end-user systems (supplicants) expecting to 638 obtain network access. 640 * Using explicit routing paths requires thousands, if not 641 millions of end-user systems to be updated with new path 642 information when a AAA routing path changes. This adds huge 643 expense for updates that would be better done at only a few AAA 644 systems in the network. 646 * Manual updates to RADIUS paths are expensive, time-consuming, 647 and prone to error. 649 * Creating compatible formats for the NAI is difficult 650 when locally-defined "prefixes" and "suffixes" conflict with 651 similar practices elsewhere in the network. These conflicts mean 652 that connecting two networks may be impossible in some cases, as 653 there is no way for packets to be routed properly in a way that 654 meets all requirements at all intermediate proxies. 656 * Leveraging the DNS name system for realm names establishes 657 a globally unique name space for realms. 659 In summary, network practices and capabilities have changed 660 significantly since NAIs were first overloaded to define AAA routes 661 through a network. While explicit path routing was once useful, the 662 time has come for better methods to be used. 664 2.12. Examples 666 Examples of valid Network Access Identifiers include the following: 668 bob 669 joe@example.com 670 fred@foo-9.example.com 671 jack@3rd.depts.example.com 672 fred.smith@example.com 673 fred_smith@example.com 674 fred$@example.com 675 fred=?#$&*+-/^smith@example.com 676 nancy@eng.example.net 677 eng.example.net!nancy@example.net 678 eng%nancy@example.net 679 @privatecorp.example.net 680 \(user\)@example.net 682 Examples of invalid Network Access Identifiers include the following: 684 fred@example 685 fred@example_9.com 686 fred@example.net@example.net 687 fred.@example.net 688 eng:nancy@example.net 689 eng;nancy@example.net 690 (user)@example.net 691 @example.net 693 One example given in [RFC4282] is still permitted by the ABNF, but it 694 is NOT RECOMMMENDED because of the use of the ToAscii function to 695 create an ASCII encoding from what is now a valid UTF-8 string. 697 alice@xn--tmonesimerkki-bfbb.example.net 699 3. Security Considerations 701 Since an NAI reveals the home affiliation of a user, it may assist an 702 attacker in further probing the username space. Typically, this 703 problem is of most concern in protocols that transmit the username in 704 clear-text across the Internet, such as in RADIUS, described in 705 [RFC2865] and [RFC2866]. In order to prevent snooping of the 706 username, protocols may use confidentiality services provided by 707 protocols transporting them, such as RADIUS protected by IPsec 708 [RFC3579] or Diameter protected by TLS [RFC3588]. 710 This specification adds the possibility of hiding the username part 711 in the NAI, by omitting it. As discussed in Section 2.4, this is 712 possible only when NAIs are used together with a separate 713 authentication method that can transfer the username in a secure 714 manner. In some cases, application-specific privacy mechanism have 715 also been used with NAIs. For instance, some EAP methods apply 716 method-specific pseudonyms in the username part of the NAI [RFC3748]. 717 While neither of these approaches can protect the realm part, their 718 advantage over transport protection is that privacy of the username 719 is protected, even through intermediate nodes such as NASes. 721 4. IANA Considerations 723 In order to avoid creating any new administrative procedures, 724 administration of the NAI realm namespace piggybacks on the 725 administration of the DNS namespace. 727 NAI realm names are required to be unique, and the rights to use a 728 given NAI realm for roaming purposes are obtained coincident with 729 acquiring the rights to use a particular Fully Qualified Domain Name 730 (FQDN). Those wishing to use an NAI realm name should first acquire 731 the rights to use the corresponding FQDN. Using an NAI realm without 732 ownership of the corresponding FQDN creates the possibility of 733 conflict and is therefore discouraged. 735 Note that the use of an FQDN as the realm name does not require use 736 of the DNS for location of the authentication server. While Diameter 737 [RFC3588] supports the use of DNS for location of authentication 738 servers, existing RADIUS implementations typically use proxy 739 configuration files in order to locate authentication servers within 740 a domain and perform authentication routing. The implementations 741 described in [RFC2194] did not use DNS for location of the 742 authentication server within a domain. Similarly, existing 743 implementations have not found a need for dynamic routing protocols 744 or propagation of global routing information. Note also that there 745 is no requirement that the NAI represent a valid email address. 747 5. References 749 5.1. Normative References 751 [RFC2119] 752 Bradner, S., "Key words for use in RFCs to Indicate Requirement 753 Levels", RFC 2119, March, 1997. 755 [RFC3629] 756 Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, 757 RFC 3629, November 2003. 759 [RFC5198] 760 Klensin J., and Padlipsky M., "Unicode Format for Network 761 Interchange", RFC 5198, March 2008 763 [RFC5234] 764 Crocker, D. and P. Overell, "Augmented BNF for Syntax 765 Specifications: ABNF", RFC 5234, January 2008. 767 [RFC5890] 768 Faltstrom, P., Hoffman, P., and A. Costello, "Internationalizing 769 Domain Names in Applications (IDNA)", RFC 5890 771 5.2. Informative References 773 [RFC2194] 774 Aboba, B., Lu, J., Alsop, J., Ding, J., and W. Wang, "Review of 775 Roaming Implementations", RFC 2194, September 1997. 777 [RFC2341] 778 Valencia, A., Littlewood, M., and T. Kolar, "Cisco Layer Two 779 Forwarding (Protocol) "L2F"", RFC 2341, May 1998. 781 [RFC2637] 782 Hamzeh, K., Pall, G., Verthein, W., Taarud, J., Little, W., and G. 783 Zorn, "Point-to-Point Tunneling Protocol", RFC 2637, July 1999. 785 [RFC2661] 786 Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G., and B. 787 Palter, "Layer Two Tunneling Protocol "L2TP"", RFC 2661, August 788 1999. 790 [RFC2865] 791 Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote 792 Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. 794 [RFC2866] 795 Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. 797 [RFC3579] 798 Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial In 799 User Service) Support For Extensible Authentication Protocol 800 (EAP)", RFC 3579, September 2003. 802 [RFC3588] 803 Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, 804 "Diameter Base Protocol", RFC 3588, September 2003. 806 [RFC3748] 807 Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 808 Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, 809 June 2004. 811 [RFC4282] 812 Aboba, B. et al., "The Network Access Identifier", RFC 4282, 813 December 2005. 815 [RFC4301] 816 Kent, S. and S. Keo, "Security Architecture for the Internet 817 Protocol", RFC 4301, December 2005. 819 [RFC5335] 820 Y. Abel, Ed., "Internationalized Email Headers", RFC 5335, 821 September 2008. 823 [EDUROAM] 824 http://eduroam.org, "eduroam (EDUcational ROAMing)" 826 [RFC5891] 827 Klensin, J., "Internationalized Domain Names in Applications 828 (IDNA): Protocol", RFC 5891 830 [RFC6055] 831 Thaler, D., et al, "IAB Thoughts on Encodings for Internationalized 832 Domain Names", RFC 6055, February 2011. 834 Acknowledgments 836 The initial text for this document was [RFC4282], which was then 837 heavily edited. The original authors of [RFC4282] were Bernard 838 Aboba, Mark A. Beadles, Jari Arkko, and Pasi Eronen. 840 The ABNF validator at http://www.apps.ietf.org/abnf.html was used to 841 verify the syntactic correctness of the ABNF in Section 2. 843 Appendix A - Changes from RFC4282 845 This document contains the following updates with respect to the 846 previous NAI definition in RFC 4282 [RFC4282]: 848 * The formal syntax in Section 2.1 has been updated to forbid 849 non-UTF8 characters. e.g. characters with the "high bit" set. 851 * The formal syntax in Section 2.1 has been updated to allow 852 UTF-8 in the "realm" portion of the NAI. 854 * The formal syntax in [RFC4282] Section 2.1 applied to the 855 NAI after it was "internationalized" via the ToAscii function. 856 The contents of the NAI before it was "internationalized" were 857 left indeterminate. This document updates the formal syntax to 858 define an internationalized form of the NAI, and forbids the use 859 of the ToAscii function for NAI "internationalization". 861 * The grammar for the user and realm portion is based on a 862 combination 863 of the "nai" defined in [RFC4282] Section 2.1, and the "utf8-addr- 864 spec" defined in [RFC5335] Section 4.4. 866 * All use of the ToAscii function has been moved to normal 867 requirements on DNS implementations when realms are used as the 868 basis for DNS lookups. This involves no changes to the existing 869 DNS infrastructure. 871 * The discussions on internationalized character sets in Section 2.4 872 have been updated. The suggestion to use the ToAscii function for 873 realm comparisons has been removed. No AAA system has implemented 874 these suggestions, so this change should have no operational 875 impact. 877 * The section "Routing inside of AAA Systems" section is new in this 878 document. The concept of a "local AAA routing table" is also new, 879 although it accurately describes the functionality of wide-spread 880 implementations. 882 * The "Compatibility with EMail Usernames" and "Compatibility 883 with DNS" sections have been revised and updated. We now note 884 that the ToAscii function is suggested to be used only when a 885 realm name is used for DNS lookups, and even then the function is 886 only used by a resolving API on the local system, and even then we 887 recommend that only the home network perform this conversion. 889 * The "Realm Construction" section has been updated to note 890 that editing of the NAI is NOT RECOMMENDED. 892 * The "Examples" section has been updated to remove the instance 893 of the IDN being converted to ASCII. This behavior is now 894 forbidden. 896 Authors' Addresses 898 Alan DeKok 899 The FreeRADIUS Server Project 901 Email: aland@freeradius.org