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