--- 1/draft-ietf-radext-nai-12.txt 2014-12-04 09:14:53.888042148 -0800 +++ 2/draft-ietf-radext-nai-13.txt 2014-12-04 09:14:53.944043517 -0800 @@ -1,20 +1,20 @@ RADEXT Working Group DeKok, Alan INTERNET-DRAFT FreeRADIUS Obsoletes: 4282 Category: Standards Track - -3 December 2014 + +4 December 2014 The Network Access Identifier - draft-ietf-radext-nai-12 + draft-ietf-radext-nai-13 Abstract In order to provide inter-domain authentication services, it is necessary to have a standardized method that domains can use to identify each other's users. This document defines the syntax for the Network Access Identifier (NAI), the user identifier submitted by the client prior to accessing resources. This document is a revised version of RFC 4282, which addresses issues with international character sets, as well as a number of other corrections to the @@ -34,21 +34,21 @@ and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. - This Internet-Draft will expire on June 03, 2015. + This Internet-Draft will expire on June 04, 2015. Copyright Notice Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -88,26 +88,26 @@ 2.6.1. Issues with the Normalization Process .......... 15 2.7. Use in Other Protocols .............................. 16 2.8. Using the NAI format for other identifiers .......... 17 3. Routing inside of AAA Systems ............................ 18 3.1. Compatibility with Email Usernames .................. 19 3.2. Compatibility with DNS .............................. 19 3.3. Realm Construction .................................. 20 3.3.1. Historical Practices ........................... 20 3.4. Examples ............................................ 21 4. Security Considerations .................................. 22 - 4.1. Correlation of Identities over Time and Protocols ... 22 + 4.1. Correlation of Identities over Time and Protocols ... 23 4.2. Multiple Identifiers ................................ 23 5. Administration of Names .................................. 24 6. IANA Considerations ...................................... 24 -7. References ............................................... 24 - 7.1. Normative References ................................ 24 +7. References ............................................... 25 + 7.1. Normative References ................................ 25 7.2. Informative References .............................. 25 Appendix A - Changes from RFC4282 ............................ 28 1. Introduction Considerable interest exists for a set of features that fit within the general category of inter-domain authentication, or "roaming capability" for network access, including dialup Internet users, Virtual Private Network (VPN) usage, wireless LAN authentication, and other applications. @@ -156,52 +156,53 @@ necessary to have a standardized method for identifying users. This document defines syntax for the Network Access Identifier (NAI). Examples of implementations that use the NAI, and descriptions of its semantics, can be found in [RFC2194]. When the NAI was defined for network access, it had the side effect of defining an identifier which could be used in non-AAA systems. Some non-AAA systems defined identifiers which were compatible with the NAI, and deployments used the NAI. This process simplified the management of credentials, by re-using the same credential in - multiple situations. We suggest that this re-use is good practice, - so long as privacy issues are dealt with. The alternative is to have - protocol-specific identifiers, which increases cost to both the user - and the administrator. + multiple situations. Protocols that re-use the same credential or + the same identifier format can benefit from this management + simplicity. The alternative is to have protocol-specific credentials + or identifier formats, which increases cost to both the user and the + administrator. There are privacy implications to using one identifier across multiple protocols. See Section 2.7 and Section 4 for further discussion of this topic. The goal of this document is to define the format of an identifier which can be used in many protocols. A protocol may transport an encoded version of the NAI (e.g. '.' as %2E). However, the definition of the NAI is protocol independent. We hope to encourage - the wide-spread adoption of the NAI as an identifier. This adoption - will decrease work required to leverage identification and - authentication in other protocols. It will also decrease the - complexity of non-AAA systems for end users and administrators. + the wide-spread adoption of the NAI format. This adoption will + decrease work required to leverage identification and authentication + in other protocols. It will also decrease the complexity of non-AAA + systems for end users and administrators. - We note that this document only suggest that the NAI be used, but - does not require such use. Many protocols already define their own - identifier formats. Some of these are incompatible with the NAI, + We note that this document only suggests that the NAI format be used, + but does not require such use. Many protocols already define their + own identifier formats. Some of these are incompatible with the NAI, while others allow the NAI in addition to non-NAI identifiers. The definition of the NAI in this document has no requirements on protocol specifications, implementations, or deployments. - However, we suggest that using one standard identifier format is - preferable to using multiple incompatible identifier formats. Where - identifiers need to be used in new protocols and/or specifications, - it is RECOMMENDED that the format of the NAI be used. That is, the - interpretation of the identifier is context-specific, while the - format of the identifier remains the same. These issues are - discussed in more detail in Section 2.8, below. + However, this document suggests that using one standard identifier + format is preferable to using multiple incompatible identifier + formats. Where identifiers need to be used in new protocols and/or + specifications, it is RECOMMENDED that the format of the NAI be used. + That is, the interpretation of the identifier is context-specific, + while the format of the identifier remains the same. These issues + are discussed in more detail in Section 2.8, below. The recommendation for a standard identifier format is not a recommendation that each user have one universal identifier. In contrast, this document allows for the use of multiple identifiers, and recommends the use of anonymous identifiers where those identifiers are publicly visible. This document is a revised version of [RFC4282], which originally defined internationalized NAIs. Differences and enhancements compared to that document are listed in Appendix A. @@ -279,71 +280,72 @@ Providers are involved in roaming consortia. In order to be able to offer roaming capability, one of the requirements is to be able to identify the user's home authentication server. For use in roaming, this function is accomplished via the Network Access Identifier (NAI) submitted by the user to the NAS in the initial network authentication. It is also expected that NASes will use the NAI as part of the process of opening a new tunnel, in order to determine the tunnel endpoint. - We also hope that other protocols can take advantage of the NAI. - Many protocols include authentication capabilities, including - defining their own identifier formats. These identifiers can then - end up being transported in AAA protocols, so that the originating - protocols can leverage AAA for user authentication. There is - therefore a need for a definition of a user identifier which can be - used in multiple protocols. + We also hope that other protocols can take advantage of the NAI + format. Many protocols include authentication capabilities, + including defining their own identifier formats. These identifiers + can then end up being transported in AAA protocols, so that the + originating protocols can leverage AAA for user authentication. + There is therefore a need for a definition of a user identifier which + can be used in multiple protocols. While we define the NAI here, we recognize that existing protocols and deployments do not always use it. AAA systems MUST therefore be able to handle user identifiers which are not in the NAI format. The process by which that is done is outside of the scope of this document. - Non-AAA systems MAY accept user identifiers in forms other than the + Non-AAA systems can accept user identifiers in forms other than the NAI. This specification does not forbid that practice. It only codifies the format and interpretation of the NAI. We cannot expect to change existing protocols or practices. We can, however, suggest that using a consistent form for a user identifier is of a benefit to the community. We note that this document does not make any protocol-specific definitions for an identifier format, and it does not make changes to any existing protocol. Instead, it defines a protocol-independent form for the NAI. It is hoped that the NAI is a user identifier which can be used in multiple protocols. Using a common identifier format implifies protocols requiring authentication, as they no longer need to specify protocol-specific format for user identifiers. It increases security, as it multiple identifier formats allow attackers to make contradictory claims without being detected (see Section 4.2 for further discussion of this topic). It simplifies deployments, as a user can have one identifier in multiple contexts, which allows them to be uniquely - identified, so long as that identifier is itself kept private. + identified, so long as that identifier is itself protected against + access. In short, having a standard is better than having no standard at all. 1.4. Motivation The changes from [RFC4282] are listed in detail in Appendix A. However, some additional discussion is appropriate to motivate those changes. The motivation to revise [RFC4282] began with internationalization concerns raised in the context of [EDUROAM]. Section 2.1 of [RFC4282] defines ABNF for realms which limits the realm grammar to English letters, digits, and the hyphen "-" character. The intent appears to have been to encode, compare, and transport realms with - the ToASCII operation defined in [RFC5890]. There are a number of - problems with this approach: + the Punycode [RFC3492] encoding form as described in [RFC5891] There + are a number of problems with this approach: * The [RFC4282] ABNF is not aligned with internationalization of DNS. * The requirement in [RFC4282] Section 2.1 that realms are ASCII conflicts with the Extensible Authentication Protocol (EAP) defined in [RFC3748], and RADIUS, which are both 8-bit clean, and which both recommend the use of UTF-8 for identitifiers. * [RFC4282] Section 2.4 required mappings that are language-specific, and which are nearly impossible for @@ -362,20 +364,24 @@ scripts. * No Authentication, Authorization, and Accounting (AAA) client, proxy, or server has implemented any of the requirements in [RFC4282] Section 2.4, among other sections. With international roaming growing in popularity, it is important for these issues to be corrected in order to provide robust and inter- operable network services. + Furthermore, this document was motivated by a desire to codify + existing practice related to the use of the NAI format and to + encourage widespread use of the format. + 2. NAI Definition 2.1. UTF-8 Syntax and Normalization UTF-8 characters can be defined in terms of octets using the following ABNF [RFC5234], taken from [RFC3629]: UTF8-xtra-char = UTF8-2 / UTF8-3 / UTF8-4 UTF8-2 = %xC2-DF UTF8-tail @@ -394,32 +400,33 @@ These are normatively defined in [RFC3629], but are repeated in this document for reasons of convenience. See [RFC5198] and section 2.6 of this specification for a discussion of normalization. Strings which are not in Normal Form Composed (NFC) are not valid NAIs and SHOULD NOT be treated as such. Implementations which expect to receive a NAI, but which instead receive non-normalised (but otherwise valid) UTF-8 strings instead SHOULD attempt to create a local version of the NAI, which is normalized from the input identifier. This local version can then be - used for local processing. + used for local processing. This local version of the identifier MUST + NOT be used outside of the local context. Where protocols carry identifiers which are expected to be transported over an AAA protocol, it is RECOMMENDED that the identifiers be in NAI format. Where the identifiers are not in the NAI format, it is up to the AAA systems to discover this, and to process them. This document does not suggest how that is done. However, existing practice indicates that it is possible. We expect that with wider use of internationalized domain names, existing practices will be inadequate. We therefore define the NAI, - which is a user identifier that can correctly deal with + which is a user identifier format that can correctly deal with internationalized identifiers. 2.2. Formal Syntax The grammar for the NAI is given below, described in Augmented Backus-Naur Form (ABNF) as documented in [RFC5234]. nai = utf8-username nai =/ "@" utf8-realm nai =/ utf8-username "@" utf8-realm @@ -493,25 +500,24 @@ may be used as "firstname.lastname", or it may be entirely digits, or it may be a random hex identifier. There is simply no way (and no reason) for any other domain to interpret the utf8-username field as having any meaning whatsoever. In some situations, NAIs are used together with a separate authentication method that can transfer the username part in a more secure manner to increase privacy. In this case, NAIs MAY be provided in an abbreviated form by omitting the username part. Omitting the username part is RECOMMENDED over using a fixed username - part, such as "anonymous", since it provides an unambiguous way to - determine whether the username is intended to uniquely identify a - single user. However, current practice is to use the username - "anonymous" instead of omitting the username part. This behavior is - also permitted. + part, such as "anonymous", since including a fixed username part is + ambiguous as to whether or not the NAI refers to a single user. + However, current practice is to use the username "anonymous" instead + of omitting the username part. This behavior is also permitted. The most common use-case of such behavior is with TLS-based EAP methods such as TTLS [RFC5281]. Those methods allow for an "outer" identifier, which is typically an anonymous "@realm". This outer identifier allows the authentication request to be routed from a visited domain to a home domain. At the same time, user privacy is preserved. The protocol provides for an "inner" authentication exchange, in which a full identifier is used to authenticate a user. That scenario offers the best of both worlds. An anonymous NAI can @@ -538,26 +544,26 @@ appropriate backend authentication server for the given NAI before the authentication conversation can proceed. As a result, authentication routing is impossible unless the realm portion is available, and in a well-known format. 2.5. International Character Sets This specification allows both international usernames and realms. International usernames are based on the use of Unicode characters, encoded as UTF-8. Internationalization of the realm portion of the - NAI is based on "Internationalized Email Headers" [RFC5335]. + NAI is based on [RFC5890]. In order to ensure a canonical representation, characters of the - username portion in an NAI MUST match the ABNF in this specification - as well as the requirements specified in [RFC5891]. In practice, - these requirements consist of the following item: + realm portion in an NAI MUST match the ABNF in this specification as + well as the requirements specified in [RFC5891]. In practice, these + requirements consist of the following item: * Realms MUST be of the form that can be registered as a Fully Qualified Domain Name (FQDN) within the DNS. This list is significantly shorter and simpler than the list in Section 2.4 of [RFC4282]. The form suggested in [RFC4282] depended on intermediate nodes performing canonicalizations based on insufficient information, which meant that the form was not canonical. @@ -669,32 +674,31 @@ realm. If no match is found, the original form of the NAI SHOULD be used in all subsequent processing. The AAA server may also convert realms to punycode, and perform all realm comparisons on the resulting punycode strings. This conversion follows the recommendations above, but may have different operational effects and failure modes. 2.7. Use in Other Protocols - As noted earlier, the NAI MAY be used in other, non-AAA protocols. - It is RECOMMENDED that the definition given here be used unchanged. - Using other definitions for user identifiers may hinder + As noted earlier, the NAI format can be used in other, non-AAA + protocols. It is RECOMMENDED that the definition given here be used + unchanged. Using other definitions for user identifiers may hinder interoperability, along with the users ability to authenticate successfully. It is RECOMMENDED that protocols requiring the use of - a user identifier reference this specification, and suggest that the - use of an NAI is RECOMMENDED. + a user identifier use the NAI format. - We cannot require other protocols to use the NAI for user - identifiers. Their needs are unknown, and unknowable. We simply - suggest that interoperability and inter-domain authentication is - useful, and should be encouraged. + We cannot require other protocols to use the NAI format for user + identifiers. Their needs are unknown, and at this time unknowable. + This document suggests that interoperability and inter-domain + authentication is useful, and should be encouraged. Where a protocol is 8-bit clean, it can likely transport the NAI as- is, without further modification. Where a protocol is not 8-bit clean, it cannot transport the NAI as- is. Instead, we presume that a protocol-specific transport layer takes care of encoding the NAI on input to the protocol, and decoding it when the NAI exits the protocol. The encoded or escaped version of the NAI is not a valid NAI, and MUST NOT be presented to the AAA system. @@ -733,31 +737,32 @@ The private user identity shall take the form of an NAI, and shall have the form username@realm as specified in clause 2.1 of IETF RFC 4282 For 3GPP, the "username" portion is a unique identifier which is derived from device-specific information. The "realm" portion is composed of information about the home network, followed by the base string "3gppnetwork.org". e.g. 234150999999999@ims.mnc015.mcc234.3gppnetwork.org. - This format ensures that the identifier is globally unique, as it is - based off of the "3gppnetwork.org" domain. It ensures that the - "realm" portion is specific to a particular home network (or - organization), via the "ims.mnc015.mcc234" prefix to the realm. - Finally, it ensures that the "username" portion follows a well-known - format. + This format as defiend by 3GPP ensures that the identifier is + globally unique, as it is based off of the "3gppnetwork.org" domain. + It ensures that the "realm" portion is specific to a particular home + network (or organization), via the "ims.mnc015.mcc234" prefix to the + realm. Finally, it ensures that the "username" portion follows a + well-known format. - We suggest that the NAI format be used for all new specifications - and/or protocols where a user identifier is required. It is - RECOMMENDED that methods similar to that described above for 3GPP be - used to derive the identifier. + This document suggests that the NAI format be used for all new + specifications and/or protocols where a user identifier is required. + + It is RECOMMENDED that methods similar to that described above for + 3GPP be used to derive the identifier. 3. Routing inside of AAA Systems Many AAA systems use the "utf8-realm" portion of the NAI to route requests within a AAA proxy network. The semantics of this operation involves a logical AAA routing table, where the "utf8-realm" portion acts as a key, and the values stored in the table are one or more "next hop" AAA servers. Intermediate nodes MUST use the "utf8-realm" portion of the NAI @@ -814,51 +818,51 @@ form "user@realm". Please note that while the user portion of the NAI is based on the BNF described in [RFC5198], it has been modified for the purposes of Section 2.2. It does not permit quoted text along with "folding" or "non-folding" whitespace that is commonly used in email addresses. As such, the NAI is not necessarily equivalent to usernames used in e-mail. However, it is a common practice to use email addresses as user identifiers in AAA systems. The ABNF in Section 2.2 is defined to be close to the "utf8-addr-spec" portion of [RFC5335], while still being - compatible with [RFC4282]. + compatible with [RFC4282], [RFC5890], and [RFC5891]. In contrast to [RFC4282] Section 2.5, we state that the internationalization requirements for NAIs and email addresses are substantially similar. The NAI and email identifiers may be the same, and both need to be entered by the user and/or the operator supplying network access to that user. There is therefore good reason for the internationalization requirements to be similar. 3.2. Compatibility with DNS The "utf8-realm" portion of the NAI is intended to be compatible with Internationalized Domain Names (IDNs) [RFC5890]. As defined above, the "utf8-realm" portion as transported within an 8-bit clean protocol such as RADIUS and EAP can contain any valid UTF8 character. - There is therefore no reason for a NAS to apply the ToAscii function - to the "utf8-realm" portion of an NAI, prior to placing the NAI into - a RADIUS User-Name attribute. + There is therefore no reason for a NAS to convert the "utf8-realm" + portion of an NAI into Punycode encoding form [RFC3492] prior to + placing the NAI into a RADIUS User-Name attribute. The NAI does not make a distinction between A-labels and U-labels, as those are terms specific to DNS. It is instead an IDNA-valid label, as per the first item in Section 2.3.2.1 of [RFC5890]. As noted in that section, the term "IDNA-valid label" encompases both of the terms A-label and U-label. When the realm portion of the NAI is used as the basis for name resolution, it may be necessary to convert internationalized realm - names to ASCII using the ToASCII operation defined in [RFC5890]. As - noted in [RFC6055] Section 2, resolver Application Programming - Interfaces (APIs) are not necessarily DNS-specific, so that the - ToASCII operation needs to be applied carefully: + names to Punycode [RFC3492] encoding form as described in [RFC5891]. + As noted in [RFC6055] Section 2, resolver Application Programming + Interfaces (APIs) are not necessarily DNS-specific, so conversion to + Punycode needs to be done carefully: Applications which convert an IDN to A-label form before calling (for example) getaddrinfo() will result in name resolution failures if the Punycode name is directly used in such protocols. Having libraries or protocols to convert from A-labels to the encoding scheme defined by the protocol (e.g., UTF-8) would require changes to APIs and/or servers, which IDNA was intended to avoid. As a result, applications SHOULD NOT assume that non-ASCII names are resolvable using the public DNS and blindly convert them to A-labels @@ -916,22 +920,30 @@ similar practices elsewhere in the network. These conflicts mean that connecting two networks may be impossible in some cases, as there is no way for packets to be routed properly in a way that meets all requirements at all intermediate proxies. * Leveraging the DNS name system for realm names establishes a globally unique name space for realms. In summary, network practices and capabilities have changed significantly since NAIs were first overloaded to define AAA routes - through a network. While explicit path routing was once useful, the - time has come for better methods to be used. + through a network. While manually managed explicit path routing was + once useful, the time has come for better methods to be used. + + Notwithstanding the above recommendations, we note that the above + practice is widely used for Diameter routing [RFC5729]. The routes + described there are managed automatically, from both credential + provisioning and routing updates. Those routes also exist within a + particular framework (typically 3G), where membership is controlled + and system behavior is standardized. There are no known issues with + using explicit routing in such an environment. 3.4. Examples Examples of valid Network Access Identifiers include the following: bob joe@example.com fred@foo-9.example.com jack@3rd.depts.example.com fred.smith@example.com @@ -954,22 +966,22 @@ fred@example fred@example_9.com fred@example.net@example.net fred.@example.net eng:nancy@example.net eng;nancy@example.net (user)@example.net @example.net One example given in [RFC4282] is still permitted by the ABNF, but it - is NOT RECOMMMENDED because of the use of the ToAscii function to - create an ASCII encoding from what is now a valid UTF-8 string. + is NOT RECOMMMENDED because of the use of the Punycode [RFC3492] + encoding form for what is now a valid UTF-8 string. alice@xn--tmonesimerkki-bfbb.example.net 4. Security Considerations Since an NAI reveals the home affiliation of a user, it may assist an attacker in further probing the username space. Typically, this problem is of most concern in protocols that transmit the username in clear-text across the Internet, such as in RADIUS, described in [RFC2865] and [RFC2866]. In order to prevent snooping of the @@ -1018,24 +1030,24 @@ outer identifier, and "user@example.org" as an inner identifier. The authentication request will then be routed to "example.com", which will likely be unable to authenticate "user@example.org". Even worse, a misconfiguration of "example.com" means that it may in turn proxy the inner authentication request to the "example.org" domain. Such cross-domain authentication is highly problematic, and there are few good reasons to allow it. It is therefore RECOMMENDED that systems which permit anonymous - "outer" identifiers require that the both the "outer" and "inner" - identifiers use the same realm. An authentication request using - different realms is a security violation, and the request SHOULD be - rejected. + "outer" identifiers require that the "inner" domain be the same as, + or a sub-domain of the "outer" domain. An authentication request + using disparate realms is a security violation, and the request + SHOULD be rejected. The situation gets worse when multiple protocols are involved. The TTLS protocol permits MS-CHAP [RFC2433] to be carried inside of the TLS tunnel. MS-CHAP defines its own identifier which is encapsulated inside of the MS-CHAP exchange. That identifier is not required to be UTF-8, and in practice, can be one of many unknown character sets. There is no way in practice to determine which character set was used for that identifier. The result is that the "outer" EAP Identity carried by TTLS is likely @@ -1094,20 +1106,24 @@ Interchange", RFC 5198, March 2008 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 5234, January 2008. [RFC5890] Faltstrom, P., Hoffman, P., and A. Costello, "Internationalizing Domain Names in Applications (IDNA)", RFC 5890, August 2010 +[RFC5891] + Klensin, J., "Internationalized Domain Names in Applications + (IDNA): Protocol", RFC 5891, August 2010 + [RFC6365] Hoffman, P., and Klensin, J., "Terminology Used in Internationalization in the IETF", RFC 6365, September 2011 7.2. Informative References [RFC2194] Aboba, B., Lu, J., Alsop, J., Ding, J., and W. Wang, "Review of Roaming Implementations", RFC 2194, September 1997. @@ -1128,66 +1145,72 @@ Palter, "Layer Two Tunneling Protocol "L2TP"", RFC 2661, August 1999. [RFC2865] Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. +[RFC3492] + Costello, A., "Punycode: A Bootstring encoding of Unicode for + Internationalized Domain Names in Applications (IDNA)", RFC 3492, + March 2003. + [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial In User Service) Support For Extensible Authentication Protocol (EAP)", RFC 3579, September 2003. [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004. [RFC4282] Aboba, B. et al., "The Network Access Identifier", RFC 4282, December 2005. [RFC4301] Kent, S. and S. Keo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005. -[RFC5335] - Y. Abel, Ed., "Internationalized Email Headers", RFC 5335, - September 2008. - -[EDUROAM] - http://eduroam.org, "eduroam (EDUcational ROAMing)" - [RFC5281] Funk, P., and Blake-Wilson, S., "Extensible Authentication Protocol Tunneled Transport Layer Security Authenticated Protocol Version 0 (EAP-TTLSv0)", RFC 5281, August 2008/ -[RFC5891] - Klensin, J., "Internationalized Domain Names in Applications - (IDNA): Protocol", RFC 5891, August 2010 +[RFC5335] + Y. Abel, Ed., "Internationalized Email Headers", RFC 5335, + September 2008. + +[RFC5729] + Korhohen, J. (Ed) et. al., "Clarifications on the Routing of + Diameter Requests Based on the Username and the Realm", RFC 5729, + December 2009 [RFC6055] Thaler, D., et al, "IAB Thoughts on Encodings for Internationalized Domain Names", RFC 6055, February 2011. [RFC6733] V. Fajardo, Ed., et al, "Diameter Base Protocol", RFC 6733, October 2012. [RFC6912] Sullivan, A., et al, "Principles for Unicode Code Point Inclusion in Labels in the DNS", RFC 6912, April 2013. +[EDUROAM] + http://eduroam.org, "eduroam (EDUcational ROAMing)" + [3GPP] 3GPP, "TS 23.003 Numbering, addressing, and Identification (Release 12)", July 2014, ftp://ftp.3gpp.org/Specs/archive/23_series/23.003/. Acknowledgments The initial text for this document was [RFC4282], which was then heavily edited. The original authors of [RFC4282] were Bernard Aboba, Mark A. Beadles, Jari Arkko, and Pasi Eronen.