draft-ietf-radext-dynamic-discovery-08.txt   draft-ietf-radext-dynamic-discovery-09.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: April 19, 2014 OSC Expires: June 23, 2014 OSC
October 16, 2013 December 20, 2013
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-08 draft-ietf-radext-dynamic-discovery-09
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 April 19, 2014. This Internet-Draft will expire on June 23, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 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
skipping to change at page 2, line 12 skipping to change at page 2, line 12
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 . . . . . . . . . . . . . . . . . . . . . . . 3 2.1.1. S-NAPTR . . . . . . . . . . . . . . . . . . . . . . . 4
2.1.2. SRV . . . . . . . . . . . . . . . . . . . . . . . . . 8 2.1.2. SRV . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.1.3. Remarks . . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . 11 3.2. Configuration Variables . . . . . . . . . . . . . . . . . 12
3.3. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . 12 3.3. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.4. Realm to RADIUS server resolution algorithm . . . . . . . 12 3.4. Realm to RADIUS server resolution algorithm . . . . . . . 13
3.4.1. Input . . . . . . . . . . . . . . . . . . . . . . . . 12 3.4.1. Input . . . . . . . . . . . . . . . . . . . . . . . . 13
3.4.2. Output . . . . . . . . . . . . . . . . . . . . . . . 13 3.4.2. Output . . . . . . . . . . . . . . . . . . . . . . . 14
3.4.3. Algorithm . . . . . . . . . . . . . . . . . . . . . . 13 3.4.3. Algorithm . . . . . . . . . . . . . . . . . . . . . . 14
3.4.4. Validity of results . . . . . . . . . . . . . . . . . 15 3.4.4. Validity of results . . . . . . . . . . . . . . . . . 15
3.4.5. Delay considerations . . . . . . . . . . . . . . . . 16 3.4.5. Delay considerations . . . . . . . . . . . . . . . . 17
3.4.6. Example . . . . . . . . . . . . . . . . . . . . . . . 16 3.4.6. Example . . . . . . . . . . . . . . . . . . . . . . . 17
4. Security Considerations . . . . . . . . . . . . . . . . . . . 19 4. Security Considerations . . . . . . . . . . . . . . . . . . . 19
5. Privacy Considerations . . . . . . . . . . . . . . . . . . . 20 5. Privacy Considerations . . . . . . . . . . . . . . . . . . . 21
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
7. Normative References . . . . . . . . . . . . . . . . . . . . 22 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 23
Appendix A. Appendix A: ASN.1 Syntax of NAIRealm . . . . . . . . 23 7.1. Normative References . . . . . . . . . . . . . . . . . . 23
7.2. Informative References . . . . . . . . . . . . . . . . . 24
Appendix A. Appendix A: ASN.1 Syntax of NAIRealm . . . . . . . . 24
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 5, line 22 skipping to change at page 5, line 33
Note that [RFC3958] already defines that a failure to identify the Note that [RFC3958] already defines that a failure to identify the
server as being authoritative for the realm is always considered a server as being authoritative for the realm is always considered a
failure; so even if a discovered target returns a wrong credential failure; so even if a discovered target returns a wrong credential
instantly, it is not eligible for retry. instantly, it is not eligible for retry.
Furthermore, the contacted RADIUS/TLS server verifies during Furthermore, the contacted RADIUS/TLS server verifies during
connection setup whether or not it finds the connecting RADIUS/TLS connection setup whether or not it finds the connecting RADIUS/TLS
client authorized or not. If the connecting RADIUS/TLS client is not client authorized or not. If the connecting RADIUS/TLS client is not
found acceptable, the server will close the TLS connection found acceptable, the server will close the TLS connection
immediately with an appropriate alert. Such TLS handshake failures immediately with an appropriate alert. Such TLS handshake failures
are permanently fatal and not eligible for retry. 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.
If the TLS session setup to a discovered target does not succeed, If the TLS session setup to a discovered target does not succeed,
that target (as identified by IP address and port number) SHOULD be that target (as identified by IP address and port number) SHOULD be
ignored from the result set of any subsequent executions of the ignored from the result set of any subsequent executions of the
discovery algorithm at least until the target's Effective TTL has discovery algorithm at least until the target's Effective TTL has
expired or until the entity which executes the algorithm changes its expired or until the entity which executes the algorithm changes its
TLS context to either send a new client certificate or expect a TLS context to either send a new client certificate or expect a
different server certificate. different server certificate.
2.1.1.3. Server Identification and Handshake 2.1.1.3. Server Identification and Handshake
After the algorithm in this document has been executed, a RADIUS/TLS After the algorithm in this document has been executed, a RADIUS/TLS
session as per [RFC6614] is established. Since the algorithm does session as per [RFC6614] is established. Since the dynamic discover
not allow to derive confidential keying material between the RADIUS/ algorithm does not have provisions to establish confidential keying
TLS client (i.e. the server which executes the discovery algorithm) material between the RADIUS/TLS client (i.e. the server which
and the RADIUS/TLS server which was discovered, TLS-PSK ciphersuites executes the discovery algorithm) and the RADIUS/TLS server which was
can not be used for the subsequent TLS handshake in the RADIUS/TLS discovered, TLS-PKS ciphersuites cannot be used for in the subsequent
conversation. Only TLS ciphersuites using X.509 certificates can be TLS handshake. Only TLS ciphersuites using X.509 certificates can be
used with this algorithm. used with this algorithm.
There are numerous ways to define which certificates are acceptable There are numerous ways to define which certificates are acceptable
for use in this context. This document defines one mandatory-to- for use in this context. This document defines one mandatory-to-
implement mechanism which allows to verify whether the contacted host implement mechanism which allows to verify whether the contacted host
is authoritative for a NAI realm or not. It also gives one example is authoritative for a NAI realm or not. It also gives one example
of another mechanism which is currently in wide-spread deployment, of another mechanism which is currently in wide-spread deployment,
and one possible approach based on DNSSEC which is yet unimplemented. and one possible approach based on DNSSEC which is yet unimplemented.
2.1.1.3.1. Mandatory-to-implement mechanism: Trust Roots + NAIRealm 2.1.1.3.1. Mandatory-to-implement mechanism: Trust Roots + NAIRealm
skipping to change at page 6, line 4 skipping to change at page 6, line 16
used with this algorithm. used with this algorithm.
There are numerous ways to define which certificates are acceptable There are numerous ways to define which certificates are acceptable
for use in this context. This document defines one mandatory-to- for use in this context. This document defines one mandatory-to-
implement mechanism which allows to verify whether the contacted host implement mechanism which allows to verify whether the contacted host
is authoritative for a NAI realm or not. It also gives one example is authoritative for a NAI realm or not. It also gives one example
of another mechanism which is currently in wide-spread deployment, of another mechanism which is currently in wide-spread deployment,
and one possible approach based on DNSSEC which is yet unimplemented. and one possible approach based on DNSSEC which is yet unimplemented.
2.1.1.3.1. Mandatory-to-implement mechanism: Trust Roots + NAIRealm 2.1.1.3.1. Mandatory-to-implement mechanism: Trust Roots + NAIRealm
Verification of authority to provide AAA services over RADIUS/TLS is Verification of authority to provide AAA services over RADIUS/TLS is
a two-step process. a two-step process.
Step 1 is the verification of certificate wellformedness and validity Step 1 is the verification of certificate wellformedness and validity
as per [RFC5280] and whether it was issued from a root certificate as per [RFC5280] and whether it was issued from a root certificate
which is deemed trustworthy by the RADIUS/TLS client. which is deemed trustworthy by the RADIUS/TLS client.
Step 2 is: compare the value of algorithm's variable "R" after the Step 2 is to compare the value of algorithm's variable "R" after the
execution of step 3 of the discovery algorithm in Section 3.4.3 below 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 (i.e. after a consortium name mangling, but before conversion to a
form usable by the name resolution library) to all values of the form usable by the name resolution library) to all values of the
contacted RADIUS/TLS server's X.509 certificate property contacted RADIUS/TLS server's X.509 certificate property
"subjectAlternativeName:otherName:NAIRealm" as defined in "subjectAlternativeName:otherName:NAIRealm" as defined in
Section 2.2. The comparison is a byte-by-byte comparison, except for Section 2.2.
dot-separated parts of the value whose content is a single "*"
character; such labels match all strings in the same 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.
Examples:
+-----------------+-----------------------------------------------+
| NAI realm | NAIRealm | MATCH? |
+-----------------+-----------------------------------------------+
| foo.example | foo.example | YES |
| foo.example | *.example | YES |
| bar.foo.example | *.example | NO |
| 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 3: Examples for NAI realm vs. certificate matching
2.1.1.3.2. Other mechanism: Trust Roots + policyOID 2.1.1.3.2. Other mechanism: Trust Roots + policyOID
Verification of authority to provide AAA services over RADIUS/TLS is Verification of authority to provide AAA services over RADIUS/TLS is
a two-step process. a two-step process.
Step 1 is the verification of certificate wellformedness and validity Step 1 is the verification of certificate wellformedness and validity
as per [RFC5280] and whether it was issued from a root certificate as per [RFC5280] and whether it was issued from a root certificate
which is deemed trustworthy by the RADIUS/TLS client. which is deemed trustworthy by the RADIUS/TLS client.
Step 2 is: compare the values of the contacted RADIUS/TLS server's 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 X.509 certificate's extensions of type "Policy OID" to a list of
configured acceptable Policy OIDs for the roaming consortium. If one configured acceptable Policy OIDs for the roaming consortium. If one
of the configured OIDs is found in the certificate's Policy OID of the configured OIDs is found in the certificate's Policy OID
extensions, then the server is considered authorized; if there is no extensions, then the server is considered authorized; if there is no
match, the server is considered unauthorized. match, the server is considered unauthorized.
This mechanism is inferior to the mandatory-to-implement mechanism in This mechanism is inferior to the mandatory-to-implement mechanism in
the previous section because all authorized servers are validated by the previous section because all authorized servers are validated by
the same OID value; the mechanism is not fine-grained enough to the same OID value; the mechanism is not fine-grained enough to
express authority for one specific realm inside the consortium. If express authority for one specific realm inside the consortium. If
the consortium contains members which are hostile against other the consortium contains members which are hostile against other
members, this weakness can be exploited by one RADIUS/TLS server members, this weakness can be exploited by one RADIUS/TLS server
impersonating another if DNS responses can be spoofed by the hostile impersonating another if DNS responses can be spoofed by the hostile
member. member.
It should be noted that these shortcomings can be mitigated by using The shortcomings in server identification can be partially mitigated
the RADIUS infrastructure only with authentication payloads which by using the RADIUS infrastructure only with authentication payloads
provide mutual authentication; that way, the final EAP server that which provide mutual authentication and credential protection (i.e.
was reached can be validated by the EAP peer, and any improper EAP types passing the criteria of [RFC4017]): using mutual
redirections to a different server will be detected. 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 2.1.1.3.3. Other mechanism: DNSSEC / DANE
Where DNSSEC is used, the results of the algorithm can be trusted; Where DNSSEC is used, the results of the algorithm can be trusted;
i.e. the entity which executes the algorithm can be certain that the i.e. the entity which executes the algorithm can be certain that the
realm that triggered the discovery is actually served by the server realm that triggered the discovery is actually served by the server
that was discovered via DNS. However, this does not guarantee that that was discovered via DNS. However, this does not guarantee that
the server is also authorized (i.e. a recognised member of the the server is also authorized (i.e. a recognised member of the
roaming consortium). roaming consortium).
skipping to change at page 8, line 4 skipping to change at page 7, line 49
Realm = "example.com" Realm = "example.com"
Common Branch = "idp.roaming-consortium.example. Common Branch = "idp.roaming-consortium.example.
label for TLSA query = "example.com.idp.roaming- label for TLSA query = "example.com.idp.roaming-
consortium.example. consortium.example.
result of discovery algorithm for realm "example.com" = result of discovery algorithm for realm "example.com" =
192.0.2.1:2083 192.0.2.1:2083
( TLS certificate of 192.0.2.1:2083 matches TLSA RR ? "PASS" : ( TLS certificate of 192.0.2.1:2083 matches TLSA RR ? "PASS" :
"FAIL" ) "FAIL" )
2.1.1.3.4. Remark 2.1.1.3.4. Client Authentication and Authorisation
Note that RADIUS/TLS connections always mutually authenticate the Note that RADIUS/TLS connections always mutually authenticate the
RADIUS server and the RADIUS client. This specification provides an RADIUS server and the RADIUS client. This specification provides an
algorithm for a RADIUS client to contact and verify authorization of algorithm for a RADIUS client to contact and verify authorization of
a RADIUS server only. During connection setup, the RADIUS server a RADIUS server only. During connection setup, the RADIUS server
also needs to verify whether it considers the connecting RADIUS also needs to verify whether it considers the connecting RADIUS
client authorized; this is outside the scope of this specification. client authorized; this is outside the scope of this specification.
2.1.2. SRV 2.1.2. SRV
skipping to change at page 8, line 31 skipping to change at page 8, line 29
+-----------------+-----------------------------------------+ +-----------------+-----------------------------------------+
| SRV Label | Use | | SRV Label | Use |
+-----------------+-----------------------------------------+ +-----------------+-----------------------------------------+
| _radiustls._tcp | RADIUS transported over TLS as defined | | _radiustls._tcp | RADIUS transported over TLS as defined |
| | in [RFC6614] | | | in [RFC6614] |
| - - - - - - - - | - - - - - - - - - - - - - - - - - - - - | | - - - - - - - - | - - - - - - - - - - - - - - - - - - - - |
| _radiustls._udp | RADIUS transported over DTLS as defined | | _radiustls._udp | RADIUS transported over DTLS as defined |
| | in [I-D.ietf-radext-dtls] | | | in [I-D.ietf-radext-dtls] |
+-----------------+-----------------------------------------+ +-----------------+-----------------------------------------+
Figure 4: List of SRV Labels Figure 3: List of SRV Labels
Just like NAPTR records, the lookup and subsequent follow-up of SRV Just like NAPTR records, the lookup and subsequent follow-up of SRV
records may yield more than one server to contact in a prioritised records may yield more than one server to contact in a prioritised
list. [RFC2782] does not specify rules regarding "Definition of list. [RFC2782] does not specify rules regarding "Definition of
Conditions for Retry/Failure", nor "Server Identification and Conditions for Retry/Failure", nor "Server Identification and
Handshake". This specification defines that the rules for these two 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 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 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 for targets retrieved via an initial SRV RR (i.e. in the absence of
NAPTR RRs). NAPTR RRs).
2.1.3. Remarks 2.1.3. Optional name mangling
It is expected that in most cases, the SRV and/or NAPTR label used 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 for the records is the DNS A-label representation of the literal
realm name for which the server is the authoritative RADIUS server realm name for which the server is the authoritative RADIUS server
(i.e. the realm name after conversion according to section 5 of (i.e. the realm name after conversion according to section 5 of
[RFC5891]). [RFC5891]).
However, arbitrary other labels or service tags may be used if, for However, arbitrary other labels or service tags may be used if, for
example, a roaming consortium uses realm names which are not example, a roaming consortium uses realm names which are not
associated to DNS names or special-purpose consortia where a globally associated to DNS names or special-purpose consortia where a globally
skipping to change at page 11, line 4 skipping to change at page 10, line 50
a trusted comparison item. a trusted comparison item.
Further to this, this specification's NAPTR entries may be of type Further to this, this specification's NAPTR entries may be of type
"A" which do not involve resolution of any SRV records, which again "A" which do not involve resolution of any SRV records, which again
makes subjectAltName:otherName:sRVName unsuited for this purpose. makes subjectAltName:otherName:sRVName unsuited for this purpose.
This section defines the NAIRealm name as a form of otherName from This section defines the NAIRealm name as a form of otherName from
the GeneralName structure in SubjectAltName defined in [RFC5280]. the GeneralName structure in SubjectAltName defined in [RFC5280].
id-on-nai OBJECT IDENTIFIER ::= { id-on XXX } id-on-nai OBJECT IDENTIFIER ::= { id-on XXX }
NAIRealm ::= UTF8String (SIZE (1..MAX)) NAIRealm ::= UTF8String (SIZE (1..MAX))
The NAIRealm, if present, MUST contain an NAI realm as defined in The NAIRealm, if present, MUST contain an NAI realm as defined in
[I-D.ietf-radext-nai]. It MAY substitute labels on the leftmost dot- [I-D.ietf-radext-nai]. It MAY substitute labels on the leftmost dot-
separated part of the NAI with the single character "*" to indicate a separated part of the NAI with the single character "*" to indicate a
wildcard match for "all labels in this part". Further features of wildcard match for "all labels in this part". Further features of
regular expressions, such as a number of characters followed by a * regular expressions, such as a number of characters followed by a *
to indicate a common prefix inside the part, are not permitted. to indicate a common prefix inside the part, are not permitted.
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. This subjectAltName MAY occur more than once 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 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 AAA transactions where a RADIUS entity which acts as a
forwarding server for one or more realms receives a request with 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 realm for which it is not authoritative, and which no explicit next
skipping to change at page 14, line 41 skipping to change at page 15, line 21
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; order/preference; Effective TTL (
all DNS TTLs that led to this hostname ) } for all terminal all DNS TTLs that led to this hostname ) } for all terminal
lookup results). lookup results).
12. Proceed with step 18. 12. Proceed with step 18.
13. Generate R' = (prefix R with "_radiustls._tcp." 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 ) }
skipping to change at page 19, line 19 skipping to change at page 20, line 4
}; 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.
4. Security Considerations 4. Security Considerations
When using DNS without DNSSEC security extensions and validation for
The results from the execution of this algorithm are only trustworthy all of the replies to NAPTR, SRV and A/AAAA requests as described in
if each of the lookup steps by the name resolution library were section Section 3, the result O can not be trusted. Even if it can
cryptographically secured; i.e. if DNSSEC validation was turned on be trusted (i.e. DNSSEC is in use), actual authorization of the
during the resolution AND all of the records were in a DNSSEC signed
zone AND validation of all those records was successful.
When using DNS without DNSSEC security extensions for at least one 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 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
lookup of DNS resource records based on unverified user input is an lookup of DNS resource records based on unverified user input is an
attack vector for DoS attacks: an attacker might intentionally craft attack vector for DoS attacks: an attacker might intentionally craft
bogus DNS zones which take a very long time to reply (e.g. due to a bogus DNS zones which take a very long time to reply (e.g. due to a
particularly byzantine tree structure, or artificial delays in particularly byzantine tree structure, or artificial delays in
skipping to change at page 21, line 6 skipping to change at page 21, line 38
o In addition to that, with the clearinghouse being a RADIUS o In addition to that, with the clearinghouse being a RADIUS
intermediate in possession of a valid shared secret, the intermediate in possession of a valid shared secret, the
clearinghouse can observe and record even the security-critical clearinghouse can observe and record even the security-critical
RADIUS attributes such as User-Password. This risk may be RADIUS attributes such as User-Password. This risk may be
mitigated by choosing authentication payloads which are mitigated by choosing authentication payloads which are
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 aprticular, 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 Passive observers on the IP path cannot inspect any part of the
RADIUS payload. They can observe source and destination of the
traffic flow, but can not easily use this information to create
mobility profiles because the user who tries to authenticate is
not identifiable due to the encrypted payload.
o Clearinghouses can be eliminated by RADIUS clients directly o Clearinghouses can be eliminated by RADIUS clients directly
contacting the RADIUS home server, if this is desired. The contacting the RADIUS home server, if this is desired. The
possibility of aggregation of user information in the possibility of aggregation of user information in the
clearinghouse thus does not manifest. Note that despite the clearinghouse thus does not manifest. Note that despite the
technical possibility of avoid clearinghouses, they may still technical possibility of avoiding clearinghouses, they may still
remain in operation for other reasons. remain in operation for other reasons.
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 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
client and the DNS server(s) being queried can learn that a user client and the DNS server(s) being queried can learn that a user
of that specific realm was trying to authenticate at that RADIUS of that specific realm was trying to authenticate at that RADIUS
client at a certain point in time. This may or may not be client at a certain point in time. This may or may not be
sufficient for the passive observer to create a mobility profile. sufficient for the passive observer to create a mobility profile.
During the recursive DNS resolution, a fair number of DNS servers During the recursive DNS resolution, a fair number of DNS servers
and the IP hops in between those get to learn that information. and the IP hops in between those get to learn that information.
Not every single authentication triggers DNS lookups, so there is Not every single authentication triggers DNS lookups, so there is
no one-to-one relation of leaked realm information and the number no one-to-one relation of leaked realm information and the number
of authentications for that realm. 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 which do not make use of this algorithm,
and possibly using other transports such as RADIUS/UDP. On such
hops, the enhanced privacy is jeopardized.
In summary, with classic RADIUS, few intermediate entities learn very In summary, with classic RADIUS, few intermediate entities learn very
detailed data about every ongoing authentications, while with dynamic detailed data about every ongoing authentications, while with dynamic
discovery, many entities learn only very little about recently discovery, many entities learn only very little about recently
authenticated realms. authenticated realms.
6. IANA Considerations 6. IANA Considerations
This document requests IANA registration of the following entries in This document requests IANA registration of the following entries in
existing registries: existing registries:
skipping to change at page 22, line 32 skipping to change at page 23, line 25
This specification allocates a X.509 certificate property "NAIRealm" This specification allocates a X.509 certificate property "NAIRealm"
as per section Section 2.2 above, see placeholders "XXX". There is as per section Section 2.2 above, see placeholders "XXX". There is
currently no IANA registry for the subjectAltName:otherName currently no IANA registry for the subjectAltName:otherName
namespace. The authority for this namespace appears to be the PKIX namespace. The authority for this namespace appears to be the PKIX
working group. Before issuing the RFC, IANA should liaise with PKIX working group. Before issuing the RFC, IANA should liaise with PKIX
to ensure that a value for NAIRealm is issued; IANA should to ensure that a value for NAIRealm is issued; IANA should
subsequently, prior to issuing the RFC, update the placeholders in subsequently, prior to issuing the RFC, update the placeholders in
said section. said section.
7. Normative References 7. References
7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
specifying the location of services (DNS SRV)", RFC 2782, specifying the location of services (DNS SRV)", RFC 2782,
February 2000. February 2000.
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
"Remote Authentication Dial In User Service (RADIUS)", RFC "Remote Authentication Dial In User Service (RADIUS)", RFC
skipping to change at page 23, line 24 skipping to change at page 24, line 16
[RFC5580] Tschofenig, H., Adrangi, F., Jones, M., Lior, A., and B. [RFC5580] Tschofenig, H., Adrangi, F., Jones, M., Lior, A., and B.
Aboba, "Carrying Location Objects in RADIUS and Diameter", Aboba, "Carrying Location Objects in RADIUS and Diameter",
RFC 5580, August 2009. RFC 5580, August 2009.
[RFC5891] Klensin, J., "Internationalized Domain Names in [RFC5891] Klensin, J., "Internationalized Domain Names in
Applications (IDNA): Protocol", RFC 5891, August 2010. Applications (IDNA): Protocol", RFC 5891, August 2010.
[I-D.ietf-radext-dtls] [I-D.ietf-radext-dtls]
DeKok, A., "DTLS as a Transport Layer for RADIUS", draft- DeKok, A., "DTLS as a Transport Layer for RADIUS", draft-
ietf-radext-dtls-05 (work in progress), April 2013. ietf-radext-dtls-07 (work in progress), October 2013.
[RFC6614] Winter, S., McCauley, M., Venaas, S., and K. Wierenga, [RFC6614] Winter, S., McCauley, M., Venaas, S., and K. Wierenga,
"Transport Layer Security (TLS) Encryption for RADIUS", "Transport Layer Security (TLS) Encryption for RADIUS",
RFC 6614, May 2012. RFC 6614, May 2012.
[I-D.ietf-radext-nai] [I-D.ietf-radext-nai]
DeKok, A., "The Network Access Identifier", draft-ietf- DeKok, A., "The Network Access Identifier", draft-ietf-
radext-nai-03 (work in progress), May 2013. radext-nai-05 (work in progress), November 2013.
Appendix A. Appendix A: ASN.1 Syntax of NAIRealm 7.2. Informative References
PKIXServiceNameSAN93 {iso(1) identified-organization(3) dod(6) [RFC4017] Stanley, D., Walker, J., and B. Aboba, "Extensible
internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) Authentication Protocol (EAP) Method Requirements for
id-mod-dns-srv-name-93(40) } Wireless LANs", RFC 4017, March 2005.
DEFINITIONS EXPLICIT TAGS ::= Appendix A. Appendix A: ASN.1 Syntax of NAIRealm
PKIXServiceNameSAN93 {iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-dns-srv-name-93(40) }
BEGIN DEFINITIONS EXPLICIT TAGS ::=
-- EXPORTS ALL -- BEGIN
IMPORTS -- EXPORTS ALL --
id-pkix IMPORTS
FROM PKIX1Explicit88 { iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7)
id-mod(0) id-pkix1-explicit(18) } ;
-- from RFC 5280
-- In the GeneralName definition using the 1993 ASN.1 syntax id-pkix
-- includes: 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 RFC 5280
OTHER-NAME ::= TYPE-IDENTIFIER 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)}
;
-- Service Name Object Identifier -- Service Name Object Identifier
id-on OBJECT IDENTIFIER ::= { id-pkix 8 } id-on OBJECT IDENTIFIER ::= { id-pkix 8 }
id-on-nai OBJECT IDENTIFIER ::= { id-on XXX } id-on-nai OBJECT IDENTIFIER ::= { id-on 99999 }
-- Service Name -- Service Name
naiRealm OTHER-NAME ::= { NAIRealm IDENTIFIED BY { id-on-nai }} naiRealm OTHER-NAME ::= { NAIRealm IDENTIFIED BY { id-on-nai }}
NAIRealm ::= UTF8String (SIZE (1..MAX)) NAIRealm ::= UTF8String (SIZE (1..MAX))
END END
Authors' Addresses Authors' Addresses
Stefan Winter Stefan Winter
Fondation RESTENA Fondation RESTENA
6, rue Richard Coudenhove-Kalergi 6, rue Richard Coudenhove-Kalergi
Luxembourg 1359 Luxembourg 1359
LUXEMBOURG LUXEMBOURG
Phone: +352 424409 1 Phone: +352 424409 1
 End of changes. 49 change blocks. 
102 lines changed or deleted 129 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/