--- 1/draft-ietf-radext-dynamic-discovery-12.txt 2015-03-06 01:14:43.855176033 -0800 +++ 2/draft-ietf-radext-dynamic-discovery-13.txt 2015-03-06 01:14:43.919177584 -0800 @@ -1,19 +1,19 @@ RADIUS Extensions Working Group S. Winter Internet-Draft RESTENA Intended status: Experimental M. McCauley -Expires: April 30, 2015 OSC - October 27, 2014 +Expires: September 7, 2015 AirSpayce + March 06, 2015 NAI-based Dynamic Peer Discovery for RADIUS/TLS and RADIUS/DTLS - draft-ietf-radext-dynamic-discovery-12 + draft-ietf-radext-dynamic-discovery-13 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,69 +22,69 @@ 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 April 30, 2015. + This Internet-Draft will expire on September 7, 2015. Copyright Notice - Copyright (c) 2014 IETF Trust and the persons identified as the + 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 - 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 - 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 - 1.3. Document Status . . . . . . . . . . . . . . . . . . . . . 4 - 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 - 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 + 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 . . . . . . . . . . . . . . . . . . . . . . . . . 11 + 2.1.3. Optional name mangling . . . . . . . . . . . . . . . 12 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 - 3.4.2. Output . . . . . . . . . . . . . . . . . . . . . . . 15 - 3.4.3. Algorithm . . . . . . . . . . . . . . . . . . . . . . 15 - 3.4.4. Validity of results . . . . . . . . . . . . . . . . . 17 - 3.4.5. Delay considerations . . . . . . . . . . . . . . . . 18 - 3.4.6. Example . . . . . . . . . . . . . . . . . . . . . . . 18 - 4. Operations and Manageability Considerations . . . . . . . . . 20 - 5. Security Considerations . . . . . . . . . . . . . . . . . . . 21 - 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 22 - 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 - 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 - 8.1. Normative References . . . . . . . . . . . . . . . . . . 25 - 8.2. Informative References . . . . . . . . . . . . . . . . . 26 - Appendix A. Appendix A: ASN.1 Syntax of NAIRealm . . . . . . . . 27 + SubjectAltName:otherName:NAIRealm . . . . . . . . . . . . 13 + 3. DNS-based NAPTR/SRV Peer Discovery . . . . . . . . . . . . . 15 + 3.1. Applicability . . . . . . . . . . . . . . . . . . . . . . 15 + 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 . . . . . . . . . . . . . . . . . 19 + 3.4.5. Delay considerations . . . . . . . . . . . . . . . . 20 + 3.4.6. Example . . . . . . . . . . . . . . . . . . . . . . . 21 + 4. Operations and Manageability Considerations . . . . . . . . . 23 + 5. Security Considerations . . . . . . . . . . . . . . . . . . . 24 + 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 25 + 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 + 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 + 8.1. Normative References . . . . . . . . . . . . . . . . . . 28 + 8.2. Informative References . . . . . . . . . . . . . . . . . 29 + Appendix A. Appendix A: ASN.1 Syntax of NAIRealm . . . . . . . . 30 1. Introduction 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) @@ -97,24 +97,103 @@ 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 change their realm lists at their own discretion, there is additional complexity in synchronising the changed data across all branches. - 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. + Where realms can be partitioned (e.g. according to their top-level + domain ending), forwarding of requests can be realised with a + hierarchy of RADIUS servers, all serving their partition of the realm + space. Figure 1 show an example of this hierarchical routing. + + +-------+ + | | + | . | + | | + +---+---+ + / | \ + +----------------/ | \---------------------+ + | | | + | | | + | | | + +--+---+ +--+--+ +----+---+ + | | | | | | + | .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 are organised along country borders, but + generic top-level domains such as .edu do not map to this choice of + boundaries (see [I-D.wierenga-ietf-eduroam] 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 realised without a + static hierarchy such as in the following figure: + + --------- + / \ + --------- ------------ + / \ + | 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 which was retrieved from DNS was from an authorised party; e.g. an organisation which 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 @@ -150,45 +229,48 @@ 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 NAPTR records in DNS - domains which match NAI realms) is not of very experimental nature. + [RFC6733]. As such, the basic approach (using Naming Authority + Pointer (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 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 Time-To-Live (TTL) information than the Diameter counterpart o a partially correct routing error detection during DNS lookups 2. Definitions -2.1. DNS Resource Record definition +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). + (see [RFC3958]) or Service Record (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] | | - - - - - - - - | - - - - - - - - - - - - - - - - - - - - | @@ -192,35 +274,35 @@ | 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 Authorisation, i.e. | | | traffic as defined in [RFC5176] | +-----------------+-----------------------------------------+ - Figure 1: List of Service Tags + 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 2: List of Protocol Tags + Figure 4: 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 human reading convenience - not for structure or namespacing; it MUST NOT be parsed in any way by the querying application or resolver. @@ -277,20 +359,35 @@ 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 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. + For the approaches which 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 which + is independent from default "browser" trust stores. Often, this will + be one or few 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 which operate outside the + control of the roaming consortium, for their issuance of certificates + with the properties important for authorisation (such as NAIRealm and + policyOID below) is difficult to verify. Therefore, clients SHOULD + NOT be pre-configured 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 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 which is deemed trustworthy by the RADIUS/TLS client. Step 2 is to compare the value of algorithm's variable "R" after the @@ -387,21 +484,21 @@ +-----------------+-----------------------------------------+ | SRV Label | Use | +-----------------+-----------------------------------------+ | _radiustls._tcp | RADIUS transported over TLS as defined | | | in [RFC6614] | | - - - - - - - - | - - - - - - - - - - - - - - - - - - - - | | _radiustls._udp | RADIUS transported over DTLS as defined | | | in [RFC7360] | +-----------------+-----------------------------------------+ - Figure 3: List of SRV Labels + 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 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 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). @@ -542,21 +639,21 @@ | 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 4: Examples for NAI realm vs. certificate matching + Figure 6: Examples for NAI realm vs. certificate matching Appendix A contains the ASN.1 definition of the above objects. 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 @@ -751,39 +849,43 @@ 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, Terminate. 3.4.4. Validity of results The dynamic discovery algorithm is used by servers which 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 this will - either lead to a tight loop (if that DNS entry has topmost priority, - the server would forward the request to itself, triggering dynamic - discovery again in a perpetual loop), or lead to 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 recognise - 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: other reasons include the possiblity that a subsequent - hop has a statically configured next-hop which leads to an earlier - host in the loop; or the algorithm execution was executed with greedy - result evaluation, and the own address was in a lower-priority branch - of the result set which was not retrieved from DNS at all. + 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 priorty, 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 recognise 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 which might introduce a + loop include the possiblity that a subsequent hop has a statically + configured next-hop which leads to an earlier host in the loop. + Another reason for occuring loops is if the algorithm was executed + with greedy result evaluation, and the own address was in a lower- + priority branch of the result set which 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 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 @@ -807,21 +909,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 timeout of its name resolution - algorithms. The algorithm therefore control execution time with + 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". @@ -1194,21 +1294,21 @@ [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-08 (work in progress), September 2014. + radext-nai-15 (work in progress), December 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 @@ -1275,19 +1375,18 @@ 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 - Open Systems Consultants + AirSpayce Pty Ltd 9 Bulbul Place Currumbin Waters QLD 4223 AUSTRALIA Phone: +61 7 5598 7474 - Fax: +61 7 5598 7070 - EMail: mikem@open.com.au - URI: http://www.open.com.au. + EMail: mikem@airspayce.com + URI: http://www.airspayce.com