--- 1/draft-ietf-radext-dynamic-discovery-11.txt 2014-10-27 05:15:11.898691571 -0700 +++ 2/draft-ietf-radext-dynamic-discovery-12.txt 2014-10-27 05:15:11.958693039 -0700 @@ -1,19 +1,19 @@ RADIUS Extensions Working Group S. Winter Internet-Draft RESTENA Intended status: Experimental M. McCauley -Expires: September 4, 2014 OSC - March 03, 2014 +Expires: April 30, 2015 OSC + October 27, 2014 NAI-based Dynamic Peer Discovery for RADIUS/TLS and RADIUS/DTLS - draft-ietf-radext-dynamic-discovery-11 + draft-ietf-radext-dynamic-discovery-12 Abstract This document specifies a means to find authoritative RADIUS servers for a given realm. It is used in conjunction with either RADIUS/TLS and RADIUS/DTLS. Status of This Memo This Internet-Draft is submitted in full conformance with the @@ -22,21 +22,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months 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." - This Internet-Draft will expire on September 4, 2014. + This Internet-Draft will expire on April 30, 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 @@ -46,22 +46,22 @@ the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.3. Document Status . . . . . . . . . . . . . . . . . . . . . 4 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 - 2.1. DNS RR definition . . . . . . . . . . . . . . . . . . . . 4 - 2.1.1. S-NAPTR . . . . . . . . . . . . . . . . . . . . . . . 5 + 2.1. DNS Resource Record definition . . . . . . . . . . . . . 4 + 2.1.1. S-NAPTR . . . . . . . . . . . . . . . . . . . . . . . 4 2.1.2. SRV . . . . . . . . . . . . . . . . . . . . . . . . . 9 2.1.3. Optional name mangling . . . . . . . . . . . . . . . 9 2.2. Definition of the X.509 certificate property SubjectAltName:otherName:NAIRealm . . . . . . . . . . . . 11 3. DNS-based NAPTR/SRV Peer Discovery . . . . . . . . . . . . . 12 3.1. Applicability . . . . . . . . . . . . . . . . . . . . . . 12 3.2. Configuration Variables . . . . . . . . . . . . . . . . . 13 3.3. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . 13 3.4. Realm to RADIUS server resolution algorithm . . . . . . . 14 3.4.1. Input . . . . . . . . . . . . . . . . . . . . . . . . 14 @@ -83,21 +83,21 @@ RADIUS in all its current transport variants (RADIUS/UDP, RADIUS/TCP, RADIUS/TLS, RADIUS/DTLS) requires manual configuration of all peers (clients, servers). Where more than one administrative entity collaborates for RADIUS authentication of their respective customers (a "roaming consortium"), the Network Access Identifier (NAI) [I-D.ietf-radext-nai] is the suggested way of differentiating users between those entities; the part of a username to the right of the @ - delimiter in a NAI is called the user's "realm". Where many realms + delimiter in an NAI is called the user's "realm". Where many realms and RADIUS forwarding servers are in use, the number of realms to be forwarded and the corresponding number of servers to configure may be significant. Where new realms with new servers are added or details of existing servers change on a regular basis, maintaining a single monolithic configuration file for all these details may prove too cumbersome to be useful. Furthermore, in cases where a roaming consortium consists of independently working branches (e.g. departments, national subsidiaries), each with their own forwarding servers, and who add or @@ -157,42 +157,38 @@ The document provides a discovery mechanism for RADIUS which is very similar to the approach that is taken with the Diameter protocol [RFC6733]. As such, the basic approach (using NAPTR records in DNS domains which match NAI realms) is not of very experimental nature. However, the document offers a few choice points and extensions which go beyond the provisions for Diameter. The list of major additions/ deviations is - o a fallback mechanism using SRV records, should no matching NAPTR - records be found (not defined for Diameter) - o Provisions for determining the authority of a server to act for users of a realm (declared out of scope for Diameter) o much more in-depth guidance on DNS regarding timeouts, failure - conditions, alteration of TTLs (not considered for Diameter) + conditions, alteration of Time-To-Live (TTL) information than the + Diameter counterpart - o a partially correct routing error detection (not considered for - Diameter) + o a partially correct routing error detection during DNS lookups 2. Definitions -2.1. DNS RR definition +2.1. DNS Resource Record definition DNS definitions of RADIUS/TLS servers can be either S-NAPTR records (see [RFC3958]) or SRV records. When both are defined, the resolution algorithm prefers S-NAPTR results (see Section 3.4 below). 2.1.1. S-NAPTR - 2.1.1.1. Registration of Application Service and Protocol Tags This specification defines three S-NAPTR service tags: +-----------------+-----------------------------------------+ | Service Tag | Use | +-----------------+-----------------------------------------+ | aaa+auth | RADIUS Authentication, i.e. traffic as | | | defined in [RFC2865] | | - - - - - - - - | - - - - - - - - - - - - - - - - - - - - | @@ -203,25 +199,25 @@ | | traffic as defined in [RFC5176] | +--------------- --+-----------------------------------------+ Figure 1: List of Service Tags This specification defines two S-NAPTR protocol tags: +-----------------+-----------------------------------------+ | Protocol Tag | Use | +-----------------+-----------------------------------------+ - | radius.tls | RADIUS transported over TLS as defined | + | radius.tls.tcp | RADIUS transported over TLS as defined | | | in [RFC6614] | | - - - - - - - - | - - - - - - - - - - - - - - - - - - - - | - | radius.dtls | RADIUS transported over DTLS as defined | - | | in [I-D.ietf-radext-dtls] | + | radius.dtls.udp | RADIUS transported over DTLS as defined | + | | in [RFC7360] | +-----------------+-----------------------------------------+ Figure 2: List of Protocol Tags Note well: The S-NAPTR service and protocols are unrelated to the IANA Service Name and Transport Protocol Number registry The delimiter '.' in the protocol tags is only a separator for @@ -235,21 +231,21 @@ 2.1.1.2. Definition of Conditions for Retry/Failure RADIUS is a time-critical protocol; RADIUS clients which do not receive an answer after a configurable, but short, amount of time, will consider the request failed. Due to this, there is little leeway for extensive retries. As a general rule, only error conditions which generate an immediate response from the other end are eligible for a retry of a discovered - target. Any error condition involving time-outs, or the absence of a + target. Any error condition involving timeouts, or the absence of a reply for more than one second during the connection setup phase is to be considered a failure; the next target in the set of discovered NAPTR targets is to be tried. Note that [RFC3958] already defines that a failure to identify the server as being authoritative for the realm is always considered a failure; so even if a discovered target returns a wrong credential instantly, it is not eligible for retry. Furthermore, the contacted RADIUS/TLS server verifies during @@ -266,32 +262,32 @@ that target (as identified by IP address and port number) SHOULD be ignored from the result set of any subsequent executions of the discovery algorithm at least until the target's Effective TTL has expired or until the entity which executes the algorithm changes its TLS context to either send a new client certificate or expect a different server certificate. 2.1.1.3. Server Identification and Handshake After the algorithm in this document has been executed, a RADIUS/TLS - session as per [RFC6614] is established. Since the dynamic discover + session as per [RFC6614] is established. Since the dynamic discovery algorithm does not have provisions to establish confidential keying material between the RADIUS/TLS client (i.e. the server which executes the discovery algorithm) and the RADIUS/TLS server which was discovered, TLS-PKS ciphersuites cannot be used for in the subsequent TLS handshake. Only TLS ciphersuites using X.509 certificates can be used with this algorithm. There are numerous ways to define which certificates are acceptable for use in this context. This document defines one mandatory-to- implement mechanism which allows to verify whether the contacted host - is authoritative for a NAI realm or not. It also gives one example + is authoritative for an NAI realm or not. It also gives one example of another mechanism which is currently in wide-spread deployment, and one possible approach based on DNSSEC which is yet unimplemented. 2.1.1.3.1. Mandatory-to-implement mechanism: Trust Roots + NAIRealm Verification of authority to provide AAA services over RADIUS/TLS is a two-step process. Step 1 is the verification of certificate wellformedness and validity as per [RFC5280] and whether it was issued from a root certificate @@ -347,24 +343,24 @@ Where DNSSEC is used, the results of the algorithm can be trusted; i.e. the entity which executes the algorithm can be certain that the realm that triggered the discovery is actually served by the server that was discovered via DNS. However, this does not guarantee that the server is also authorized (i.e. a recognised member of the roaming consortium). The authorization can be sketched using DNSSEC+DANE as follows: if DANE/TLSA records of all authorized servers are put into a DNSSEC zone with a common, consortium-specific branch of the DNS tree, then - the entity executing the algorithm can retrieve TLSA RRs for the - label "realm.commonroot" and verify that the presented server - certificate during the RADIUS/TLS handshake matches the information - in the TLSA record. + the entity executing the algorithm can retrieve TLSA Resource Records + (TLSA RR) for the label "realm.commonroot" and verify that the + presented server certificate during the RADIUS/TLS handshake matches + the information in the TLSA record. Example: Realm = "example.com" Common Branch = "idp.roaming-consortium.example. label for TLSA query = "example.com.idp.roaming- consortium.example. @@ -388,21 +384,21 @@ This specification defines two SRV prefixes (i.e. two values for the "_service._proto" part of an SRV RR as per [RFC2782]): +-----------------+-----------------------------------------+ | SRV Label | Use | +-----------------+-----------------------------------------+ | _radiustls._tcp | RADIUS transported over TLS as defined | | | in [RFC6614] | | - - - - - - - - | - - - - - - - - - - - - - - - - - - - - | | _radiustls._udp | RADIUS transported over DTLS as defined | - | | in [I-D.ietf-radext-dtls] | + | | in [RFC7360] | +-----------------+-----------------------------------------+ Figure 3: List of SRV Labels Just like NAPTR records, the lookup and subsequent follow-up of SRV records may yield more than one server to contact in a prioritised list. [RFC2782] does not specify rules regarding "Definition of Conditions for Retry/Failure", nor "Server Identification and Handshake". This specification defines that the rules for these two topics as defined in Section 2.1.1.2 and Section 2.1.1.3 SHALL be @@ -423,72 +419,72 @@ associated to DNS names or special-purpose consortia where a globally valid discovery is not a use case. Such other labels require a consortium-wide agreement about the transformation from realm name to lookup label, and/or which service tag to use. Examples: a. A general-purpose RADIUS server for realm example.com might have DNS entries as follows: - example.com. IN NAPTR 50 50 "s" "aaa+auth:radius.tls" "" + example.com. IN NAPTR 50 50 "s" "aaa+auth:radius.tls.tcp" "" _radiustls._tcp.foobar.example.com. _radiustls._tcp.foobar.example.com. IN SRV 0 10 2083 radsec.example.com. b. The consortium "foo" provides roaming services for its members only. The realms used are of the form enterprise-name.example. The consortium operates a special purpose DNS server for the (private) TLD "example" which all RADIUS servers use to resolve realm names. "Company, Inc." is part of the consortium. On the consortium's DNS server, realm company.example might have the following DNS entries: - company.example IN NAPTR 50 50 "a" "aaa+auth:radius.dtls" "" - roamserv.company.example + company.example IN NAPTR 50 50 "a" "aaa+auth:radius.dtls.udp" + "" roamserv.company.example - c. The eduroam consortium uses realms based on DNS, but provides its - services to a closed community only. However, a AAA domain - participating in eduroam may also want to expose AAA services to - other, general-purpose, applications (on the same or other RADIUS - servers). Due to that, the eduroam consortium uses the service - tag "x-eduroam" for authentication purposes and eduroam RADIUS - servers use this tag to look up other eduroam servers. An - eduroam participant example.org which also provides general- - purpose AAA on a different server uses the general "aaa+auth" - tag: + c. The eduroam consortium (see [I-D.wierenga-ietf-eduroam] uses + realms based on DNS, but provides its services to a closed + community only. However, a AAA domain participating in eduroam + may also want to expose AAA services to other, general-purpose, + applications (on the same or other RADIUS servers). Due to that, + the eduroam consortium uses the service tag "x-eduroam" for + authentication purposes and eduroam RADIUS servers use this tag + to look up other eduroam servers. An eduroam participant + example.org which also provides general-purpose AAA on a + different server uses the general "aaa+auth" tag: - example.org. IN NAPTR 50 50 "s" "x-eduroam:radius.tls" "" + example.org. IN NAPTR 50 50 "s" "x-eduroam:radius.tls.tcp" "" _radiustls._tcp.eduroam.example.org. - example.org. IN NAPTR 50 50 "s" "aaa+auth:radius.tls" "" + example.org. IN NAPTR 50 50 "s" "aaa+auth:radius.tls.tcp" "" _radiustls._tcp.aaa.example.org _radiustls._tcp.eduroam.example.org. IN SRV 0 10 2083 aaa- eduroam.example.org. _radiustls._tcp.aaa.example.org. IN SRV 0 10 2083 aaa- default.example.org. 2.2. Definition of the X.509 certificate property SubjectAltName:otherName:NAIRealm This specification retrieves IP addresses and port numbers from the Domain Name System which are subsequently used to authenticate users via the RADIUS/TLS protocol. Since the Domain Name System is not necessarily trustworthy (e.g. if DNSSEC is not deployed for the queried domain name), it is important to verify that the server which was contacted is authorized to service requests for the user which triggered the discovery process. - The input to the algorithm is a NAI realm as specified in + The input to the algorithm is an NAI realm as specified in Section 3.4.1. As a consequence, the X.509 certificate of the server which is ultimately contacted for user authentication needs to be able to express that it is authorized to handle requests for that realm. Current subjectAltName fields do not semantically allow to express an NAI realm; the field subjectAltName:dNSName is syntactically a good match but would inappropriately conflate DNS names and NAI realm names. Thus, this specification defines a new subjectAltName field to hold either a single NAI realm name or a wildcard name matching a @@ -518,21 +514,21 @@ NAIRealm ::= UTF8String (SIZE (1..MAX)) The NAIRealm, if present, MUST contain an NAI realm as defined in [I-D.ietf-radext-nai]. It MAY substitute labels on the leftmost dot- separated part of the NAI with the single character "*" to indicate a wildcard match for "all labels in this part". Further features of regular expressions, such as a number of characters followed by a * to indicate a common prefix inside the part, are not permitted. - The comparison of a NAIRealm to the NAI realm as derived from user + The comparison of an NAIRealm to the NAI realm as derived from user input with this algorithm is a byte-by-byte comparison, except for the optional leftmost dot-separated part of the value whose content is a single "*" character; such labels match all strings in the same dot-separated part of the NAI realm. If at least one of the sAN:otherName:NAIRealm values matches the NAI realm, the server is considered authorized; if none matches, the server is considered unauthorized. Since multiple names and multiple name forms may occur in the subjectAltName extension, an arbitrary number of NAIRealms can be @@ -567,23 +563,23 @@ Authorization) where a RADIUS entity which acts as a forwarding server for one or more realms receives a request with a realm for which it is not authoritative, and which no explicit next hop is configured. It is only applicable for a. new user sessions, i.e. for the initial Access-Request. Subsequent messages concerning this session, for example Access- Challenges and Access-Accepts use the previously-established communication channel between client and server. - b. the first accounting ticket for a user session + b. the first accounting ticket for a user session. - c. the first RADIUS DynAuth packet for a user session + c. the first RADIUS DynAuth packet for a user session. 3.2. Configuration Variables The algorithm contains various variables for timeouts. These variables are named here and reasonable default values are provided. Implementations wishing to deviate from these defaults should make they understand the implications of changes. DNS_TIMEOUT: maximum amount of time to wait for the complete set of all DNS queries to complete: Default = 3 seconds @@ -649,24 +645,25 @@ Note well: The attribute User-Name is defined to contain UTF-8 text. In practice, the content may or may not be UTF-8. Even if UTF-8, it may or may not map to a domain name in the realm part. Implementors MUST take possible conversion error paths into consideration when parsing incoming User-Name attributes. This document describes server discovery only for well-formed realms mapping to DNS domain names in UTF-8 encoding. The result of all other possible contents of User-Name is unspecified; this includes, but is not limited to: - Usage of separators other than @ + Usage of separators other than @. - Encoding of User-Name in local encodings - UTF-8 realms which fail the conversion rules as per [RFC5891] + Encoding of User-Name in local encodings. + + UTF-8 realms which fail the conversion rules as per [RFC5891]. UTF-8 realms which end with a . ("dot") character. For the last bullet point, "trailing dot", special precautions should be taken to avoid problems when resolving servers with the algorithm below: they may resolve to a RADIUS server even if the peer RADIUS server only is configured to handle the realm without the trailing dot. If that RADIUS server again uses NAI discovery to determine the authoritative server, the server will forward the request to localhost, resulting in a tight endless loop. @@ -809,21 +806,21 @@ The host's name resolution library may need to contact outside entities to perform the name resolution (e.g. authoritative name servers for a domain), and since the NAI discovery algorithm is based on uncontrollable user input, the destination of the lookups is out of control of the server that performs NAI discovery. If such outside entities are misconfigured or unreachable, the algorithm above may need an unacceptably long time to terminate. Many RADIUS implementations time out after five seconds of delay between Request and Response. It is not useful to wait until the host name - resolution library signals a time-out of its name resolution + resolution library signals a timeout of its name resolution algorithms. The algorithm therefore control execution time with TIMER. Execution of the NAI discovery algorithm SHOULD be non- blocking (i.e. allow other requests to be processed in parallel to the execution of the algorithm). 3.4.6. Example Assume a user from the Technical University of Munich, Germany, has a @@ -843,21 +840,22 @@ DNS_TIMEOUT = 3 seconds MIN_EFF_TTL = 60 seconds BACKOFF_TIME = 3600 seconds If DNS contains the following records: xn--tu-mnchen-t9a.example. IN NAPTR 50 50 "s" - "aaa+auth:radius.tls" "" _myradius._tcp.xn--tu-mnchen-t9a.example. + "aaa+auth:radius.tls.tcp" "" _myradius._tcp.xn--tu-mnchen- + t9a.example. xn--tu-mnchen-t9a.example. IN NAPTR 50 50 "s" "fooservice:bar.dccp" "" _abc123._def.xn--tu-mnchen-t9a.example. _myradius._tcp.xn--tu-mnchen-t9a.example. IN SRV 0 10 2083 radsecserver.xn--tu-mnchen-t9a.example. _myradius._tcp.xn--tu-mnchen-t9a.example. IN SRV 0 20 2083 backupserver.xn--tu-mnchen-t9a.example. @@ -877,29 +875,29 @@ 2. R = "tu-m[U+00FC]nchen.example" 3. NOOP 4. name resolution library converts R to xn--tu-mnchen-t9a.example 5. TIMER starts. 6. Result: - (TTL = 47) 50 50 "s" "aaa+auth:radius.tls" "" + (TTL = 47) 50 50 "s" "aaa+auth:radius.tls.tcp" "" _myradius._tcp.xn--tu-mnchen-t9a.example. (TTL = 522) 50 50 "s" "fooservice:bar.dccp" "" _abc123._def.xn--tu-mnchen-t9a.example. 7. Result: - (TTL = 47) 50 50 "s" "aaa+auth:radius.tls" "" + (TTL = 47) 50 50 "s" "aaa+auth:radius.tls.tcp" "" _myradius._tcp.xn--tu-mnchen-t9a.example. 8. NOOP 9. Successive resolution performs SRV query for label _myradius._tcp.xn--tu-mnchen-t9a.example, which results in (TTL 499) 0 10 2083 radsec.xn--tu-mnchen-t9a.example. (TTL 2200) 0 20 2083 backup.xn--tu-mnchen-t9a.example. @@ -969,21 +967,21 @@ 5. Security Considerations When using DNS without DNSSEC security extensions and validation for all of the replies to NAPTR, SRV and A/AAAA requests as described in section Section 3, the result O can not be trusted. Even if it can be trusted (i.e. DNSSEC is in use), actual authorization of the discovered server to provide service for the given realm needs to be verified. A mechanism from section Section 2.1.1.3 or equivalent MUST be used to verify authorization. - The algorithm has a configurable completion time-out DNS_TIMEOUT + The algorithm has a configurable completion timeout DNS_TIMEOUT defaulting to three seconds for RADIUS' operational reasons. The lookup of DNS resource records based on unverified user input is an attack vector for DoS attacks: an attacker might intentionally craft bogus DNS zones which take a very long time to reply (e.g. due to a particularly byzantine tree structure, or artificial delays in responses). To mitigate this DoS vector, implementations SHOULD consider rate- limiting either their amount of new executions of the dynamic discovery algorithm as a whole, or the amount of intermediate @@ -1099,23 +1097,23 @@ o S-NAPTR Application Service Tags registry * aaa+auth * aaa+acct * aaa+dynauth o S-NAPTR Application Protocol Tags registry - * radius.tls + * radius.tls.tcp - * radius.dtls + * radius.dtls.udp This document reserves the use of the "radiustls" and "radiusdtls" service names. Registration information as per [RFC6335] section 8.1.1 is as follows: Service Name: radiustls; radiusdtls Transport Protocols: TCP, UDP Assignee: IESG @@ -1124,30 +1122,29 @@ Description: Authentication, Accounting and Dynamic authorization via the RADIUS protocol. These service names are used to construct the SRV service labels "_radiustls" and "_radiusdtls" for discovery of RADIUS/TLS and RADIUS/DTLS servers, respectively. Reference: RFC Editor Note: please insert the RFC number of this document. The protocol does not use broadcast, multicast or anycast communication. - This document requests the creation of a new IANA registry named - "RADIUS/TLS SRV Protocol Registry" with the following initial - entries: - - o _tcp + This specification makes use of the SRV Protocol identifiers "_tcp" + and "_udp" which are mentioned as early as [RFC2782] but do not + appear to be assigned in an actual registry. Since they are in wide- + spread use in other protocols, this specification refrains from + requesting a new registry "RADIUS/TLS SRV Protocol Registry" and + continues to make use of these tags implicitly. - o _udp This document requires that a number of Object Identifiers be - assigned. They re now under the control of IANA following [I-D - .housley-pkix-oids]. + assigned. They are now under the control of IANA following [RFC7299] IANA is requested to assign the following identifiers: TBD99 is to be assigned from the "SMI Security for PKIX Module Identifier Registry". The suggested description is id-mod-nai- realm-08. TBD98 is to be assigned from the "SMI Security for PKIX Other Name Forms Registry." The suggested description is id-on-nai. @@ -1188,47 +1185,54 @@ Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008. [RFC5580] Tschofenig, H., Adrangi, F., Jones, M., Lior, A., and B. Aboba, "Carrying Location Objects in RADIUS and Diameter", RFC 5580, August 2009. [RFC5891] Klensin, J., "Internationalized Domain Names in Applications (IDNA): Protocol", RFC 5891, August 2010. - [I-D.ietf-radext-dtls] - DeKok, A., "DTLS as a Transport Layer for RADIUS", draft- - ietf-radext-dtls-07 (work in progress), October 2013. - [RFC6614] Winter, S., McCauley, M., Venaas, S., and K. Wierenga, "Transport Layer Security (TLS) Encryption for RADIUS", RFC 6614, May 2012. + [RFC7360] DeKok, A., "Datagram Transport Layer Security (DTLS) as a + Transport Layer for RADIUS", RFC 7360, September 2014. + [I-D.ietf-radext-nai] DeKok, A., "The Network Access Identifier", draft-ietf- - radext-nai-05 (work in progress), November 2013. + radext-nai-08 (work in progress), September 2014. 8.2. Informative References [RFC4017] Stanley, D., Walker, J., and B. Aboba, "Extensible Authentication Protocol (EAP) Method Requirements for Wireless LANs", RFC 4017, March 2005. [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. Cheshire, "Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry", BCP 165, RFC 6335, August 2011. [RFC6733] Fajardo, V., Arkko, J., Loughney, J., and G. Zorn, "Diameter Base Protocol", RFC 6733, October 2012. + [RFC7299] Housley, R., "Object Identifier Registry for the PKIX + Working Group", RFC 7299, July 2014. + + [I-D.wierenga-ietf-eduroam] + Wierenga, K., Winter, S., and T. Wolniewicz, "The eduroam + architecture for network roaming", draft-wierenga-ietf- + eduroam-04 (work in progress), August 2014. + Appendix A. Appendix A: ASN.1 Syntax of NAIRealm PKIXNaiRealm08 {iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-nai-realm-08 (TBD99) } DEFINITIONS EXPLICIT TAGS ::= BEGIN