idnits 2.17.1 draft-dekok-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 date (28 August 2012) is 4256 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 (~~), 2 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 August 2012 9 The Network Access Identifier 10 draft-dekok-radext-nai-02 12 Abstract 14 In order to provide roaming services, it is necessary to have a 15 standardized method for identifying users. This document defines the 16 syntax for the Network Access Identifier (NAI), the user identity 17 submitted by the client during network authentication. "Roaming" may 18 be loosely defined as the ability to use any one of multiple Internet 19 Service Providers (ISPs), while maintaining a formal, customer-vendor 20 relationship with only one. Examples of where roaming capabilities 21 might be required include ISP "confederations" and ISP-provided 22 corporate network access support. This document is a revised version 23 of RFC 4282 [RFC4282], which addresses issues with international 24 character sets, as well as a number of other corrections to the 25 previous document. 27 Status of this Memo 29 This Internet-Draft is submitted to IETF in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF), its areas, and its working groups. Note that 34 other groups may also distribute working documents as Internet- 35 Drafts. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 The list of current Internet-Drafts can be accessed at 43 http://www.ietf.org/ietf/1id-abstracts.txt. 45 The list of Internet-Draft Shadow Directories can be accessed at 46 http://www.ietf.org/shadow.html. 48 This Internet-Draft will expire on February 28, 2013. 50 Copyright Notice 52 Copyright (c) 2012 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 Appendix A - Changes from RFC4282 ............................ 3 68 1. Introduction ............................................. 4 69 1.1. Terminology ......................................... 4 70 1.2. Requirements Language ............................... 5 71 1.3. Purpose ............................................. 6 72 1.4. Motivation .......................................... 6 73 2. NAI Definition ........................................... 7 74 2.1. UTF-8 Syntax and Normalization ...................... 7 75 2.2. Formal Syntax ....................................... 7 76 2.3. NAI Length Considerations ........................... 8 77 2.4. Support for Username Privacy ........................ 8 78 2.5. International Character Sets ........................ 9 79 2.6. The Normalization Process ........................... 10 80 2.7. Routing inside of AAA Systems ....................... 10 81 2.8. Compatibility with Email Usernames .................. 11 82 2.9. Compatibility with DNS .............................. 11 83 2.10. Realm Construction ................................. 12 84 2.10.1. Historical Practices .......................... 13 85 2.11. Examples ........................................... 13 86 3. Security Considerations .................................. 14 87 4. IANA Considerations ...................................... 15 88 5. References ............................................... 15 89 5.1. Normative References ................................ 15 90 5.2. Informative References .............................. 16 91 Appendix A - Changes from RFC4282 ............................ 18 92 1. Introduction 94 Considerable interest exists for a set of features that fit within 95 the general category of "roaming capability" for network access, 96 including dialup Internet users, Virtual Private Network (VPN) usage, 97 wireless LAN authentication, and other applications. Interested 98 parties have included the following: 100 o Regional Internet Service Providers (ISPs) operating within a 101 particular state or province, looking to combine their efforts 102 with those of other regional providers to offer dialup service 103 over a wider area. 105 o National ISPs wishing to combine their operations with those of 106 one or more ISPs in another nation to offer more comprehensive 107 dialup service in a group of countries or on a continent. 109 o Wireless LAN hotspots providing service to one or more ISPs. 111 o Businesses desiring to offer their employees a comprehensive 112 package of dialup services on a global basis. Those services may 113 include Internet access as well as secure access to corporate 114 intranets via a VPN, enabled by tunneling protocols such as the 115 Point-to-Point Tunneling Protocol (PPTP) [RFC2637], the Layer 2 116 Forwarding (L2F) protocol [RFC2341], the Layer 2 Tunneling 117 Protocol (L2TP) [RFC2661], and the IPsec tunnel mode [RFC4301]. 119 In order to enhance the interoperability of roaming services, it is 120 necessary to have a standardized method for identifying users. This 121 document defines syntax for the Network Access Identifier (NAI). 122 Examples of implementations that use the NAI, and descriptions of its 123 semantics, can be found in [RFC2194]. 125 This document is a revised version of [RFC4282], which originally 126 defined internationalized NAIs. Differences and enhancements 127 compared to that document are listed in Appendix A. 129 1.1. Terminology 131 This document frequently uses the following terms: 133 Network Access Identifier 135 The Network Access Identifier (NAI) is the user identity submitted 136 by the client during network access authentication. In roaming, 137 the purpose of the NAI is to identify the user as well as to 138 assist in the routing of the authentication request. Please note 139 that the NAI may not necessarily be the same as the user's email 140 address or the user identity submitted in an application layer 141 authentication. 143 Network Access Server 145 The Network Access Server (NAS) is the device that clients connect 146 to in order to get access to the network. In PPTP terminology, 147 this is referred to as the PPTP Access Concentrator (PAC), and in 148 L2TP terminology, it is referred to as the L2TP Access 149 Concentrator (LAC). In IEEE 802.11, it is referred to as an 150 Access Point. 152 Roaming Capability 154 Roaming capability can be loosely defined as the ability to use 155 any one of multiple Internet Service Providers (ISPs), while 156 maintaining a formal, customer-vendor relationship with only one. 157 Examples of cases where roaming capability might be required 158 include ISP "confederations" and ISP-provided corporate network 159 access support. 161 Tunneling Service 163 A tunneling service is any network service enabled by tunneling 164 protocols such as PPTP, L2F, L2TP, and IPsec tunnel mode. One 165 example of a tunneling service is secure access to corporate 166 intranets via a Virtual Private Network (VPN). 168 1.2. Requirements Language 170 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 171 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 172 document are to be interpreted as described in [RFC2119]. 174 1.3. Purpose 176 As described in [RFC2194], there are a number of providers offering 177 network access services, and the number of Internet Service Providers 178 involved in roaming consortia is increasing rapidly. 180 In order to be able to offer roaming capability, one of the 181 requirements is to be able to identify the user's home authentication 182 server. For use in roaming, this function is accomplished via the 183 Network Access Identifier (NAI) submitted by the user to the NAS in 184 the initial network authentication. It is also expected that NASes 185 will use the NAI as part of the process of opening a new tunnel, in 186 order to determine the tunnel endpoint. 188 1.4. Motivation 190 The changes from [RFC4282] are listed in detail in Appendix A. 191 However, some additional discussion is appropriate to motivate those 192 changes. 194 The motivation to revise [RFC4282] began with internationalization 195 concerns raised in the context of [EDUROAM]. Section 2.1 of 196 [RFC4282] defines ABNF for realms which limits the realm grammar to 197 English letters, digits, and the hyphen "-" character. The intent 198 appears to have been to encode, compare, and transport realms with 199 the ToASCII operation defined in [RFC5890]. There are a number of 200 problems with this approach: 202 o The requirement in Section 2.1 that realms are ASCII conflicts 203 with the Extensible Authentication Protocol (EAP) and RADIUS, 204 which are both 8-bit clean, and which both recommend the use of 205 UTF-8 for identities. 207 o Section 2.4 required mappings that are language-specific, 208 and which are nearly impossible for intermediate nodes to perform 209 correctly without information about that language. 211 o Section 2.4 requires normalization of user names, which 212 may conflict with local system or administrative requirements. 214 o The recommendations in Section 2.4 for treatment of 215 bidirectional characters have proven to be unworkable. 217 o The prohibition against use of unassigned code points in 218 Section 2.4 effectively prohibits support for new scripts. 220 o No Authentication, Authorization, and Accounting (AAA) 221 client, proxy, or server has implemented any of the requirements 222 in [RFC4282] Section 2.4, among other sections. 224 With international roaming growing in popularity, it is important for 225 these issues to be corrected in order to provide robust and inter- 226 operable network services. 228 2. NAI Definition 230 2.1. UTF-8 Syntax and Normalization 232 UTF-8 characters can be defined in terms of octets using the 233 following ABNF [RFC5234], taken from [RFC3629]: 235 UTF8-xtra-char = UTF8-2 / UTF8-3 / UTF8-4 237 UTF8-2 = %xC2-DF UTF8-tail 239 UTF8-3 = %xE0 %xA0-BF UTF8-tail / 240 %xE1-EC 2(UTF8-tail) / 241 %xED %x80-9F UTF8-tail / 242 %xEE-EF 2(UTF8-tail) 244 UTF8-4 = %xF0 %x90-BF 2( UTF8-tail ) / 245 %xF1-F3 3( UTF8-tail ) / 246 %xF4 %x80-8F 2( UTF8-tail ) 248 UTF8-tail = %x80-BF 250 These are normatively defined in [RFC3629], but are repeated in this 251 document for reasons of convenience. 253 See [RFC5198] for a discussion of normalization; implementations of 254 this specification MUST use the Normal Form Composed (NFC) for NAIs. 256 2.2. Formal Syntax 258 The grammar for the NAI is given below, described in Augmented 259 Backus-Naur Form (ABNF) as documented in [RFC5234]. 261 nai = utf8-username 262 nai =/ "@" utf8-realm 263 nai =/ utf8-username "@" utf8-realm 265 utf8-username = dot-string 266 dot-string = string 267 dot-string =/ dot-string "." string 268 string = utf8-atext 269 string =/ string utf8-atext 271 utf8-atext = ALPHA / DIGIT / 272 "!" / "#" / 273 "$" / "%" / 274 "&" / "'" / 275 "*" / "+" / 276 "-" / "/" / 277 "=" / "?" / 278 "^" / "_" / 279 "`" / "{" / 280 "|" / "}" / 281 "~" / 282 UTF8-xtra-char 284 utf8-realm = 1*( label "." ) label 286 label = utf8-rtext *(ldh-str) 287 ldh-str = *( utf8-rtext / "-" ) utf8-rtext 288 utf8-rtext = ALPHA / DIGIT / UTF8-xtra-char 290 2.3. NAI Length Considerations 292 Devices handling NAIs MUST support an NAI length of at least 72 293 octets. Devices SHOULD support an NAI length of 253 octets. 294 However, the following implementation issues should be considered: 296 o NAIs are often transported in the User-Name attribute of the 297 Remote Authentication Dial-In User Service (RADIUS) protocol. 298 Unfortunately, RFC 2865 [RFC2865], Section 5.1, states that "the 299 ability to handle at least 63 octets is recommended." As a 300 result, it may not be possible to transfer NAIs beyond 63 octets 301 through all devices. In addition, since only a single User-Name 302 attribute may be included in a RADIUS message and the maximum 303 attribute length is 253 octets; RADIUS is unable to support NAI 304 lengths beyond 253 octets. 306 o NAIs can also be transported in the User-Name attribute of 307 Diameter [RFC3588], which supports content lengths up to 2^24 - 9 308 octets. As a result, NAIs processed only by Diameter nodes can be 309 very long. However, an NAI transported over Diameter may 310 eventually be translated to RADIUS, in which case the above 311 limitations will apply. 313 2.4. Support for Username Privacy 315 Interpretation of the username part of the NAI depends on the realm 316 in question. Therefore, the utf8-username portion SHOULD be treated 317 as opaque data when processed by nodes that are not a part of the 318 authoritative domain (in the sense of Section 4) for that realm. 320 In some situations, NAIs are used together with a separate 321 authentication method that can transfer the username part in a more 322 secure manner to increase privacy. In this case, NAIs MAY be 323 provided in an abbreviated form by omitting the username part. 324 Omitting the username part is RECOMMENDED over using a fixed username 325 part, such as "anonymous", since it provides an unambiguous way to 326 determine whether the username is intended to uniquely identify a 327 single user. 329 For roaming purposes, it is typically necessary to locate the 330 appropriate backend authentication server for the given NAI before 331 the authentication conversation can proceed. As a result, the realm 332 portion is typically required in order for the authentication 333 exchange to be routed to the appropriate server. 335 2.5. International Character Sets 337 This specification allows both international usernames and realms. 338 International usernames are based on the use of Unicode characters, 339 encoded as UTF-8. Internationalization of the realm portion of the 340 NAI is based on "Internationalized Email Headers" [RFC5335]. 342 In order to ensure a canonical representation, characters of the 343 username portion in an NAI MUST match the ABNF in this specification 344 as well as the requirements specified in [RFC5891]. In practice, 345 these requirements consist of the following item: 347 o Realms MUST be of the form that can be registered as a 348 Fully Qualified Domain Name (FQDN) within the DNS name system. 350 This list is significantly shorter and simpler than the list in 351 Section 2.4 of [RFC4282]. The form suggested in [RFC4282] depended 352 on intermediate nodes performing canonicalizations based on 353 insufficient information, which meant that the form was not 354 canonical. This document instead suggests (Section 2.10) that the 355 realm owner provide a canonical form of the realm, and that all 356 intermediate nodes use that form without modification. 358 Specifying the realm requirement as above means that the requirements 359 depend on specifications that are referenced here, rather than copied 360 here. This allows the realm definition to be updated when the 361 referenced documents change, without requiring a revision of this 362 specification. 364 In general, the above requirement means following the requirements as 365 specified in [RFC5891]. However, that document is in flux at the 366 time of this writing, and the issues with [RFC4282] mandate a timely 367 update to it. 369 2.6. The Normalization Process 371 All normalization MUST be performed by end systems that take "local" 372 text as input. That is, text that is in an encoding other than 373 UTF-8, or that has locale-specific variations. In a network access 374 setting, such systems are typically the client (e.g. EAP supplicant) 375 and the Authentication, Authorization, and Accounting (AAA) server. 377 All other AAA systems (proxies, etc.) MUST NOT perform 378 normalization. These other systems do not have access to locale and 379 character set information that is available to end systems. 381 That is, all processing of NAIs from "local" character sets and 382 locales to UTF-8 is performed by edge systems, prior to the NAIs 383 entering the AAA system. Inside of an AAA system, NAIs are sent over 384 the wire in their canonical form, and this canonical form is used for 385 all NAI and/or realm comparisons. 387 In contrast to the comments in [RFC4282] Section 2.4, we expect AAA 388 systems to perform NAI comparisons, matching, and AAA routing based 389 on the NAI as it is received. This specification provides a 390 canonical representation, ensures that intermediate systems such as 391 AAA proxies do not need to perform translations, and can be expected 392 to work through systems that are unaware of international character 393 sets. 395 For example, much of the common realm routing can be done on the 396 "utf8-realm" portion of NAI, through simple checks for equality. 397 This routing can be done even if the AAA proxy is unaware of 398 internalized domain names. All that is required is for the AAA proxy 399 to be able to enter, store, and compare 8-bit data. 401 EAP supplicants MUST normalize user names that get placed in the EAP- 402 Response/Identity field. They MUST NOT copy localized text into that 403 field. This normalization SHOULD be performed once, and then cached 404 for subsequent use. 406 2.7. Routing inside of AAA Systems 408 Many systems require that the "utf8-realm" portion of the NAI be used 409 to route requests within a AAA proxy network. The semantics of this 410 operation involves a logical AAA routing table, where the 411 "utf8-realm" portion acts as a key, and the values stored in the 412 table are one or more "next hop" AAA servers. 414 Intermediate nodes MUST use the "utf8-realm" portion of the NAI 415 without modification to perform this lookup. Comparisons between the 416 NAI as given in a AAA packet, and as provisioned in a logical AAA 417 routing table SHOULD be done as a byte-for-byte equality test. The 418 "utf8-realm" provisioned in the logical AAA routing table SHOULD be 419 provisioned prior to the proxy receiving any AAA traffic, and SHOULD 420 be supplied by the "next hop" system that also supplies the other 421 information about the next hop. 423 This "next hop" information may be IP address, port, RADIUS shared 424 secret, TLS certificates, or a DNS host name. 426 2.8. Compatibility with Email Usernames 428 As proposed in this document, the Network Access Identifier is of the 429 form user@realm. Please note that while the user portion of the NAI 430 is based on the BNF described in [RFC5198], it has been modified for 431 the purposes of Section 2.2. It does not permit quoted text along 432 with "folding" or "non-folding" whitespace that is commonly used in 433 email addresses. As such, the NAI is not necessarily equivalent to 434 usernames used in e-mail. 436 However, it is a common practice to use email addresses as user 437 identifiers in AAA systems. The ABNF in Section 2.2 is defined to be 438 close to the "utf8-addr-spec" portion of [RFC5335], while still being 439 compatible with [RFC4282]. 441 In contrast to the comments in [RFC4282] Section 2.5, we state that 442 the internationalization requirements for NAIs and email addresses 443 are substantially similar. The NAI and email identifiers may be the 444 same, and both need to be entered by the user and/or the operator 445 supplying network access to that user. There is therefore good 446 reason for the internationalization requirements to be similar. 448 2.9. Compatibility with DNS 450 The "realm" portion of the NAI is intended to be compatible with 451 domain names used in DNS systems. However, the "realm" portion 452 within AAA systems is intended to be a UTF-8 string, not an ASCII 453 string as with the DNS protocol. Therefore, AAA systems transporting 454 NAIs in an AAA protocol MUST NOT encode the "utf8-realm" portion 455 using the ToAscii function. That function creates strings that may 456 be transported over DNS, and it is not appropriate for use within an 457 AAA protocol. 459 When the realm portion of the NAI is used as the basis for name 460 lookups within the DNS system, the ToASCII operation defined in 461 [RFC5890] MAY be used to convert internationalized realm names to 462 ASCII. This function is normally handled by a DNS resolver library 463 on the local system. When this function is not handled by a DNS 464 resolver library, the AAA system MAY perform the ToAscii conversion 465 itself, before passing the modified realm name to the DNS resolver 466 library. 468 There is, however, a problem with this approach. A AAA proxy may not 469 have sufficient information in order to perform the ToAscii 470 conversion properly. We therefore RECOMMEND that only the owner of 471 the realm perform the ToAscii conversion. We RECOMMEND that the 472 owner of the realm pre-provision all proxies with the "utf8-realm" 473 portion of the NAI, along with the value returned from passing the 474 "utf8-realm" to the ToAscii function. This key-value pair can then 475 be placed into logical AAA routing table discussed above. Having 476 only one entity run the ToAscii function ensures that the result 477 returned by that function are considered as canonical form by all 478 other participants in a AAA network. 480 The paragraph above does not negate all of the benefits of using DNS 481 to automatically discover the location of a "next hop" AAA server. 482 Many AAA proxies require a business or legal relationship prior to 483 routing any traffic. This relationship can be leveraged to bootstrap 484 the DNS information located in the logical AAA routing table. 486 2.10. Realm Construction 488 The home realm usually appears in the realm portion of the NAI, but 489 in some cases a different realm can be used. This may be useful, for 490 instance, when the home realm is reachable only via intermediate 491 proxies. 493 Such usage may prevent interoperability unless the parties involved 494 have a mutual agreement that the usage is allowed. In particular, 495 NAIs MUST NOT use a different realm than the home realm unless the 496 sender has explicit knowledge that (a) the specified other realm is 497 available and (b) the other realm supports such usage. The sender 498 may determine the fulfillment of these conditions through a database, 499 dynamic discovery, or other means not specified here. Note that the 500 first condition is affected by roaming, as the availability of the 501 other realm may depend on the user's location or the desired 502 application. 504 The use of the home realm MUST be the default unless otherwise 505 configured. 507 2.10.1. Historical Practices 509 Some systems have historically used NAI modifications with multiple 510 "prefix" and "suffix" decorations to perform explicit routing through 511 multiple proxies inside of a AAA network. This practice is NOT 512 RECOMMENDED for the following reasons: 514 o Using explicit routing paths is fragile, and is unresponsive to 515 changes in the network due to servers going up or down, or to 516 changing business relationships. 518 o There is no RADIUS routing protocol, meaning that routing paths 519 have to be communicated "out of band" to all intermediate AAA 520 nodes, and also to all end-user systems (supplicants) expecting to 521 obtain network access. 523 o Using explicit routing paths requires thousands, if not 524 millions of end-user systems to be updated with new path 525 information when a AAA routing path changes. This adds huge 526 expense for updates that would be better done at only a few AAA 527 systems in the network. 529 o Manual updates to RADIUS paths are expensive, time-consuming, 530 and prone to error. 532 o Re-writing of the User-Name in AAA servers means that it may not 533 match the EAP-Response/Identity fields. This mismatch may cause 534 the home AAA server to reject the request as being malformed. 536 o Creating compatible formats for the NAI is difficult 537 when locally-defined "prefixes" and "suffixes" conflict with 538 similar practices elsewhere in the network. These conflicts mean 539 that connecting two networks may be impossible in some cases, as 540 there is no way for packets to be routed properly in a way that 541 meets all requirements at all intermediate proxies. 543 o Leveraging the DNS name system for realm names establishes 544 a globally unique name space for realms. 546 In summary, network practices and capabilities have changed 547 significantly since NAIs were first overloaded to define AAA routes 548 through a network. While explicit path routing was once useful, the 549 time has come for better methods to be used. 551 2.11. Examples 553 Examples of valid Network Access Identifiers include the following: 555 bob 556 joe@example.com 557 fred@foo-9.example.com 558 jack@3rd.depts.example.com 559 fred.smith@example.com 560 fred_smith@example.com 561 fred$@example.com 562 fred=?#$&*+-/^smith@example.com 563 nancy@eng.example.net 564 eng.example.net!nancy@example.net 565 eng%nancy@example.net 566 @privatecorp.example.net 567 \(user\)@example.net 569 Examples of invalid Network Access Identifiers include the following: 571 fred@example 572 fred@example_9.com 573 fred@example.net@example.net 574 fred.@example.net 575 eng:nancy@example.net 576 eng;nancy@example.net 577 (user)@example.net 578 @example.net 580 One example given in [RFC4282] is still permitted by the ABNF, but it 581 is NOT RECOMMMENDED because of the use of the ToAscii function to 582 create an ASCII encoding from what is now a valid UTF-8 string. 584 alice@xn--tmonesimerkki-bfbb.example.net 586 3. Security Considerations 588 Since an NAI reveals the home affiliation of a user, it may assist an 589 attacker in further probing the username space. Typically, this 590 problem is of most concern in protocols that transmit the username in 591 clear-text across the Internet, such as in RADIUS, described in 592 [RFC2865] and [RFC2866]. In order to prevent snooping of the 593 username, protocols may use confidentiality services provided by 594 protocols transporting them, such as RADIUS protected by IPsec 595 [RFC3579] or Diameter protected by TLS [RFC3588]. 597 This specification adds the possibility of hiding the username part 598 in the NAI, by omitting it. As discussed in Section 2.4, this is 599 possible only when NAIs are used together with a separate 600 authentication method that can transfer the username in a secure 601 manner. In some cases, application-specific privacy mechanism have 602 also been used with NAIs. For instance, some EAP methods apply 603 method-specific pseudonyms in the username part of the NAI [RFC3748]. 604 While neither of these approaches can protect the realm part, their 605 advantage over transport protection is that privacy of the username 606 is protected, even through intermediate nodes such as NASes. 608 4. IANA Considerations 610 In order to avoid creating any new administrative procedures, 611 administration of the NAI realm namespace piggybacks on the 612 administration of the DNS namespace. 614 NAI realm names are required to be unique, and the rights to use a 615 given NAI realm for roaming purposes are obtained coincident with 616 acquiring the rights to use a particular Fully Qualified Domain Name 617 (FQDN). Those wishing to use an NAI realm name should first acquire 618 the rights to use the corresponding FQDN. Using an NAI realm without 619 ownership of the corresponding FQDN creates the possibility of 620 conflict and is therefore discouraged. 622 Note that the use of an FQDN as the realm name does not require use 623 of the DNS for location of the authentication server. While Diameter 624 [RFC3588] supports the use of DNS for location of authentication 625 servers, existing RADIUS implementations typically use proxy 626 configuration files in order to locate authentication servers within 627 a domain and perform authentication routing. The implementations 628 described in [RFC2194] did not use DNS for location of the 629 authentication server within a domain. Similarly, existing 630 implementations have not found a need for dynamic routing protocols 631 or propagation of global routing information. Note also that there 632 is no requirement that the NAI represent a valid email address. 634 5. References 636 5.1. Normative References 638 [RFC2119] 639 Bradner, S., "Key words for use in RFCs to Indicate Requirement 640 Levels", RFC 2119, March, 1997. 642 [RFC3629] 643 Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, 644 RFC 3629, November 2003. 646 [RFC5198] 647 Klensin J., and Padlipsky M., "Unicode Format for Network 648 Interchange", RFC 5198, March 2008 650 [RFC5234] 651 Crocker, D. and P. Overell, "Augmented BNF for Syntax 652 Specifications: ABNF", RFC 5234, January 2008. 654 [RFC5890] 655 Faltstrom, P., Hoffman, P., and A. Costello, "Internationalizing 656 Domain Names in Applications (IDNA)", RFC 5890 658 5.2. Informative References 660 [RFC2194] 661 Aboba, B., Lu, J., Alsop, J., Ding, J., and W. Wang, "Review of 662 Roaming Implementations", RFC 2194, September 1997. 664 [RFC2341] 665 Valencia, A., Littlewood, M., and T. Kolar, "Cisco Layer Two 666 Forwarding (Protocol) "L2F"", RFC 2341, May 1998. 668 [RFC2637] 669 Hamzeh, K., Pall, G., Verthein, W., Taarud, J., Little, W., and G. 670 Zorn, "Point-to-Point Tunneling Protocol", RFC 2637, July 1999. 672 [RFC2661] 673 Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G., and B. 674 Palter, "Layer Two Tunneling Protocol "L2TP"", RFC 2661, August 675 1999. 677 [RFC2865] 678 Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote 679 Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. 681 [RFC2866] 682 Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. 684 [RFC3579] 685 Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial In 686 User Service) Support For Extensible Authentication Protocol 687 (EAP)", RFC 3579, September 2003. 689 [RFC3588] 690 Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, 691 "Diameter Base Protocol", RFC 3588, September 2003. 693 [RFC3748] 694 Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 695 Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, 696 June 2004. 698 [RFC4282] 699 Aboba, B. et al., "The Network Access Identifier", RFC 4282, 700 December 2005. 702 [RFC4301] 703 Kent, S. and S. Keo, "Security Architecture for the Internet 704 Protocol", RFC 4301, December 2005. 706 [RFC5335] 707 Y. Abel, Ed., "Internationalized Email Headers", RFC 5335, 708 September 2008. 710 [EDUROAM] 711 http://eduroam.org, "eduroam (EDUcational ROAMing)" 713 [RFC5891] 714 Klensin, J., "Internationalized Domain Names in Applications 715 (IDNA): Protocol", RFC 5891 717 Acknowledgments 719 The initial text for this document was [RFC4282], which was then 720 heavily edited. The original authors of [RFC4282] were Bernard 721 Aboba, Mark A. Beadles, Jari Arkko, and Pasi Eronen. 723 The ABNF validator at http://www.apps.ietf.org/abnf.html was used to 724 verify the syntactic correctness of the ABNF in Section 2. 726 Appendix A - Changes from RFC4282 728 This document contains the following updates with respect to the 729 previous NAI definition in RFC 4282 [RFC4282]: 731 o The formal syntax in Section 2.1 has been updated to forbid 732 non-UTF8 characters. e.g. characters with the "high bit" set. 734 o The formal syntax in Section 2.1 has been updated to allow 735 UTF-8 in the "realm" portion of the NAI. 737 o The formal syntax in [RFC4282] Section 2.1 applied to the 738 NAI after it was "internationalized" via the ToAscii function. 739 The contents of the NAI before it was "internationalized" were 740 left indeterminate. This document updates the formal syntax to 741 define an internationalized form of the NAI, and forbids the use 742 of the ToAscii function for NAI "internationalization". 744 o The grammar for the user and realm portion is based on a 745 combination 746 of the "nai" defined in [RFC4282] Section 2.1, and the "utf8-addr- 747 spec" defined in [RFC5335] Section 4.4. 749 o All use of the ToAscii function has been moved to normal 750 requirements on DNS implementations when realms are used as the 751 basis for DNS lookups. This involves no changes to the existing 752 DNS infrastructure. 754 o The discussions on internationalized character sets in Section 2.4 755 have been updated. The suggestion to use the ToAscii function for 756 realm comparisons has been removed. No AAA system implemented the 757 suggestion, so this change should have no operational impact. 759 o The section "Routing inside of AAA Systems" section is new in this 760 document. The concept of a "local AAA routing table" is also new, 761 although it accurately describes the functionality of wide-spread 762 implementations. 764 o The "Compatibility with EMail Usernames" and "Compatibility 765 with DNS" sections have been revised and updated. We now note 766 that the ToAscii function is required to be used only when a realm 767 name is used for DNS lookups, and even then the function is only 768 used by a DNS resolving library on the local system, and even then 769 we recommend that only the home network perform this conversion. 771 o The "Realm Construction" section has been updated to note 772 that editing of the NAI is NOT RECOMMENDED. 774 o The "Examples" section has been updated to remove the instance 775 of the IDN being converted to ASCII. This behavior is now 776 forbidden. 778 Authors' Addresses 780 Alan DeKok 781 The FreeRADIUS Server Project 783 Email: aland@freeradius.org