diff options
Diffstat (limited to 'doc/rfc/rfc7585.txt')
| -rw-r--r-- | doc/rfc/rfc7585.txt | 1795 |
1 files changed, 1795 insertions, 0 deletions
diff --git a/doc/rfc/rfc7585.txt b/doc/rfc/rfc7585.txt new file mode 100644 index 0000000..c8641be --- /dev/null +++ b/doc/rfc/rfc7585.txt @@ -0,0 +1,1795 @@ + + + + + + +Internet Engineering Task Force (IETF) S. Winter +Request for Comments: 7585 RESTENA +Category: Experimental M. McCauley +ISSN: 2070-1721 AirSpayce + October 2015 + + + Dynamic Peer Discovery for RADIUS/TLS and RADIUS/DTLS + Based on the Network Access Identifier (NAI) + +Abstract + + This document specifies a means to find authoritative RADIUS servers + for a given realm. It is used in conjunction with either RADIUS over + Transport Layer Security (RADIUS/TLS) or RADIUS over Datagram + Transport Layer Security (RADIUS/DTLS). + +Status of This Memo + + This document is not an Internet Standards Track specification; it is + published for examination, experimental implementation, and + evaluation. + + This document defines an Experimental Protocol for the Internet + community. This document is a product of the Internet Engineering + Task Force (IETF). It represents the consensus of the IETF + community. It has received public review and has been approved for + publication by the Internet Engineering Steering Group (IESG). Not + all documents approved by the IESG are a candidate for any level of + Internet Standard; see Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc7585. + + + + + + + + + + + + + + + + + +Winter & McCauley Experimental [Page 1] + +RFC 7585 RADIUS Peer Discovery October 2015 + + +Copyright Notice + + Copyright (c) 2015 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 + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 + 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5 + 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 + 1.3. Document Status . . . . . . . . . . . . . . . . . . . . . 6 + 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 7 + 2.1. DNS Resource Record (RR) Definition . . . . . . . . . . . 7 + 2.1.1. S-NAPTR . . . . . . . . . . . . . . . . . . . . . . . 7 + 2.1.2. SRV . . . . . . . . . . . . . . . . . . . . . . . . . 12 + 2.1.3. Optional Name Mangling . . . . . . . . . . . . . . . 12 + 2.2. Definition of the X.509 Certificate Property + SubjectAltName:otherName:NAIRealm . . . . . . . . . . . . 14 + 3. DNS-Based NAPTR/SRV Peer Discovery . . . . . . . . . . . . . 16 + 3.1. Applicability . . . . . . . . . . . . . . . . . . . . . . 16 + 3.2. Configuration Variables . . . . . . . . . . . . . . . . . 16 + 3.3. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . 16 + 3.4. Realm to RADIUS Server Resolution Algorithm . . . . . . . 17 + 3.4.1. Input . . . . . . . . . . . . . . . . . . . . . . . . 17 + 3.4.2. Output . . . . . . . . . . . . . . . . . . . . . . . 18 + 3.4.3. Algorithm . . . . . . . . . . . . . . . . . . . . . . 18 + 3.4.4. Validity of Results . . . . . . . . . . . . . . . . . 20 + 3.4.5. Delay Considerations . . . . . . . . . . . . . . . . 21 + 3.4.6. Example . . . . . . . . . . . . . . . . . . . . . . . 21 + 4. Operations and Manageability Considerations . . . . . . . . . 24 + 5. Security Considerations . . . . . . . . . . . . . . . . . . . 25 + 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 26 + 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 + 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 + 8.1. Normative References . . . . . . . . . . . . . . . . . . 29 + 8.2. Informative References . . . . . . . . . . . . . . . . . 30 + Appendix A. ASN.1 Syntax of NAIRealm . . . . . . . . . . . . . . 31 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32 + + + +Winter & McCauley Experimental [Page 2] + +RFC 7585 RADIUS Peer Discovery October 2015 + + +1. Introduction + + RADIUS in all its current transport variants (RADIUS/UDP, RADIUS/TCP, + RADIUS/TLS, and RADIUS/DTLS) requires manual configuration of all + peers (clients and servers). + + Where more than one administrative entity collaborates for RADIUS + authentication of their respective customers (a "roaming + consortium"), the Network Access Identifier (NAI) [RFC7542] is the + suggested way of differentiating users between those entities; the + part of a username to the right of the "@" 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 and national + subsidiaries), each with their own forwarding servers, and who add or + change their realm lists at their own discretion, there is additional + complexity in synchronizing the changed data across all branches. + + Where realms can be partitioned (e.g., according to their top-level + domain (TLD) ending), forwarding of requests can be realized with a + hierarchy of RADIUS servers, all serving their partition of the realm + space. Figure 1 shows an example of this hierarchical routing. + + + + + + + + + + + + + + + + + + + + + + +Winter & McCauley Experimental [Page 3] + +RFC 7585 RADIUS Peer Discovery October 2015 + + + +-------+ + | | + | . | + | | + +---+---+ + / | \ + +----------------/ | \---------------------+ + | | | + | | | + | | | + +--+---+ +--+--+ +----+---+ + | | | | | | + | .edu | . . . | .nl | . . . | .ac.uk | + | | | | | | + +--+---+ +--+--+ +----+---+ + / | \ | \ | + / | \ | \ | + / | \ | \ | + +-----+ | +-----+ | +------+ | + | | | | | | + | | | | | | + +---+---+ +----+---+ +----+---+ +--+---+ +-----+----+ +-----+-----+ + | | | | | | | | | | | | + |utk.edu| |utah.edu| |case.edu| |hva.nl| |surfnet.nl| |soton.ac.uk| + | | | | | | | | | | | | + +----+--+ +--------+ +--------+ +------+ +----+-----+ +-----------+ + | | + | | + +--+--+ +--+--+ + | | | | + +-+-----+-+ | | + | | +-----+ + +---------+ + user: paul@surfnet.nl surfnet.nl Authentication server + + Figure 1: RADIUS Hierarchy Based on Top-Level Domain Partitioning + + However, such partitioning is not always possible. As an example, in + one real-life deployment, the administrative boundaries and RADIUS + forwarding servers are organized along country borders, but generic + top-level domains such as .edu do not map to this choice of + boundaries (see [RFC7593] for details). These situations can benefit + significantly from a distributed mechanism for storing realm and + server reachability information. This document describes one such + mechanism: storage of realm-to-server mappings in DNS; realm-based + request forwarding can then be realized without a static hierarchy + such as in the following figure: + + + + +Winter & McCauley Experimental [Page 4] + +RFC 7585 RADIUS Peer Discovery October 2015 + + + --------- + / \ + --------- ------------ + / \ + | DNS - + ----------| \ + / \ surfnet.nl NAPTR? | + (1) / ---- -> radius.surfnet.nl / + / \ / + / -------- --------- + / \---------/ + | + | --------------------------------------- + | / (2) RADIUS \ + | | | + +---+---+ +----+---+ +----+---+ +--+---+ +-----+----+ +-----+-----+ + | | | | | | | | | | | | + |utk.edu| |utah.edu| |case.edu| |hva.nl| |surfnet.nl| |soton.ac.uk| + | | | | | | | | | | | | + +----+--+ +--------+ +--------+ +------+ +----+-----+ +-----------+ + | | + | | + +--+--+ +--+--+ + | | | | + +-+-----+-+ | | + | | +-----+ + +---------+ + user: paul@surfnet.nl surfnet.nl Authentication server + + Figure 2: RADIUS Hierarchy Based on Top-Level Domain Partitioning + + This document also specifies various approaches for verifying that + server information that was retrieved from DNS was from an authorized + party; for example, an organization that is not at all part of a + given roaming consortium may alter its own DNS records to yield a + result for its own realm. + +1.1. Requirements Language + + In this document, several words are used to signify the requirements + of the specification. The key words "MUST", "MUST NOT", "REQUIRED", + "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", + and "OPTIONAL" in this document are to be interpreted as described in + RFC 2119 [RFC2119]. + + + + + + + +Winter & McCauley Experimental [Page 5] + +RFC 7585 RADIUS Peer Discovery October 2015 + + +1.2. Terminology + + RADIUS/TLS Client: a RADIUS/TLS [RFC6614] instance that initiates a + new connection. + + RADIUS/TLS Server: a RADIUS/TLS [RFC6614] instance that listens on a + RADIUS/TLS port and accepts new connections. + + RADIUS/TLS Node: a RADIUS/TLS client or server. + + [RFC7542] defines the terms NAI, realm, and consortium. + +1.3. Document Status + + This document is an Experimental RFC. + + The communities expected to use this document are roaming consortia + whose authentication services are based on the RADIUS protocol. + + The duration of the experiment is undetermined; as soon as enough + experience is collected on the choice points mentioned below, it is + expected to be obsoleted by a Standards Track version of the + protocol, which trims down the choice points. + + If that removal of choice points obsoletes tags or service names as + defined in this document and allocated by IANA, these items will be + returned to IANA as per the provisions in [RFC6335]. + + 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 Naming Authority + Pointer (NAPTR) records in DNS domains that match NAI realms) is not + of a very experimental nature. + + However, the document offers a few choice points and extensions that + go beyond the provisions for Diameter. The list of major additions/ + deviations is + + 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, and alteration of Time-To-Live (TTL) information than + the Diameter counterpart + + o a partially correct routing error detection during DNS lookups + + + + + +Winter & McCauley Experimental [Page 6] + +RFC 7585 RADIUS Peer Discovery October 2015 + + +2. Definitions + +2.1. DNS Resource Record (RR) 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] | + | - - - - - - - - | - - - - - - - - - - - - - - - - - - - - | + | aaa+acct | RADIUS Accounting, i.e., traffic as | + | | defined in [RFC2866] | + | - - - - - - - - | - - - - - - - - - - - - - - - - - - - - | + | aaa+dynauth | RADIUS Dynamic Authorization, i.e., | + | | traffic as defined in [RFC5176] | + +-----------------+-----------------------------------------+ + + Figure 3: List of Service Tags + + This specification defines two S-NAPTR protocol tags: + + +-----------------+-----------------------------------------+ + | Protocol Tag | Use | + +-----------------+-----------------------------------------+ + | radius.tls.tcp | RADIUS transported over TLS as defined | + | | in [RFC6614] | + | - - - - - - - - | - - - - - - - - - - - - - - - - - - - - | + | radius.dtls.udp | RADIUS transported over DTLS as defined | + | | in [RFC7360] | + +-----------------+-----------------------------------------+ + + Figure 4: List of Protocol Tags + + Note well: + + The S-NAPTR service and protocols are unrelated to the IANA + "Service Name and Transport Protocol Port Number Registry". + + + + +Winter & McCauley Experimental [Page 7] + +RFC 7585 RADIUS Peer Discovery October 2015 + + + The delimiter "." in the protocol tags is only a separator for + human reading convenience -- not for structure or namespacing; it + MUST NOT be parsed in any way by the querying application or + resolver. + + The use of the separator "." is common also in other protocols' + protocol tags. This is coincidence and does not imply a shared + semantics with such protocols. + +2.1.1.2. Definition of Conditions for Retry/Failure + + RADIUS is a time-critical protocol; RADIUS clients that 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 that generate an immediate + response from the other end are eligible for a retry of a discovered + 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 + connection setup whether or not it finds the connecting RADIUS/TLS + client authorized. If the connecting RADIUS/TLS client is not found + acceptable, the server will close the TLS connection immediately with + an appropriate alert. Such TLS handshake failures are permanently + fatal and not eligible for retry, unless the connecting client has + more X.509 certificates to try; in this case, a retry with the + remainder of its set of certificates SHOULD be attempted. Not trying + all available client certificates potentially creates a DoS for the + end user whose authentication attempt triggered the discovery; one of + the neglected certificates might have led to a successful RADIUS + connection and subsequent end-user authentication. + + If the TLS session setup to a discovered target does not succeed, + that target (as identified by the 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 (see + Section 3.3) has expired or until the entity that executes the + algorithm changes its TLS context to either send a new client + certificate or expect a different server certificate. + + + +Winter & McCauley Experimental [Page 8] + +RFC 7585 RADIUS Peer Discovery October 2015 + + +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 discovery + algorithm does not have provisions to establish confidential keying + material between the RADIUS/TLS client (i.e., the server that + executes the discovery algorithm) and the RADIUS/TLS server that was + discovered, Pre-Shared Key (PSK) ciphersuites for TLS cannot be used + 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 that allows verification of whether the contacted + host is authoritative for an NAI realm or not. It also gives one + example of another mechanism that is currently in widespread + deployment and one possible approach based on DNSSEC, which is yet + unimplemented. + + For the approaches that use trust roots (see the following two + sections), a typical deployment will use a dedicated trust store for + RADIUS/TLS certificate authorities, particularly a trust store that + is independent from default "browser" trust stores. Often, this will + be one or a few Certification Authorities (CAs), and they only issue + certificates for the specific purpose of establishing RADIUS server- + to-server trust. It is important not to trust a large set of CAs + that operate outside the control of the roaming consortium, since + their issuance of certificates with the properties important for + authorization (such as NAIRealm and policyOID below) is difficult to + verify. Therefore, clients SHOULD NOT be preconfigured with a list + of known public CAs by the vendor or manufacturer. Instead, the + clients SHOULD start off with an empty CA list. The addition of a CA + SHOULD be done only when manually configured by an administrator. + +2.1.1.3.1. Mandatory-to-Implement Mechanism: Trust Roots + NAIRealm + + Verification of authority to provide Authentication, Authorization, + and Accounting (AAA) services over RADIUS/TLS is a two-step process. + + Step 1 is the verification of certificate well-formedness and + validity as per [RFC5280] and whether it was issued from a root + certificate that is deemed trustworthy by the RADIUS/TLS client. + + Step 2 is to compare the value of the algorithm's variable "R" after + the execution of step 3 of the discovery algorithm in Section 3.4.3 + below (i.e., after a consortium name mangling but before conversion + to a form usable by the name resolution library) to all values of the + + + + +Winter & McCauley Experimental [Page 9] + +RFC 7585 RADIUS Peer Discovery October 2015 + + + contacted RADIUS/TLS server's X.509 certificate property + "subjectAlternativeName:otherName:NAIRealm" as defined in + Section 2.2. + +2.1.1.3.2. Other Mechanism: Trust Roots + policyOID + + Verification of authority to provide AAA services over RADIUS/TLS is + a two-step process. + + Step 1 is the verification of certificate well-formedness and + validity as per [RFC5280] and whether it was issued from a root + certificate that is deemed trustworthy by the RADIUS/TLS client. + + Step 2 is to compare the values of the contacted RADIUS/TLS server's + X.509 certificate's extensions of type "Policy OID" to a list of + configured acceptable Policy OIDs for the roaming consortium. If one + of the configured OIDs is found in the certificate's Policy OID + extensions, then the server is considered authorized; if there is no + match, the server is considered unauthorized. + + This mechanism is inferior to the mandatory-to-implement mechanism in + the previous section because all authorized servers are validated by + the same OID value; the mechanism is not fine grained enough to + express authority for one specific realm inside the consortium. If + the consortium contains members that are hostile against other + members, this weakness can be exploited by one RADIUS/TLS server + impersonating another if DNS responses can be spoofed by the hostile + member. + + The shortcomings in server identification can be partially mitigated + by using the RADIUS infrastructure only with authentication payloads + that provide mutual authentication and credential protection (i.e., + Extensible Authentication Protocol (EAP) types passing the criteria + of [RFC4017]): using mutual authentication prevents the hostile + server from mimicking the real EAP server (it can't terminate the EAP + authentication unnoticed because it does not have the server + certificate from the real EAP server); protection of credentials + prevents the impersonating server from learning usernames and + passwords of the ongoing EAP conversation (other RADIUS attributes + pertaining to the authentication, such as the EAP peer's Calling- + Station-ID, can still be learned though). + +2.1.1.3.3. Other Mechanism: DNSSEC/DANE + + Where DNSSEC is used, the results of the algorithm can be trusted; + that is, the entity that 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 + + + +Winter & McCauley Experimental [Page 10] + +RFC 7585 RADIUS Peer Discovery October 2015 + + + that the server is also authorized (i.e., a recognized member of the + roaming consortium). The server still needs to present an X.509 + certificate proving its authority to serve a particular realm. + + The authorization can be sketched using DNSSEC and DNS-Based + Authentication of Named Entities (DANE) as follows: DANE/TLSA records + of all authorized servers are put into a DNSSEC zone that contains + all known and authorized realms; the zone is rooted in a common, + consortium-agreed branch of the DNS tree. The entity executing the + algorithm uses the realm information from the authentication attempt + and then attempts to retrieve TLSA resource records (TLSA RRs) for + the DNS label "realm.commonroot". It then verifies 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. + + result of discovery algorithm for realm "example.com" = + 192.0.2.1:2083 + + ( TLS certificate of 192.0.2.1:2083 matches TLSA RR ? "PASS" : + "FAIL" ) + +2.1.1.3.4. Client Authentication and Authorization + + Note that RADIUS/TLS connections always mutually authenticate the + RADIUS server and the RADIUS client. This specification provides an + algorithm for a RADIUS client to contact and verify authorization of + a RADIUS server only. During connection setup, the RADIUS server + also needs to verify whether it considers the connecting RADIUS + client authorized; this is outside the scope of this specification. + + + + + + + + + + + + + +Winter & McCauley Experimental [Page 11] + +RFC 7585 RADIUS Peer Discovery October 2015 + + +2.1.2. SRV + + 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] | + | - - - - - - - - - | - - - - - - - - - - - - - - - - - - - - | + | _radiusdtls._udp | RADIUS transported over DTLS as defined | + | | in [RFC7360] | + +-------------------+-----------------------------------------+ + + Figure 5: 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 prioritized + list. [RFC2782] does not specify rules regarding "Definition of + Conditions for Retry/Failure" nor "Server Identification and + Handshake". This specification states that the rules for these two + topics as defined in Sections 2.1.1.2 and 2.1.1.3 SHALL be used both + for targets retrieved via an initial NAPTR RR as well as for targets + retrieved via an initial SRV RR (i.e., in the absence of NAPTR RRs). + +2.1.3. Optional Name Mangling + + It is expected that in most cases, the SRV and/or NAPTR label used + for the records is the DNS A-label representation of the literal + realm name for which the server is the authoritative RADIUS server + (i.e., the realm name after conversion according to Section 5 of + [RFC5891]). + + However, arbitrary other labels or service tags may be used if, for + example, a roaming consortium uses realm names that are not + 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. + + + + + + + + + + + +Winter & McCauley Experimental [Page 12] + +RFC 7585 RADIUS Peer Discovery October 2015 + + + 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.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.udp" "" roamserv.company.example. + + c. The eduroam consortium (see [RFC7593]) 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 that 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.tcp" "" + _radiustls._tcp.eduroam.example.org. + + 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. + + + + + + + +Winter & McCauley Experimental [Page 13] + +RFC 7585 RADIUS Peer Discovery October 2015 + + +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 that are subsequently used to authenticate users + via the RADIUS/TLS protocol. Regardless whether the results from DNS + discovery are trustworthy or not (e.g., DNSSEC in use), it is always + important to verify that the server that was contacted is authorized + to service requests for the user that triggered the discovery + process. + + 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 + that 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 an NAI realm + to be expressed; 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 + set of NAI realms. + + The subjectAltName:otherName:sRVName field certifies that a + certificate holder is authorized to provide a service; this can be + compared to the target of a DNS label's SRV resource record. If the + Domain Name System is insecure, it is required that the label of the + SRV record itself is known-correct. In this specification, that + label is not known-correct; it is potentially derived from a + (potentially untrusted) NAPTR resource record of another label. If + DNS is not secured with DNSSEC, the NAPTR resource record may have + been altered by an attacker with access to the Domain Name System + resolution, and thus the label used to look up the SRV record may + already be tainted. This makes subjectAltName:otherName:sRVName not + a trusted comparison item. + + Further to this, this specification's NAPTR entries may be of type + "A", which does not involve resolution of any SRV records, which + again makes subjectAltName:otherName:sRVName unsuited for this + purpose. + + This section defines the NAIRealm name as a form of otherName from + the GeneralName structure in subjectAltName defined in [RFC5280]. + + + + + + + + +Winter & McCauley Experimental [Page 14] + +RFC 7585 RADIUS Peer Discovery October 2015 + + + id-on-naiRealm OBJECT IDENTIFIER ::= { id-on 8 } + + ub-naiRealm-length INTEGER ::= 255 + + NAIRealm ::= UTF8String (SIZE (1..ub-naiRealm-length)) + + The NAIRealm, if present, MUST contain an NAI realm as defined in + [RFC7542]. It MAY substitute the leftmost dot-separated label 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 an "*" to indicate a + common prefix inside the part, are not permitted. + + 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 match the NAI realm, the server is + considered authorized; if none match, 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 + specified in a certificate. + + Examples: + + +---------------------+-------------------+-----------------------+ + | NAI realm (RADIUS) | NAIRealm (cert) | MATCH? | + +---------------------+-------------------+-----------------------+ + | foo.example | foo.example | YES | + | foo.example | *.example | YES | + | bar.foo.example | *.example | NO | + | bar.foo.example | *ar.foo.example | NO (NAIRealm invalid) | + | bar.foo.example | bar.*.example | NO (NAIRealm invalid) | + | bar.foo.example | *.*.example | NO (NAIRealm invalid) | + | sub.bar.foo.example | *.*.example | NO (NAIRealm invalid) | + | sub.bar.foo.example | *.bar.foo.example | YES | + +-----------------+-----------------------------------------------+ + + Figure 6: Examples for NAI Realm vs. Certificate Matching + + Appendix A contains the ASN.1 definition of the above objects. + + + + + + + +Winter & McCauley Experimental [Page 15] + +RFC 7585 RADIUS Peer Discovery October 2015 + + +3. DNS-Based NAPTR/SRV Peer Discovery + +3.1. Applicability + + Dynamic server discovery as defined in this document is only + applicable for new AAA transactions and per service (i.e., distinct + discovery is needed for Authentication, Accounting, and Dynamic + Authorization) where a RADIUS entity that 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. + + 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 + sure 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 + + MIN_EFF_TTL: minimum DNS TTL of discovered targets: Default = 60 + seconds + + BACKOFF_TIME: if no conclusive DNS response was retrieved after + DNS_TIMEOUT, do not attempt dynamic discovery before BACKOFF_TIME + has elapsed: Default = 600 seconds + +3.3. Terms + + Positive DNS response: A response that contains the RR that was + queried for. + + Negative DNS response: A response that does not contain the RR that + was queried for but contains an SOA record along with a TTL + indicating cache duration for this negative result. + + + + + +Winter & McCauley Experimental [Page 16] + +RFC 7585 RADIUS Peer Discovery October 2015 + + + DNS Error: Where the algorithm states "name resolution returns with + an error", this shall mean that either the DNS request timed out or + it is a DNS response, which is neither a positive nor a negative + response (e.g., SERVFAIL). + + Effective TTL: The validity period for discovered RADIUS/TLS target + hosts. Calculated as: Effective TTL (set of DNS TTL values) = max { + MIN_EFF_TTL, min { DNS TTL values } } + + SRV lookup: For the purpose of this specification, SRV lookup + procedures are defined as per [RFC2782] but excluding that RFCs "A" + fallback as defined in the "Usage Rules" section, final "else" + clause. + + Greedy result evaluation: The NAPTR to SRV/A/AAAA resolution may lead + to a tree of results, whose leafs are the IP addresses to contact. + The branches of the tree are ordered according to their order/ + preference DNS properties. An implementation is executing greedy + result evaluation if it uses a depth-first search in the tree along + the highest order results, attempts to connect to the corresponding + resulting IP addresses, and only backtracks to other branches if the + higher ordered results did not end in successful connection attempts. + +3.4. Realm to RADIUS Server Resolution Algorithm + +3.4.1. Input + + For RADIUS Authentication and RADIUS Accounting server discovery, + input I to the algorithm is the RADIUS User-Name attribute with + content of the form "user@realm"; the literal "@" sign is the + separator between a local user identifier within a realm and its + realm. The use of multiple literal "@" signs in a User-Name is + strongly discouraged; but if present, the last "@" sign is to be + considered the separator. All previous instances of the "@" sign are + to be considered part of the local user identifier. + + For RADIUS DynAuth server discovery, input I to the algorithm is the + domain name of the operator of a RADIUS realm as was communicated + during user authentication using the Operator-Name attribute + ([RFC5580], Section 4.1). Only Operator-Name values with the + namespace "1" are supported by this algorithm -- the input to the + algorithm is the actual domain name, preceded with an "@" (but + without the "1" namespace identifier byte of that attribute). + + 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 + + + +Winter & McCauley Experimental [Page 17] + +RFC 7585 RADIUS Peer Discovery October 2015 + + + 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 "@". + + Encoding of User-Name in local encodings. + + UTF-8 realms that fail the conversion rules as per [RFC5891]. + + UTF-8 realms that 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. + +3.4.2. Output + + Output O of the algorithm is a two-tuple consisting of: O-1) a set of + tuples {hostname; port; protocol; order/preference; Effective TTL} -- + the set can be empty -- and O-2) an integer. If the set in the first + part of the tuple is empty, the integer contains the Effective TTL + for backoff timeout; if the set is not empty, the integer is set to 0 + (and not used). + +3.4.3. Algorithm + + The algorithm to determine the RADIUS server to contact is as + follows: + + 1. Determine P = (position of last "@" character) in I. + + 2. Generate R = (substring from P+1 to end of I). + + 3. Modify R according to agreed consortium procedures if + applicable. + + 4. Convert R to a representation usable by the name resolution + library if needed. + + 5. Initialize TIMER = 0; start TIMER. If TIMER reaches + DNS_TIMEOUT, continue at step 20. + + + + +Winter & McCauley Experimental [Page 18] + +RFC 7585 RADIUS Peer Discovery October 2015 + + + 6. Using the host's name resolution library, perform a NAPTR query + for R (see "Delay Considerations", Section 3.4.5, below). If + the result is a negative DNS response, O-2 = Effective TTL ( TTL + value of the SOA record ) and continue at step 13. If name + resolution returns with error, O-1 = { empty set }, O-2 = + BACKOFF_TIME, and terminate. + + 7. Extract NAPTR records with service tags "aaa+auth", "aaa+acct", + and "aaa+dynauth" as appropriate. Keep note of the protocol tag + and remaining TTL of each of the discovered NAPTR records. + + 8. If no records are found, continue at step 13. + + 9. For the extracted NAPTRs, perform successive resolution as + defined in [RFC3958], Section 2.2. An implementation MAY use + greedy result evaluation according to the NAPTR order/preference + fields (i.e., can execute the subsequent steps of this algorithm + for the highest-order entry in the set of results and only look + up the remainder of the set if necessary). + + 10. If the set of hostnames is empty, O-1 = { empty set }, O-2 = + BACKOFF_TIME, and terminate. + + 11. O' = (set of {hostname; port; protocol; order/preference; + Effective TTL ( all DNS TTLs that led to this hostname ) } for + all terminal lookup results). + + 12. Proceed with step 18. + + 13. Generate R' = (prefix R with "_radiustls._tcp." and/or + "_radiustls._udp."). + + 14. Using the host's name resolution library, perform SRV lookup + with R' as label (see "Delay Considerations", Section 3.4.5, + below). + + 15. If name resolution returns with error, O-1 = { empty set }, O-2 + = BACKOFF_TIME, and terminate. + + 16. If the result is a negative DNS response, O-1 = { empty set }, + O-2 = min { O-2, Effective TTL ( TTL value of the SOA record ) + }, and terminate. + + 17. O' = (set of {hostname; port; protocol; order/preference; + Effective TTL ( all DNS TTLs that led to this result ) } for all + hostnames). + + + + + +Winter & McCauley Experimental [Page 19] + +RFC 7585 RADIUS Peer Discovery October 2015 + + + 18. Generate O-1 by resolving hostnames in O' into corresponding A + and/or AAAA addresses: O-1 = (set of {IP address; port; + protocol; order/preference; Effective TTL ( all DNS TTLs that + led to this result ) } for all hostnames ), O-2 = 0. + + 19. For each element in O-1, test if the original request that + triggered dynamic discovery was received on {IP address; port}. + If yes, O-1 = { empty set }, O-2 = BACKOFF_TIME, log error, and + terminate (see next section for a rationale). If no, O is the + result of dynamic discovery; terminate. + + 20. O-1 = { empty set }, O-2 = BACKOFF_TIME, log error, and + terminate. + +3.4.4. Validity of Results + + The discovery algorithm is used by servers that do not have + sufficient configuration information to process an incoming request + on their own. If the discovery algorithm result contains the + server's own listening address (IP address and port), then there is a + potential for an endless forwarding loop. If the listening address + is the DNS result with the highest priority, the server will enter a + tight loop (the server would forward the request to itself, + triggering dynamic discovery again in a perpetual loop). If the + address has a lower priority in the set of results, there is a + potential loop with intermediate hops in between (the server could + forward to another host with a higher priority, which might use DNS + itself and forward the packet back to the first server). The + underlying reason that enables these loops is that the server + executing the discovery algorithm is seriously misconfigured in that + it does not recognize the request as one that is to be processed by + itself. RADIUS has no built-in loop detection, so any such loops + would remain undetected. So, if step 18 of the algorithm discovers + such a possible-loop situation, the algorithm should be aborted and + an error logged. Note that this safeguard does not provide perfect + protection against routing loops. One reason that might introduce a + loop includes the possibility that a subsequent hop has a statically + configured next hop that leads to an earlier host in the loop. + Another reason for occurring loops is if the algorithm was executed + with greedy result evaluation, and the server's own address was in a + lower-priority branch of the result set that was not retrieved from + DNS at all, and thus can't be detected. + + After executing the above algorithm, the RADIUS server establishes a + connection to a home server from the result set. This connection can + potentially remain open for an indefinite amount of time. This + conflicts with the possibility of changing device and network + configurations on the receiving end. Typically, TTL values for + + + +Winter & McCauley Experimental [Page 20] + +RFC 7585 RADIUS Peer Discovery October 2015 + + + records in the name resolution system are used to indicate how long + it is safe to rely on the results of the name resolution. If these + TTLs are very low, thrashing of connections becomes possible; the + Effective TTL mitigates that risk. When a connection is open and the + smallest of the Effective TTL value that was learned during + discovering the server has not expired, subsequent new user sessions + for the realm that corresponds to that open connection SHOULD reuse + the existing connection and SHOULD NOT re-execute the discovery + algorithm nor open a new connection. To allow for a change of + configuration, a RADIUS server SHOULD re-execute the discovery + algorithm after the Effective TTL that is associated with this + connection has expired. The server SHOULD keep the session open + during this reassessment to avoid closure and immediate reopening of + the connection should the result not have changed. + + Should the algorithm above terminate with O-1 = { empty set }, the + RADIUS server SHOULD NOT attempt another execution of this algorithm + for the same target realm before the timeout O-2 has passed. + +3.4.5. Delay Considerations + + 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 timeout of its name resolution + algorithms. The algorithm therefore controls 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 + RADIUS User-Name of "foobar@tu-m[U+00FC]nchen.example". + + The name resolution library on the RADIUS forwarding server does + not have the realm tu-m[U+00FC]nchen.example in its forwarding + configuration but uses DNS for name resolution and has configured + the use of dynamic discovery to discover RADIUS servers. + + + + +Winter & McCauley Experimental [Page 21] + +RFC 7585 RADIUS Peer Discovery October 2015 + + + It is IPv6 enabled and prefers AAAA records over A records. + + It is listening for incoming RADIUS/TLS requests on 192.0.2.1, + TCP/2083. + + May the configuration variables be + + 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.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. + + radsecserver.xn--tu-mnchen-t9a.example. IN AAAA + 2001:0DB8::202:44ff:fe0a:f704 + + radsecserver.xn--tu-mnchen-t9a.example. IN A 192.0.2.3 + + backupserver.xn--tu-mnchen-t9a.example. IN A 192.0.2.7 + + Then the algorithm executes as follows, with I = + "foobar@tu-m[U+00FC]nchen.example", and no consortium name mangling + in use: + + 1. P = 7 + + 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. + + + +Winter & McCauley Experimental [Page 22] + +RFC 7585 RADIUS Peer Discovery October 2015 + + + 6. Result: + + (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.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. + + 10. NOOP + + 11. O' = { + + (radsec.xn--tu-mnchen-t9a.example.; 2083; RADIUS/TLS; 10; + 60), + + (backup.xn--tu-mnchen-t9a.example.; 2083; RADIUS/TLS; 20; 60) + + } // minimum TTL is 47, upped to MIN_EFF_TTL + + 12. Continuing at 18. + + 13. (not executed) + + 14. (not executed) + + 15. (not executed) + + 16. (not executed) + + 17. (not executed) + + + + + + + +Winter & McCauley Experimental [Page 23] + +RFC 7585 RADIUS Peer Discovery October 2015 + + + 18. O-1 = { + + (2001:0DB8::202:44ff:fe0a:f704; 2083; RADIUS/TLS; 10; 60), + + (192.0.2.7; 2083; RADIUS/TLS; 20; 60) + + }; O-2 = 0 + + 19. No match with own listening address; terminate with tuple (O-1, + O-2) from previous step. + + The implementation will then attempt to connect to two servers, with + preference to [2001:0DB8::202:44ff:fe0a:f704]:2083 using the RADIUS/ + TLS protocol. + +4. Operations and Manageability Considerations + + The discovery algorithm as defined in this document contains several + options: the major ones are use of NAPTR vs. SRV; how to determine + the authorization status of a contacted server for a given realm; and + which trust anchors to consider trustworthy for the RADIUS + conversation setup. + + Random parties that do not agree on the same set of options may not + be able to interoperate. However, such a global interoperability is + not intended by this document. + + Discovery as per this document becomes important inside a roaming + consortium, which has set up roaming agreements with the other + partners. Such roaming agreements require much more than a technical + means of server discovery; there are administrative and contractual + considerations at play (service contracts, back-office compensations, + procedures, etc.). + + A roaming consortium's roaming agreement must include a profile of + which choice points in this document to use. So as long as the + roaming consortium can settle on one deployment profile, they will be + able to interoperate based on that choice; this per-consortium + interoperability is the intended scope of this document. + + + + + + + + + + + + +Winter & McCauley Experimental [Page 24] + +RFC 7585 RADIUS Peer Discovery October 2015 + + +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 3, the result of the discovery process 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 2.1.1.3 + or equivalent MUST be used to verify authorization. + + 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 that 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 the amount of new executions of the discovery + algorithm as a whole or the amount of intermediate responses to + track, or at least the number of pending DNS queries. + Implementations MAY choose lower values than the default for + DNS_TIMEOUT to limit the impact of DoS attacks via that vector. They + MAY also continue their attempt to resolve DNS records even after + DNS_TIMEOUT has passed; a subsequent request for the same realm might + benefit from retrieving the results anyway. The amount of time spent + waiting for a result will influence the impact of a possible DoS + attack; the waiting time value is implementation dependent and + outside the scope of this specification. + + With dynamic discovery being enabled for a RADIUS server, and + depending on the deployment scenario, the server may need to open up + its target IP address and port for the entire Internet because + arbitrary clients may discover it as a target for their + authentication requests. If such clients are not part of the roaming + consortium, the RADIUS/TLS connection setup phase will fail (which is + intended), but the computational cost for the connection attempt is + significant. When the port for a TLS-based service is open, the + RADIUS server shares all the typical attack vectors for services + based on TLS (such as HTTPS and SMTPS). Deployments of RADIUS/TLS + with dynamic discovery should consider these attack vectors and take + appropriate countermeasures (e.g., blacklisting known bad IPs on a + firewall, rate limiting new connection attempts, etc.). + + + + + + + +Winter & McCauley Experimental [Page 25] + +RFC 7585 RADIUS Peer Discovery October 2015 + + +6. Privacy Considerations + + The classic RADIUS operational model (known, preconfigured peers, + shared secret security, and mostly plaintext communication) and this + new RADIUS dynamic discovery model (peer discovery with DNS, PKI + security, and packet confidentiality) differ significantly in their + impact on the privacy of end users trying to authenticate to a RADIUS + server. + + With classic RADIUS, traffic in large environments gets aggregated by + statically configured clearinghouses. The packets sent to those + clearinghouses and their responses are mostly unprotected. As a + consequence, + + o All intermediate IP hops can inspect most of the packet payload in + clear text, including the User-Name and Calling-Station-Id + attributes, and can observe which client sent the packet to which + clearinghouse. This allows the creation of mobility profiles for + any passive observer on the IP path. + + o The existence of a central clearinghouse creates an opportunity + for the clearinghouse to trivially create the same mobility + profiles. The clearinghouse may or may not be trusted not to do + this, e.g., by sufficiently threatening contractual obligations. + + o In addition to that, with the clearinghouse being a RADIUS + intermediate in possession of a valid shared secret, the + clearinghouse can observe and record even the security-critical + RADIUS attributes such as User-Password. This risk may be + mitigated by choosing authentication payloads that are + cryptographically secured and do not use the attribute User- + Password -- such as certain EAP types. + + o There is no additional information disclosure to parties outside + the IP path between the RADIUS client and server (in particular, + no DNS servers learn about realms of current ongoing + authentications). + + With RADIUS and dynamic discovery, + + o This protocol allows for RADIUS clients to identify and directly + connect to the RADIUS home server. This can eliminate the use of + clearinghouses to do forwarding of requests, and it also + eliminates the ability of the clearinghouse to then aggregate the + user information that flows through it. However, there are + reasons why clearinghouses might still be used. One reason to + keep a clearinghouse is to act as a gateway for multiple backends + + + + +Winter & McCauley Experimental [Page 26] + +RFC 7585 RADIUS Peer Discovery October 2015 + + + in a company; another reason may be a requirement to sanitize + RADIUS datagrams (filter attributes, tag requests with new + attributes, etc.). + + o Even where intermediate proxies continue to be used for reasons + unrelated to dynamic discovery, the number of such intermediates + may be reduced by removing those proxies that are only deployed + for pure request routing reasons. This reduces the number of + entities that can inspect the RADIUS traffic. + + o RADIUS clients that make use of dynamic discovery will need to + query the Domain Name System and use a user's realm name as the + query label. A passive observer on the IP path between the RADIUS + client and the DNS server(s) being queried can learn that a user + of that specific realm was trying to authenticate at that RADIUS + client at a certain point in time. This may or may not be + sufficient for the passive observer to create a mobility profile. + During the recursive DNS resolution, a fair number of DNS servers + and the IP hops in between those get to learn that information. + Not every single authentication triggers DNS lookups, so there is + no one-to-one relation of leaked realm information and the number + of authentications for that realm. + + o Since dynamic discovery operates on a RADIUS hop-by-hop basis, + there is no guarantee that the RADIUS payload is not transmitted + between RADIUS systems that do not make use of this algorithm, and + they possibly use other transports such as RADIUS/UDP. On such + hops, the enhanced privacy is jeopardized. + + In summary, with classic RADIUS, few intermediate entities learn very + detailed data about every ongoing authentication, while with dynamic + discovery, many entities learn only very little about recently + authenticated realms. + +7. IANA Considerations + + Per this document, IANA has added the following entries in existing + registries: + + o S-NAPTR Application Service Tags registry + + * aaa+auth + + * aaa+acct + + * aaa+dynauth + + + + + +Winter & McCauley Experimental [Page 27] + +RFC 7585 RADIUS Peer Discovery October 2015 + + + o S-NAPTR Application Protocol Tags registry + + * radius.tls.tcp + + * radius.dtls.udp + + This document reserves the use of the "radiustls" and "radiusdtls" + service names. Registration information as per Section 8.1.1 of + [RFC6335] is as follows: + + Service Name: radiustls; radiusdtls + + Transport Protocols: TCP (for radiustls), UDP (for radiusdtls) + + Assignee: IESG <iesg@ietf.org> + + Contact: IETF Chair <chair@ietf.org> + + 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 7585 + + 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 + widespread 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. + + Per this document, a number of Object Identifiers have been assigned. + They are now under the control of IANA following [RFC7299]. + + IANA has assigned the following identifiers: + + 85 has been assigned from the "SMI Security for PKIX Module + Identifier" registry. The description is id-mod-nai-realm-08. + + 8 has been assigned from the "SMI Security for PKIX Other Name + Forms" registry. The description is id-on-naiRealm. + + + + + + + + + +Winter & McCauley Experimental [Page 28] + +RFC 7585 RADIUS Peer Discovery October 2015 + + +8. References + +8.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + <http://www.rfc-editor.org/info/rfc2119>. + + [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for + specifying the location of services (DNS SRV)", RFC 2782, + DOI 10.17487/RFC2782, February 2000, + <http://www.rfc-editor.org/info/rfc2782>. + + [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, + "Remote Authentication Dial In User Service (RADIUS)", + RFC 2865, DOI 10.17487/RFC2865, June 2000, + <http://www.rfc-editor.org/info/rfc2865>. + + [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, + DOI 10.17487/RFC2866, June 2000, + <http://www.rfc-editor.org/info/rfc2866>. + + [RFC3958] Daigle, L. and A. Newton, "Domain-Based Application + Service Location Using SRV RRs and the Dynamic Delegation + Discovery Service (DDDS)", RFC 3958, DOI 10.17487/RFC3958, + January 2005, <http://www.rfc-editor.org/info/rfc3958>. + + [RFC5176] Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B. + Aboba, "Dynamic Authorization Extensions to Remote + Authentication Dial In User Service (RADIUS)", RFC 5176, + DOI 10.17487/RFC5176, January 2008, + <http://www.rfc-editor.org/info/rfc5176>. + + [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., + Housley, R., and W. Polk, "Internet X.509 Public Key + Infrastructure Certificate and Certificate Revocation List + (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, + <http://www.rfc-editor.org/info/rfc5280>. + + [RFC5580] Tschofenig, H., Ed., Adrangi, F., Jones, M., Lior, A., and + B. Aboba, "Carrying Location Objects in RADIUS and + Diameter", RFC 5580, DOI 10.17487/RFC5580, August 2009, + <http://www.rfc-editor.org/info/rfc5580>. + + + + + + + +Winter & McCauley Experimental [Page 29] + +RFC 7585 RADIUS Peer Discovery October 2015 + + + [RFC5891] Klensin, J., "Internationalized Domain Names in + Applications (IDNA): Protocol", RFC 5891, + DOI 10.17487/RFC5891, August 2010, + <http://www.rfc-editor.org/info/rfc5891>. + + [RFC6614] Winter, S., McCauley, M., Venaas, S., and K. Wierenga, + "Transport Layer Security (TLS) Encryption for RADIUS", + RFC 6614, DOI 10.17487/RFC6614, May 2012, + <http://www.rfc-editor.org/info/rfc6614>. + + [RFC7360] DeKok, A., "Datagram Transport Layer Security (DTLS) as a + Transport Layer for RADIUS", RFC 7360, + DOI 10.17487/RFC7360, September 2014, + <http://www.rfc-editor.org/info/rfc7360>. + + [RFC7542] DeKok, A., "The Network Access Identifier", RFC 7542, + DOI 10.17487/RFC7542, May 2015, + <http://www.rfc-editor.org/info/rfc7542>. + +8.2. Informative References + + [RFC4017] Stanley, D., Walker, J., and B. Aboba, "Extensible + Authentication Protocol (EAP) Method Requirements for + Wireless LANs", RFC 4017, DOI 10.17487/RFC4017, March + 2005, <http://www.rfc-editor.org/info/rfc4017>. + + [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, DOI 10.17487/RFC6335, August 2011, + <http://www.rfc-editor.org/info/rfc6335>. + + [RFC6733] Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn, + Ed., "Diameter Base Protocol", RFC 6733, + DOI 10.17487/RFC6733, October 2012, + <http://www.rfc-editor.org/info/rfc6733>. + + [RFC7299] Housley, R., "Object Identifier Registry for the PKIX + Working Group", RFC 7299, DOI 10.17487/RFC7299, July 2014, + <http://www.rfc-editor.org/info/rfc7299>. + + [RFC7593] Wierenga, K., Winter, S., and T. Wolniewicz, "The eduroam + Architecture for Network Roaming", RFC 7593, + DOI 10.17487/RFC7593, September 2015, + <http://www.rfc-editor.org/info/rfc7593>. + + + + + +Winter & McCauley Experimental [Page 30] + +RFC 7585 RADIUS Peer Discovery October 2015 + + +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(85) } + + DEFINITIONS EXPLICIT TAGS ::= + + BEGIN + + -- EXPORTS ALL -- + + IMPORTS + + id-pkix + FROM PKIX1Explicit-2009 + {iso(1) identified-organization(3) dod(6) internet(1) + security(5) mechanisms(5) pkix(7) id-mod(0) + id-mod-pkix1-explicit-02(51)} + -- from RFCs 5280 and 5912 + + OTHER-NAME + FROM PKIX1Implicit-2009 + {iso(1) identified-organization(3) dod(6) internet(1) security(5) + mechanisms(5) pkix(7) id-mod(0) id-mod-pkix1-implicit-02(59)} + -- from RFCs 5280 and 5912 + ; + + + -- Service Name Object Identifier + + id-on OBJECT IDENTIFIER ::= { id-pkix 8 } + + id-on-naiRealm OBJECT IDENTIFIER ::= { id-on 8 } + + -- Service Name + + naiRealm OTHER-NAME ::= { NAIRealm IDENTIFIED BY { id-on-naiRealm }} + + ub-naiRealm-length INTEGER ::= 255 + + NAIRealm ::= UTF8String (SIZE (1..ub-naiRealm-length)) + + END + + + + + + + +Winter & McCauley Experimental [Page 31] + +RFC 7585 RADIUS Peer Discovery October 2015 + + +Authors' Addresses + + Stefan Winter + Fondation RESTENA + 6, rue Richard Coudenhove-Kalergi + Luxembourg 1359 + Luxembourg + + Phone: +352 424409 1 + Fax: +352 422473 + Email: stefan.winter@restena.lu + URI: http://www.restena.lu + + + Mike McCauley + AirSpayce Pty Ltd + 9 Bulbul Place + Currumbin Waters QLD 4223 + Australia + + Phone: +61 7 5598 7474 + Email: mikem@airspayce.com + URI: http://www.airspayce.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Winter & McCauley Experimental [Page 32] + |