--- 1/draft-ietf-radext-nai-11.txt 2014-12-03 11:14:45.368036583 -0800 +++ 2/draft-ietf-radext-nai-12.txt 2014-12-03 11:14:45.424037988 -0800 @@ -1,27 +1,27 @@ RADEXT Working Group DeKok, Alan INTERNET-DRAFT FreeRADIUS Obsoletes: 4282 Category: Standards Track - -26 November 2014 + +3 December 2014 The Network Access Identifier - draft-ietf-radext-nai-11 + draft-ietf-radext-nai-12 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 identity submitted by + 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 previous document. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. @@ -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 May 29, 2015. + This Internet-Draft will expire on June 03, 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 @@ -67,63 +67,83 @@ the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Table of Contents Appendix A - Changes from RFC4282 ............................ 3 1. Introduction ............................................. 4 - 1.1. Terminology ......................................... 5 - 1.2. Requirements Language ............................... 6 - 1.3. Purpose ............................................. 7 - 1.4. Motivation .......................................... 8 -2. NAI Definition ........................................... 9 - 2.1. UTF-8 Syntax and Normalization ...................... 9 - 2.2. Formal Syntax ....................................... 10 - 2.3. NAI Length Considerations ........................... 10 - 2.4. Support for Username Privacy ........................ 11 - 2.5. International Character Sets ........................ 11 - 2.6. The Normalization Process ........................... 12 - 2.6.1. Issues with the Normalization Process .......... 13 - 2.7. Use in Other Protocols .............................. 14 - 2.8. Using the NAI format for other identifiers .......... 15 -3. Routing inside of AAA Systems ............................ 16 - 3.1. Compatibility with Email Usernames .................. 17 - 3.2. Compatibility with DNS .............................. 17 - 3.3. Realm Construction .................................. 18 - 3.3.1. Historical Practices ........................... 19 - 3.4. Examples ............................................ 19 -4. Security Considerations .................................. 20 -5. Administration of Names .................................. 21 -6. IANA Considerations ...................................... 21 -7. References ............................................... 21 - 7.1. Normative References ................................ 21 - 7.2. Informative References .............................. 22 -Appendix A - Changes from RFC4282 ............................ 25 + 1.1. Terminology ......................................... 6 + 1.2. Requirements Language ............................... 7 + 1.3. Purpose ............................................. 8 + 1.4. Motivation .......................................... 9 +2. NAI Definition ........................................... 10 + 2.1. UTF-8 Syntax and Normalization ...................... 10 + 2.2. Formal Syntax ....................................... 11 + 2.3. NAI Length Considerations ........................... 11 + 2.4. Support for Username Privacy ........................ 12 + 2.5. International Character Sets ........................ 13 + 2.6. The Normalization Process ........................... 14 + 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.2. Multiple Identifiers ................................ 23 +5. Administration of Names .................................. 24 +6. IANA Considerations ...................................... 24 +7. References ............................................... 24 + 7.1. Normative References ................................ 24 + 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. Interested parties have included the following: + other applications. + + By "inter-domain authentication", we mean situations where a user has + authentication credentials at one "home" domain, but is able to + present them at a second "visited" domain to access certain services + at the visited domain. The two domains generally have a pre-existing + relationship, so that the credentials can be passed from the visited + domain to the home domain for verification. The home domain + typically responds with a permit / deny response, which may also + include authorization parameters which the visited domain is expected + to enforce on the user. + + That is, the "roaming" scenario involves a user visiting, or + "roaming" to a non-home domain, and requesting the use of services at + that visted domain. + + Interested parties have included the following: * Regional Internet Service Providers (ISPs) operating within a particular state or province, looking to combine their efforts with those of other regional providers to offer dialup service over a wider area. - * National ISPs wishing to combine their operations with those of - one or more ISPs in another nation to offer more comprehensive - dialup service in a group of countries or on a continent. + * Telecommunications companies who wish to combine their + operations with those of one or more companies in another areas or + nations, in order to offer more comprehensive network access + service in areas where there is no native service. e.g. In + another country. * Wireless LAN hotspots providing service to one or more ISPs. * Businesses desiring to offer their employees a comprehensive package of dialup services on a global basis. Those services may include Internet access as well as secure access to corporate intranets via a VPN, enabled by tunneling protocols such as the Point-to-Point Tunneling Protocol (PPTP) [RFC2637], the Layer 2 Forwarding (L2F) protocol [RFC2341], the Layer 2 Tunneling Protocol (L2TP) [RFC2661], and the IPsec tunnel mode [RFC4301]. @@ -136,23 +156,28 @@ 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. - The alternative is to have protocol-specific identifiers, which - increases cost to both user and administrator. + 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. + + 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. @@ -164,45 +189,53 @@ 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. + 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. 1.1. Terminology This document frequently uses the following terms: "Local" or "localized" text Text which is either in non-UTF-8, or in non-normalized form. The character set, encoding, and locale are (in general) unknown to Authentication, Authorization, and Accounting (AAA) network protocols. The client which "knows" the locale may have a different concept of this text than other AAA entities, which do not know the same locale. Network Access Identifier - The Network Access Identifier (NAI) is the user identity submitted - by a client during authentication. The purpose of the NAI is to - identify the user as well as to assist in the routing of the - authentication request. Please note that the NAI may not - necessarily be the same as the user's email address or the user - identity submitted in an application layer authentication. + The Network Access Identifier (NAI) is a common format for user + identifiers submitted by a client during authentication. The + purpose of the NAI is to allow a user to be associated with an + account name, as well as to assist in the routing of the + authentication request across multiple domains. Please note that + the NAI may not necessarily be the same as the user's email + address or the user identifier submitted in an application layer + authentication. Network Access Server The Network Access Server (NAS) is the device that clients connect to in order to get access to the network. In PPTP terminology, this is referred to as the PPTP Access Concentrator (PAC), and in L2TP terminology, it is referred to as the L2TP Access Concentrator (LAC). In IEEE 802.11, it is referred to as an Access Point. @@ -235,22 +268,22 @@ 1.2. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 1.3. Purpose As described in [RFC2194], there are a number of providers offering - network access services, and the number of Internet Service Providers - involved in roaming consortia is increasing rapidly. + network access services, and essentially all Internet Service + 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. @@ -273,49 +306,51 @@ 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 simplifies deployments, as there is no need - to maintain multiple identifiers for one user. It simplifies - protocols requiring authentication, as they no longer need to specify - protocol-specific format for user identifiers. It increases - security, as it multiple identifiers allow attackers to make - contradictory claims without being detected. + 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. 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 [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) and - RADIUS, which are both 8-bit clean, and which both recommend the - use of UTF-8 for identitifiers. + 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 intermediate nodes to perform correctly without information about that language. * [RFC4282] Section 2.4 requires normalization of user names, which may conflict with local system or administrative requirements. @@ -383,24 +418,23 @@ 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 utf8-username = dot-string - dot-string = string - dot-string =/ dot-string "." string - string = utf8-atext - string =/ string utf8-atext + + dot-string = string *("." string) + string = 1*utf8-atext utf8-atext = ALPHA / DIGIT / "!" / "#" / "$" / "%" / "&" / "'" / "*" / "+" / "-" / "/" / "=" / "?" / "^" / "_" / "`" / "{" / @@ -423,58 +457,95 @@ * NAI octet length constraints may impose a more severe constraint on the number of UTF-8 characters. * NAIs are often transported in the User-Name attribute of the Remote Authentication Dial-In User Service (RADIUS) protocol. Unfortunately, RFC 2865 [RFC2865], Section 5.1, states that "the ability to handle at least 63 octets is recommended." As a result, it may not be possible to transfer NAIs beyond 63 octets through all devices. In addition, since only a single User-Name attribute may be included in a RADIUS message and the maximum - attribute length is 253 octets; RADIUS is unable to support NAI + attribute length is 253 octets, RADIUS is unable to support NAI lengths beyond 253 octets. * NAIs can also be transported in the User-Name attribute of Diameter [RFC6733], which supports content lengths up to 2^24 - 9 octets. As a result, NAIs processed only by Diameter nodes can be very long. However, an NAI transported over Diameter may eventually be translated to RADIUS, in which case the above limitations will apply. * NAIs may be transported in other protocols. Each protocol can have its own limitations on maximum NAI length. The above criteria should permit the widest use, and widest possible inter-operability of the NAI. 2.4. Support for Username Privacy Interpretation of the username part of the NAI depends on the realm in question. Therefore, the utf8-username portion SHOULD be treated as opaque data when processed by nodes that are not a part of the - authoritative domain (in the sense of Section 4) for that realm. + home domain for that realm. + + That is, the only domain which is capable of interpreting the meaning + of the utf8-username portion of the NAI is the home domain. Any + third-party domains cannot form any conclusions about the + utf8-username, and cannot decode it into sub-fields. For example, it + 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. + 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 + be used to route authentication to the home domain, and the home + domain has sufficient information to identify and authenticate users. + + However, some protocols do not support authenticate methods which + allow for "inner" and "outer" exchanges. Those protocols are limited + to using an identifier which is publicly visible. It is therefore + RECOMMENDED that such protocols use ephemeral identifiers. We + recognize that this practice is not currently used, and will likely + be difficult to implement. + + Similarly to the anonymous user, there may be situations where + portions of the realm are sensitive. For those situations, it is + RECOMMENDED that the sensitive portion of the realm also be omitted. + e.g. To use "@example.com" instead of "@sensitive.example.com", or + "anonymous@sensitive.example.com". The home domain is authoritative + for users in all subdomains, and can (if necessary) route the + authentication request to the appropriate subsystem within the home + domain. + For roaming purposes, it is typically necessary to locate the appropriate backend authentication server for the given NAI before - the authentication conversation can proceed. As a result, the realm - portion is typically required in order for the authentication - exchange to be routed to the appropriate server. + 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]. In order to ensure a canonical representation, characters of the username portion in an NAI MUST match the ABNF in this specification @@ -643,27 +714,28 @@ be used as the standard format for user identifiers. This section discusses that use in more detail. It is often useful to create new identifiers for use in specific contexts. These identifiers may have a number of different properties, most of which are unimportant to this document. For our purposes, we are interested in identifiers which need to be in a well-known format, and to have namespaces. The NAI format fits these requirements. - One example of such use is the "private user identity", which is - defined by the 3rd-Generation Partnership Project (3GPP). That - identity is used to uniquely identify the user to the network. The - identity is used for authorization, authentication, accounting, - administation, etc. The private user identity is globally unique, + One example of such use is the "private user identity", which is an + identifier defined by the 3rd-Generation Partnership Project (3GPP). + That identifier is used to uniquely identify the user to the network. + The identifier is used for authorization, authentication, accounting, + administation, etc. The "private user identity" is globally unique, and is defined by the home network operator. The format of the - identity is explicitly the NAI, as stated by Section 13.3 of [3GPP]: + identifier is explicitly the NAI, as stated by Section 13.3 of + [3GPP]: 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. @@ -687,21 +759,21 @@ 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 without modification to perform this lookup. As noted earlier, intermediate nodes may not have access to the same locale information as the system which injected the NAI into the AAA routing systems. Therefore, almost all "case insensitive" comparisons can be wrong. Where the "utf8-realm" is entirely ASCII, current AAA systems - sometimes perform case-insensitive matching on realms. This practice + sometimes perform case-insensitive matching on realms. This method MAY be continued, as it has been shown to work in practice. We also note that many existing non-AAA systems have user identifiers which are similar in format to the NAI, but which are not compliant with this specification. For example, they may use non-NFC form, or they may have multiple "@" characters in the user identifier. Intermediate nodes SHOULD normalize non-NFC identifiers to NFC, prior to looking up the "utf8-realm" in the logical routing table. Intermediate nodes MUST NOT modify the identifiers that they forward. The data as entered by the user is inviolate. @@ -908,20 +981,77 @@ in the NAI, by omitting it. As discussed in Section 2.4, this is possible only when NAIs are used together with a separate authentication method that can transfer the username in a secure manner. In some cases, application-specific privacy mechanism have also been used with NAIs. For instance, some EAP methods apply method-specific pseudonyms in the username part of the NAI [RFC3748]. While neither of these approaches can protect the realm part, their advantage over transport protection is that privacy of the username is protected, even through intermediate nodes such as NASes. +4.1. Correlation of Identities over Time and Protocols + + The recommendations in Section 2.7 and Section 2.8 for using the NAI + in other protocols has implications for privacy. Any attacker who is + capable of observing traffic containing the NAI can track the user, + and correlate his activity across time and across multiple protocols. + The authentication credentials therefore SHOULD be transported over + channels which permit private communications, or multiple identifiers + SHOULD be used, so that user tracking is impossible. + + It is RECOMMENDED that user privacy be enhanced by configuring + multiple identifiers for one user. These identifiers can be changed + over time, in order to make user tracking more difficult for a + malicous observer. However, we recognise that provisioning and + management of the identifiers may be difficult in to do in practice, + which is likely why multiple identifiers are rarely used today. + +4.2. Multiple Identifiers + + Section 1.3 states that multiple identifier formats allow attackers + to make contradictory claims without being detected. This statement + deserves further discussion. + + Section 2.4 discussed "inner" and "outer" identifiers in the context + of TTLS [RFC5281]. A close reading of that specification shows there + is no requirement that the inner and outer identifiers be in any way + related. That is, it is perfectly valid to use "@example.com" for an + 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. + + 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 + to not even share the same character set as the "inner" identifier + used by MS-CHAP. The two identifiers are entirely independent, and + fundamentally incomparable. + + Such protocol design is NOT RECOMMENDED. + 5. Administration of Names In order to avoid creating any new administrative procedures, administration of the NAI realm namespace piggybacks on the administration of the DNS namespace. NAI realm names are required to be unique, and the rights to use a given NAI realm for roaming purposes are obtained coincident with acquiring the rights to use a particular Fully Qualified Domain Name (FQDN). Those wishing to use an NAI realm name should first acquire @@ -978,20 +1108,24 @@ 7.2. Informative References [RFC2194] Aboba, B., Lu, J., Alsop, J., Ding, J., and W. Wang, "Review of Roaming Implementations", RFC 2194, September 1997. [RFC2341] Valencia, A., Littlewood, M., and T. Kolar, "Cisco Layer Two Forwarding (Protocol) "L2F"", RFC 2341, May 1998. +[RFC2433] + Zorn G., and Cobb, S. "Microsoft PPP CHAP Extensions", RFC 2433, + October 1998. + [RFC2637] Hamzeh, K., Pall, G., Verthein, W., Taarud, J., Little, W., and G. Zorn, "Point-to-Point Tunneling Protocol", RFC 2637, July 1999. [RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G., and B. Palter, "Layer Two Tunneling Protocol "L2TP"", RFC 2661, August 1999. [RFC2865] @@ -1019,23 +1153,28 @@ 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 + (IDNA): Protocol", RFC 5891, August 2010 [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]