--- 1/draft-ietf-radext-dynamic-discovery-09.txt 2014-02-14 00:14:42.578496337 -0800 +++ 2/draft-ietf-radext-dynamic-discovery-10.txt 2014-02-14 00:14:42.626497485 -0800 @@ -1,19 +1,19 @@ RADIUS Extensions Working Group S. Winter Internet-Draft RESTENA Intended status: Experimental M. McCauley -Expires: June 23, 2014 OSC - December 20, 2013 +Expires: August 18, 2014 OSC + February 14, 2014 NAI-based Dynamic Peer Discovery for RADIUS/TLS and RADIUS/DTLS - draft-ietf-radext-dynamic-discovery-09 + draft-ietf-radext-dynamic-discovery-10 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,67 +22,67 @@ 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 June 23, 2014. + This Internet-Draft will expire on August 18, 2014. Copyright Notice - Copyright (c) 2013 IETF Trust and the persons identified as the + 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 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 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. DNS RR definition . . . . . . . . . . . . . . . . . . . . 3 - 2.1.1. S-NAPTR . . . . . . . . . . . . . . . . . . . . . . . 4 + 2.1.1. S-NAPTR . . . . . . . . . . . . . . . . . . . . . . . 3 2.1.2. SRV . . . . . . . . . . . . . . . . . . . . . . . . . 8 2.1.3. Optional name mangling . . . . . . . . . . . . . . . 8 2.2. Definition of the X.509 certificate property SubjectAltName:otherName:NAIRealm . . . . . . . . . . . . 10 3. DNS-based NAPTR/SRV Peer Discovery . . . . . . . . . . . . . 11 3.1. Applicability . . . . . . . . . . . . . . . . . . . . . . 11 3.2. Configuration Variables . . . . . . . . . . . . . . . . . 12 3.3. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . 12 3.4. Realm to RADIUS server resolution algorithm . . . . . . . 13 3.4.1. Input . . . . . . . . . . . . . . . . . . . . . . . . 13 3.4.2. Output . . . . . . . . . . . . . . . . . . . . . . . 14 3.4.3. Algorithm . . . . . . . . . . . . . . . . . . . . . . 14 - 3.4.4. Validity of results . . . . . . . . . . . . . . . . . 15 + 3.4.4. Validity of results . . . . . . . . . . . . . . . . . 16 3.4.5. Delay considerations . . . . . . . . . . . . . . . . 17 3.4.6. Example . . . . . . . . . . . . . . . . . . . . . . . 17 4. Security Considerations . . . . . . . . . . . . . . . . . . . 19 - 5. Privacy Considerations . . . . . . . . . . . . . . . . . . . 21 + 5. Privacy Considerations . . . . . . . . . . . . . . . . . . . 20 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 7.1. Normative References . . . . . . . . . . . . . . . . . . 23 7.2. Informative References . . . . . . . . . . . . . . . . . 24 - Appendix A. Appendix A: ASN.1 Syntax of NAIRealm . . . . . . . . 24 + Appendix A. Appendix A: ASN.1 Syntax of NAIRealm . . . . . . . . 25 1. Introduction RADIUS in all its current transport variants (RADIUS/UDP, RADIUS/TLS, RADIUS/DTLS) requires manual configuration of all peers (clients, servers). Where 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 @@ -476,21 +476,23 @@ The comparison of a 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. - This subjectAltName MAY occur more than once in a certificate. + 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) | @@ -502,30 +504,35 @@ Figure 4: 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 AAA transactions 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 + applicable for new AAA transactions and per service (i.e. distinct + discovery is needed for Authentication, Accounting, and Dynamic + 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. RADIUS DynAuth server discovery + 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 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 @@ -611,24 +616,24 @@ 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; 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 + 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) @@ -642,61 +647,62 @@ DNS_TIMEOUT, continue at step 20. 6. Using the host's name resolution library, perform a NAPTR query for R (see "Delay considerations" 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 tag "aaa+auth", "aaa+acct", - "aaa+dynauth" as appropriate. Keep note of the remaining TTL of - each of the discovered NAPTR records. + "aaa+dynauth" as appropriate. Keep note of the protocol tag and + remaining TTL of each of the discovered NAPTR records. 8. If no records 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 lookup 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; order/preference; Effective TTL ( - all DNS TTLs that led to this hostname ) } for all terminal - lookup results). + 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" 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; order/preference; Effective TTL ( - all DNS TTLs that led to this result ) } for all hostnames). + 17. O' = (set of {hostname; port; protocol; order/preference; + Effective TTL ( all DNS TTLs that led to this result ) } for all + hostnames). 18. Generate O-1 by resolving hostnames in O' into corresponding A - and/or AAAA addresses: O-1 = (set of {IP address; port; order/ - preference; Effective TTL ( all DNS TTLs that led to this result - ) } for all hostnames ), O-2 = 0. + 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 which triggered dynamic discovery was received on {IP address; port}. If yes, O-1 = { empty set }, O-2 = BACKOFF_TIME, log error, 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 @@ -842,53 +849,56 @@ 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; 10; 60), + (radsec.xn--tu-mnchen-t9a.example.; 2083; RADIUS/TLS; 10; + 60), (backup.xn--tu-mnchen-t9a.example.; 2083; 20; 60) } // minimum TTL is 47, up'ed to MIN_EFF_TTL 12. Continuing at 18. 13. (not executed) 14. (not executed) 15. (not executed) 16. (not executed) 17. (not executed) 18. O-1 = { - (2001:0DB8::202:44ff:fe0a:f704; 2083; 10; 60), + (2001:0DB8::202:44ff:fe0a:f704; 2083; RADIUS/TLS; 10; 60), - (192.0.2.7; 2083; 20; 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. + preference to [2001:0DB8::202:44ff:fe0a:f704]:2083 using the RADIUS/ + TLS protocol. 4. 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 defaulting to three seconds for RADIUS' operational reasons. The @@ -957,26 +967,30 @@ 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 Clearinghouses can be eliminated by RADIUS clients directly - contacting the RADIUS home server, if this is desired. The - possibility of aggregation of user information in the - clearinghouse thus does not manifest. Note that despite the - technical possibility of avoiding clearinghouses, they may still - remain in operation for other reasons. + 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 exist + reasons why clearinghouses might still be used. One reason to + keep a clearinghouse is to act as a gateway for multiple backends + in a company; another reason may be a requirement to sanitise + RADIUS datagrams (filter attributes, tag requests with new + attributes, ... ). 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 which are only deployed for pure request routing reasons. This reduces the number of entities which can inspect the RADIUS traffic. o RADIUS clients which 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