draft-ietf-radext-dynamic-discovery-09.txt   draft-ietf-radext-dynamic-discovery-10.txt 
RADIUS Extensions Working Group S. Winter RADIUS Extensions Working Group S. Winter
Internet-Draft RESTENA Internet-Draft RESTENA
Intended status: Experimental M. McCauley Intended status: Experimental M. McCauley
Expires: June 23, 2014 OSC Expires: August 18, 2014 OSC
December 20, 2013 February 14, 2014
NAI-based Dynamic Peer Discovery for RADIUS/TLS and RADIUS/DTLS NAI-based Dynamic Peer Discovery for RADIUS/TLS and RADIUS/DTLS
draft-ietf-radext-dynamic-discovery-09 draft-ietf-radext-dynamic-discovery-10
Abstract Abstract
This document specifies a means to find authoritative RADIUS servers This document specifies a means to find authoritative RADIUS servers
for a given realm. It is used in conjunction with either RADIUS/TLS for a given realm. It is used in conjunction with either RADIUS/TLS
and RADIUS/DTLS. and RADIUS/DTLS.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
skipping to change at page 1, line 33 skipping to change at page 1, line 33
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." 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 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. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. DNS RR definition . . . . . . . . . . . . . . . . . . . . 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.2. SRV . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.1.3. Optional name mangling . . . . . . . . . . . . . . . 8 2.1.3. Optional name mangling . . . . . . . . . . . . . . . 8
2.2. Definition of the X.509 certificate property 2.2. Definition of the X.509 certificate property
SubjectAltName:otherName:NAIRealm . . . . . . . . . . . . 10 SubjectAltName:otherName:NAIRealm . . . . . . . . . . . . 10
3. DNS-based NAPTR/SRV Peer Discovery . . . . . . . . . . . . . 11 3. DNS-based NAPTR/SRV Peer Discovery . . . . . . . . . . . . . 11
3.1. Applicability . . . . . . . . . . . . . . . . . . . . . . 11 3.1. Applicability . . . . . . . . . . . . . . . . . . . . . . 11
3.2. Configuration Variables . . . . . . . . . . . . . . . . . 12 3.2. Configuration Variables . . . . . . . . . . . . . . . . . 12
3.3. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . 12 3.3. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.4. Realm to RADIUS server resolution algorithm . . . . . . . 13 3.4. Realm to RADIUS server resolution algorithm . . . . . . . 13
3.4.1. Input . . . . . . . . . . . . . . . . . . . . . . . . 13 3.4.1. Input . . . . . . . . . . . . . . . . . . . . . . . . 13
3.4.2. Output . . . . . . . . . . . . . . . . . . . . . . . 14 3.4.2. Output . . . . . . . . . . . . . . . . . . . . . . . 14
3.4.3. Algorithm . . . . . . . . . . . . . . . . . . . . . . 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.5. Delay considerations . . . . . . . . . . . . . . . . 17
3.4.6. Example . . . . . . . . . . . . . . . . . . . . . . . 17 3.4.6. Example . . . . . . . . . . . . . . . . . . . . . . . 17
4. Security Considerations . . . . . . . . . . . . . . . . . . . 19 4. Security Considerations . . . . . . . . . . . . . . . . . . . 19
5. Privacy Considerations . . . . . . . . . . . . . . . . . . . 21 5. Privacy Considerations . . . . . . . . . . . . . . . . . . . 20
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 23
7.1. Normative References . . . . . . . . . . . . . . . . . . 23 7.1. Normative References . . . . . . . . . . . . . . . . . . 23
7.2. Informative References . . . . . . . . . . . . . . . . . 24 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 1. Introduction
RADIUS in all its current transport variants (RADIUS/UDP, RADIUS/TLS, RADIUS in all its current transport variants (RADIUS/UDP, RADIUS/TLS,
RADIUS/DTLS) requires manual configuration of all peers (clients, RADIUS/DTLS) requires manual configuration of all peers (clients,
servers). servers).
Where RADIUS forwarding servers are in use, the number of realms to Where RADIUS forwarding servers are in use, the number of realms to
be forwarded and the corresponding number of servers to configure may be forwarded and the corresponding number of servers to configure may
be significant. Where new realms with new servers are added or be significant. Where new realms with new servers are added or
skipping to change at page 11, line 21 skipping to change at page 11, line 21
The comparison of a NAIRealm to the NAI realm as derived from user 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 input with this algorithm is a byte-by-byte comparison, except for
the optional leftmost dot-separated part of the value whose content the optional leftmost dot-separated part of the value whose content
is a single "*" character; such labels match all strings in the same 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 dot-separated part of the NAI realm. If at least one of the
sAN:otherName:NAIRealm values matches the NAI realm, the server is sAN:otherName:NAIRealm values matches the NAI realm, the server is
considered authorized; if none matches, the server is considered considered authorized; if none matches, the server is considered
unauthorized. 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: Examples:
+---------------------+-------------------+-----------------------+ +---------------------+-------------------+-----------------------+
| NAI realm (RADIUS) | NAIRealm (cert) | MATCH? | | NAI realm (RADIUS) | NAIRealm (cert) | MATCH? |
+---------------------+-------------------+-----------------------+ +---------------------+-------------------+-----------------------+
| foo.example | foo.example | YES | | foo.example | foo.example | YES |
| foo.example | *.example | YES | | foo.example | *.example | YES |
| bar.foo.example | *.example | NO | | bar.foo.example | *.example | NO |
| bar.foo.example | *ar.foo.example | NO (NAIRealm invalid) | | bar.foo.example | *ar.foo.example | NO (NAIRealm invalid) |
skipping to change at page 11, line 47 skipping to change at page 11, line 49
Figure 4: Examples for NAI realm vs. certificate matching Figure 4: Examples for NAI realm vs. certificate matching
Appendix A contains the ASN.1 definition of the above objects. Appendix A contains the ASN.1 definition of the above objects.
3. DNS-based NAPTR/SRV Peer Discovery 3. DNS-based NAPTR/SRV Peer Discovery
3.1. Applicability 3.1. Applicability
Dynamic server discovery as defined in this document is only Dynamic server discovery as defined in this document is only
applicable for AAA transactions where a RADIUS entity which acts as a applicable for new AAA transactions and per service (i.e. distinct
forwarding server for one or more realms receives a request with a discovery is needed for Authentication, Accounting, and Dynamic
realm for which it is not authoritative, and which no explicit next Authorization) where a RADIUS entity which acts as a forwarding
hop is configured. It is only applicable for 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. a. new user sessions, i.e. for the initial Access-Request.
Subsequent messages concerning this session, for example Access- Subsequent messages concerning this session, for example Access-
Challenges and Access-Accepts use the previously-established Challenges and Access-Accepts use the previously-established
communication channel between client and server. 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 3.2. Configuration Variables
The algorithm contains various variables for timeouts. These The algorithm contains various variables for timeouts. These
variables are named here and reasonable default values are provided. variables are named here and reasonable default values are provided.
Implementations wishing to deviate from these defaults should make Implementations wishing to deviate from these defaults should make
they understand the implications of changes. they understand the implications of changes.
DNS_TIMEOUT: maximum amount of time to wait for the complete set DNS_TIMEOUT: maximum amount of time to wait for the complete set
of all DNS queries to complete: Default = 3 seconds of all DNS queries to complete: Default = 3 seconds
skipping to change at page 14, line 16 skipping to change at page 14, line 19
be taken to avoid problems when resolving servers with the algorithm be taken to avoid problems when resolving servers with the algorithm
below: they may resolve to a RADIUS server even if the peer RADIUS below: they may resolve to a RADIUS server even if the peer RADIUS
server only is configured to handle the realm without the trailing server only is configured to handle the realm without the trailing
dot. If that RADIUS server again uses NAI discovery to determine the dot. If that RADIUS server again uses NAI discovery to determine the
authoritative server, the server will forward the request to authoritative server, the server will forward the request to
localhost, resulting in a tight endless loop. localhost, resulting in a tight endless loop.
3.4.2. Output 3.4.2. Output
Output O of the algorithm is a two-tuple consisting of: O-1) a set of 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 tuples {hostname; port; protocol; order/preference; Effective TTL} -
can be empty; and O-2) an integer: if the set in the first part of the set can be empty; and O-2) an integer: if the set in the first
the tuple is empty, the integer contains the Effective TTL for part of the tuple is empty, the integer contains the Effective TTL
backoff timeout, if the set is not empty, the integer is set to 0 for backoff timeout, if the set is not empty, the integer is set to 0
(and not used). (and not used).
3.4.3. Algorithm 3.4.3. Algorithm
The algorithm to determine the RADIUS server to contact is as The algorithm to determine the RADIUS server to contact is as
follows: follows:
1. Determine P = (position of last "@" character) in I. 1. Determine P = (position of last "@" character) in I.
2. generate R = (substring from P+1 to end of I) 2. generate R = (substring from P+1 to end of I)
skipping to change at page 14, line 47 skipping to change at page 14, line 50
DNS_TIMEOUT, continue at step 20. DNS_TIMEOUT, continue at step 20.
6. Using the host's name resolution library, perform a NAPTR query 6. Using the host's name resolution library, perform a NAPTR query
for R (see "Delay considerations" below). If the result is a for R (see "Delay considerations" below). If the result is a
negative DNS response, O-2 = Effective TTL ( TTL value of the negative DNS response, O-2 = Effective TTL ( TTL value of the
SOA record ) and continue at step 13. If name resolution SOA record ) and continue at step 13. If name resolution
returns with error, O-1 = { empty set }, O-2 = BACKOFF_TIME and returns with error, O-1 = { empty set }, O-2 = BACKOFF_TIME and
terminate. terminate.
7. Extract NAPTR records with service tag "aaa+auth", "aaa+acct", 7. Extract NAPTR records with service tag "aaa+auth", "aaa+acct",
"aaa+dynauth" as appropriate. Keep note of the remaining TTL of "aaa+dynauth" as appropriate. Keep note of the protocol tag and
each of the discovered NAPTR records. remaining TTL of each of the discovered NAPTR records.
8. If no records found, continue at step 13. 8. If no records found, continue at step 13.
9. For the extracted NAPTRs, perform successive resolution as 9. For the extracted NAPTRs, perform successive resolution as
defined in [RFC3958], section 2.2. An implementation MAY use defined in [RFC3958], section 2.2. An implementation MAY use
greedy result evaluation according to the NAPTR order/preference greedy result evaluation according to the NAPTR order/preference
fields (i.e. can execute the subsequent steps of this algorithm fields (i.e. can execute the subsequent steps of this algorithm
for the highest-order entry in the set of results, and only for the highest-order entry in the set of results, and only
lookup the remainder of the set if necessary). lookup the remainder of the set if necessary).
10. If the set of hostnames is empty, O-1 = { empty set }, O-2 = 10. If the set of hostnames is empty, O-1 = { empty set }, O-2 =
BACKOFF_TIME and terminate. BACKOFF_TIME and terminate.
11. O' = (set of {hostname; port; order/preference; Effective TTL ( 11. O' = (set of {hostname; port; protocol; order/preference;
all DNS TTLs that led to this hostname ) } for all terminal Effective TTL ( all DNS TTLs that led to this hostname ) } for
lookup results). all terminal lookup results).
12. Proceed with step 18. 12. Proceed with step 18.
13. Generate R' = (prefix R with "_radiustls._tcp." and/or 13. Generate R' = (prefix R with "_radiustls._tcp." and/or
"_radiustls._udp.") "_radiustls._udp.")
14. Using the host's name resolution library, perform SRV lookup 14. Using the host's name resolution library, perform SRV lookup
with R' as label (see "Delay considerations" below). with R' as label (see "Delay considerations" below).
15. If name resolution returns with error, O-1 = { empty set }, O-2 15. If name resolution returns with error, O-1 = { empty set }, O-2
= BACKOFF_TIME and terminate. = BACKOFF_TIME and terminate.
16. If the result is a negative DNS response, O-1 = { empty set }, 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 ) } O-2 = min { O-2, Effective TTL ( TTL value of the SOA record ) }
and terminate. and terminate.
17. O' = (set of {hostname; port; order/preference; Effective TTL ( 17. O' = (set of {hostname; port; protocol; order/preference;
all DNS TTLs that led to this result ) } for all hostnames). 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 18. Generate O-1 by resolving hostnames in O' into corresponding A
and/or AAAA addresses: O-1 = (set of {IP address; port; order/ and/or AAAA addresses: O-1 = (set of {IP address; port;
preference; Effective TTL ( all DNS TTLs that led to this result protocol; order/preference; Effective TTL ( all DNS TTLs that
) } for all hostnames ), O-2 = 0. led to this result ) } for all hostnames ), O-2 = 0.
19. For each element in O-1, test if the original request which 19. For each element in O-1, test if the original request which
triggered dynamic discovery was received on {IP address; port}. triggered dynamic discovery was received on {IP address; port}.
If yes, O-1 = { empty set }, O-2 = BACKOFF_TIME, log error, If yes, O-1 = { empty set }, O-2 = BACKOFF_TIME, log error,
Terminate (see next section for a rationale). If no, O is the Terminate (see next section for a rationale). If no, O is the
result of dynamic discovery. Terminate. result of dynamic discovery. Terminate.
20. O-1 = { empty set }, O-2 = BACKOFF_TIME, log error, Terminate. 20. O-1 = { empty set }, O-2 = BACKOFF_TIME, log error, Terminate.
3.4.4. Validity of results 3.4.4. Validity of results
skipping to change at page 19, line 12 skipping to change at page 19, line 12
9. Successive resolution performs SRV query for label 9. Successive resolution performs SRV query for label
_myradius._tcp.xn--tu-mnchen-t9a.example, which results in _myradius._tcp.xn--tu-mnchen-t9a.example, which results in
(TTL 499) 0 10 2083 radsec.xn--tu-mnchen-t9a.example. (TTL 499) 0 10 2083 radsec.xn--tu-mnchen-t9a.example.
(TTL 2200) 0 20 2083 backup.xn--tu-mnchen-t9a.example. (TTL 2200) 0 20 2083 backup.xn--tu-mnchen-t9a.example.
10. NOOP 10. NOOP
11. O' = { 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) (backup.xn--tu-mnchen-t9a.example.; 2083; 20; 60)
} // minimum TTL is 47, up'ed to MIN_EFF_TTL } // minimum TTL is 47, up'ed to MIN_EFF_TTL
12. Continuing at 18. 12. Continuing at 18.
13. (not executed) 13. (not executed)
14. (not executed) 14. (not executed)
15. (not executed) 15. (not executed)
16. (not executed) 16. (not executed)
17. (not executed) 17. (not executed)
18. O-1 = { 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 }; O-2 = 0
19. No match with own listening address; terminate with tuple (O-1, 19. No match with own listening address; terminate with tuple (O-1,
O-2) from previous step. O-2) from previous step.
The implementation will then attempt to connect to two servers, with 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 4. Security Considerations
When using DNS without DNSSEC security extensions and validation for When using DNS without DNSSEC security extensions and validation for
all of the replies to NAPTR, SRV and A/AAAA requests as described in 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 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 be trusted (i.e. DNSSEC is in use), actual authorization of the
discovered server to provide service for the given realm needs to be discovered server to provide service for the given realm needs to be
verified. A mechanism from section Section 2.1.1.3 or equivalent verified. A mechanism from section Section 2.1.1.3 or equivalent
MUST be used to verify authorization. MUST be used to verify authorization.
The algorithm has a configurable completion time-out DNS_TIMEOUT The algorithm has a configurable completion time-out DNS_TIMEOUT
defaulting to three seconds for RADIUS' operational reasons. The defaulting to three seconds for RADIUS' operational reasons. The
skipping to change at page 21, line 44 skipping to change at page 21, line 36
cryptographically secured and do not use the attribute User- cryptographically secured and do not use the attribute User-
Password - such as certain EAP types. Password - such as certain EAP types.
o There is no additional information disclosure to parties outside o There is no additional information disclosure to parties outside
the IP path between the RADIUS client and server (in particular, the IP path between the RADIUS client and server (in particular,
no DNS servers learn about realms of current ongoing no DNS servers learn about realms of current ongoing
authentications). authentications).
With RADIUS and dynamic discovery, With RADIUS and dynamic discovery,
o Clearinghouses can be eliminated by RADIUS clients directly o This protocol allows for RADIUS clients to identify and directly
contacting the RADIUS home server, if this is desired. The connect to the RADIUS home server. This can eliminate the use of
possibility of aggregation of user information in the clearinghouses to do forwarding of requests, and it also
clearinghouse thus does not manifest. Note that despite the eliminates the ability of the clearinghouse to then aggregate the
technical possibility of avoiding clearinghouses, they may still user information that flows through it. However, there exist
remain in operation for other reasons. 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 o Even where intermediate proxies continue to be used for reasons
unrelated to dynamic discovery, the number of such intermediates unrelated to dynamic discovery, the number of such intermediates
may be reduced by removing those proxies which are only deployed may be reduced by removing those proxies which are only deployed
for pure request routing reasons. This reduces the number of for pure request routing reasons. This reduces the number of
entities which can inspect the RADIUS traffic. entities which can inspect the RADIUS traffic.
o RADIUS clients which make use of dynamic discovery will need to 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 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 query label. A passive observer on the IP path between the RADIUS
 End of changes. 22 change blocks. 
39 lines changed or deleted 54 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/