draft-ietf-radext-dynamic-discovery-11.txt   draft-ietf-radext-dynamic-discovery-12.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: September 4, 2014 OSC Expires: April 30, 2015 OSC
March 03, 2014 October 27, 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-11 draft-ietf-radext-dynamic-discovery-12
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 September 4, 2014. This Internet-Draft will expire on April 30, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 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
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
1.3. Document Status . . . . . . . . . . . . . . . . . . . . . 4 1.3. Document Status . . . . . . . . . . . . . . . . . . . . . 4
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. DNS RR definition . . . . . . . . . . . . . . . . . . . . 4 2.1. DNS Resource Record definition . . . . . . . . . . . . . 4
2.1.1. S-NAPTR . . . . . . . . . . . . . . . . . . . . . . . 5 2.1.1. S-NAPTR . . . . . . . . . . . . . . . . . . . . . . . 4
2.1.2. SRV . . . . . . . . . . . . . . . . . . . . . . . . . 9 2.1.2. SRV . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.1.3. Optional name mangling . . . . . . . . . . . . . . . 9 2.1.3. Optional name mangling . . . . . . . . . . . . . . . 9
2.2. Definition of the X.509 certificate property 2.2. Definition of the X.509 certificate property
SubjectAltName:otherName:NAIRealm . . . . . . . . . . . . 11 SubjectAltName:otherName:NAIRealm . . . . . . . . . . . . 11
3. DNS-based NAPTR/SRV Peer Discovery . . . . . . . . . . . . . 12 3. DNS-based NAPTR/SRV Peer Discovery . . . . . . . . . . . . . 12
3.1. Applicability . . . . . . . . . . . . . . . . . . . . . . 12 3.1. Applicability . . . . . . . . . . . . . . . . . . . . . . 12
3.2. Configuration Variables . . . . . . . . . . . . . . . . . 13 3.2. Configuration Variables . . . . . . . . . . . . . . . . . 13
3.3. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . 13 3.3. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.4. Realm to RADIUS server resolution algorithm . . . . . . . 14 3.4. Realm to RADIUS server resolution algorithm . . . . . . . 14
3.4.1. Input . . . . . . . . . . . . . . . . . . . . . . . . 14 3.4.1. Input . . . . . . . . . . . . . . . . . . . . . . . . 14
skipping to change at page 2, line 49 skipping to change at page 2, line 49
RADIUS in all its current transport variants (RADIUS/UDP, RADIUS/TCP, RADIUS in all its current transport variants (RADIUS/UDP, RADIUS/TCP,
RADIUS/TLS, RADIUS/DTLS) requires manual configuration of all peers RADIUS/TLS, RADIUS/DTLS) requires manual configuration of all peers
(clients, servers). (clients, servers).
Where more than one administrative entity collaborates for RADIUS Where more than one administrative entity collaborates for RADIUS
authentication of their respective customers (a "roaming authentication of their respective customers (a "roaming
consortium"), the Network Access Identifier (NAI) consortium"), the Network Access Identifier (NAI)
[I-D.ietf-radext-nai] is the suggested way of differentiating users [I-D.ietf-radext-nai] is the suggested way of differentiating users
between those entities; the part of a username to the right of the @ between those entities; the part of a username to the right of the @
delimiter in a NAI is called the user's "realm". Where many realms delimiter in an NAI is called the user's "realm". Where many realms
and RADIUS forwarding servers are in use, the number of realms to be and 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 details significant. Where new realms with new servers are added or details
of existing servers change on a regular basis, maintaining a single of existing servers change on a regular basis, maintaining a single
monolithic configuration file for all these details may prove too monolithic configuration file for all these details may prove too
cumbersome to be useful. cumbersome to be useful.
Furthermore, in cases where a roaming consortium consists of Furthermore, in cases where a roaming consortium consists of
independently working branches (e.g. departments, national independently working branches (e.g. departments, national
subsidiaries), each with their own forwarding servers, and who add or subsidiaries), each with their own forwarding servers, and who add or
skipping to change at page 4, line 30 skipping to change at page 4, line 30
The document provides a discovery mechanism for RADIUS which is very The document provides a discovery mechanism for RADIUS which is very
similar to the approach that is taken with the Diameter protocol similar to the approach that is taken with the Diameter protocol
[RFC6733]. As such, the basic approach (using NAPTR records in DNS [RFC6733]. As such, the basic approach (using NAPTR records in DNS
domains which match NAI realms) is not of very experimental nature. domains which match NAI realms) is not of very experimental nature.
However, the document offers a few choice points and extensions which However, the document offers a few choice points and extensions which
go beyond the provisions for Diameter. The list of major additions/ go beyond the provisions for Diameter. The list of major additions/
deviations is deviations is
o a fallback mechanism using SRV records, should no matching NAPTR
records be found (not defined for Diameter)
o Provisions for determining the authority of a server to act for o Provisions for determining the authority of a server to act for
users of a realm (declared out of scope for Diameter) users of a realm (declared out of scope for Diameter)
o much more in-depth guidance on DNS regarding timeouts, failure o much more in-depth guidance on DNS regarding timeouts, failure
conditions, alteration of TTLs (not considered for Diameter) conditions, alteration of Time-To-Live (TTL) information than the
Diameter counterpart
o a partially correct routing error detection (not considered for o a partially correct routing error detection during DNS lookups
Diameter)
2. Definitions 2. Definitions
2.1. DNS RR definition 2.1. DNS Resource Record definition
DNS definitions of RADIUS/TLS servers can be either S-NAPTR records DNS definitions of RADIUS/TLS servers can be either S-NAPTR records
(see [RFC3958]) or SRV records. When both are defined, the (see [RFC3958]) or SRV records. When both are defined, the
resolution algorithm prefers S-NAPTR results (see Section 3.4 below). resolution algorithm prefers S-NAPTR results (see Section 3.4 below).
2.1.1. S-NAPTR 2.1.1. S-NAPTR
2.1.1.1. Registration of Application Service and Protocol Tags 2.1.1.1. Registration of Application Service and Protocol Tags
This specification defines three S-NAPTR service tags: This specification defines three S-NAPTR service tags:
+-----------------+-----------------------------------------+ +-----------------+-----------------------------------------+
| Service Tag | Use | | Service Tag | Use |
+-----------------+-----------------------------------------+ +-----------------+-----------------------------------------+
| aaa+auth | RADIUS Authentication, i.e. traffic as | | aaa+auth | RADIUS Authentication, i.e. traffic as |
| | defined in [RFC2865] | | | defined in [RFC2865] |
| - - - - - - - - | - - - - - - - - - - - - - - - - - - - - | | - - - - - - - - | - - - - - - - - - - - - - - - - - - - - |
skipping to change at page 5, line 22 skipping to change at page 5, line 19
| Service Tag | Use | | Service Tag | Use |
+-----------------+-----------------------------------------+ +-----------------+-----------------------------------------+
| aaa+auth | RADIUS Authentication, i.e. traffic as | | aaa+auth | RADIUS Authentication, i.e. traffic as |
| | defined in [RFC2865] | | | defined in [RFC2865] |
| - - - - - - - - | - - - - - - - - - - - - - - - - - - - - | | - - - - - - - - | - - - - - - - - - - - - - - - - - - - - |
| aaa+acct | RADIUS Accounting, i.e. traffic as | | aaa+acct | RADIUS Accounting, i.e. traffic as |
| | defined in [RFC2866] | | | defined in [RFC2866] |
| - - - - - - - - | - - - - - - - - - - - - - - - - - - - - | | - - - - - - - - | - - - - - - - - - - - - - - - - - - - - |
| aaa+dynauth | RADIUS Dynamic Authorisation, i.e. | | aaa+dynauth | RADIUS Dynamic Authorisation, i.e. |
| | traffic as defined in [RFC5176] | | | traffic as defined in [RFC5176] |
+--------------- --+-----------------------------------------+ +-----------------+-----------------------------------------+
Figure 1: List of Service Tags Figure 1: List of Service Tags
This specification defines two S-NAPTR protocol tags: This specification defines two S-NAPTR protocol tags:
+-----------------+-----------------------------------------+ +-----------------+-----------------------------------------+
| Protocol Tag | Use | | Protocol Tag | Use |
+-----------------+-----------------------------------------+ +-----------------+-----------------------------------------+
| radius.tls | RADIUS transported over TLS as defined | | radius.tls.tcp | RADIUS transported over TLS as defined |
| | in [RFC6614] | | | in [RFC6614] |
| - - - - - - - - | - - - - - - - - - - - - - - - - - - - - | | - - - - - - - - | - - - - - - - - - - - - - - - - - - - - |
| radius.dtls | RADIUS transported over DTLS as defined | | radius.dtls.udp | RADIUS transported over DTLS as defined |
| | in [I-D.ietf-radext-dtls] | | | in [RFC7360] |
+-----------------+-----------------------------------------+ +-----------------+-----------------------------------------+
Figure 2: List of Protocol Tags Figure 2: List of Protocol Tags
Note well: Note well:
The S-NAPTR service and protocols are unrelated to the IANA The S-NAPTR service and protocols are unrelated to the IANA
Service Name and Transport Protocol Number registry Service Name and Transport Protocol Number registry
The delimiter '.' in the protocol tags is only a separator for The delimiter '.' in the protocol tags is only a separator for
skipping to change at page 6, line 18 skipping to change at page 6, line 14
2.1.1.2. Definition of Conditions for Retry/Failure 2.1.1.2. Definition of Conditions for Retry/Failure
RADIUS is a time-critical protocol; RADIUS clients which do not RADIUS is a time-critical protocol; RADIUS clients which do not
receive an answer after a configurable, but short, amount of time, receive an answer after a configurable, but short, amount of time,
will consider the request failed. Due to this, there is little will consider the request failed. Due to this, there is little
leeway for extensive retries. leeway for extensive retries.
As a general rule, only error conditions which generate an immediate As a general rule, only error conditions which generate an immediate
response from the other end are eligible for a retry of a discovered response from the other end are eligible for a retry of a discovered
target. Any error condition involving time-outs, or the absence of a target. Any error condition involving timeouts, or the absence of a
reply for more than one second during the connection setup phase is reply for more than one second during the connection setup phase is
to be considered a failure; the next target in the set of discovered to be considered a failure; the next target in the set of discovered
NAPTR targets is to be tried. NAPTR targets is to be tried.
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
skipping to change at page 6, line 49 skipping to change at page 6, line 45
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 dynamic discover session as per [RFC6614] is established. Since the dynamic discovery
algorithm does not have provisions to establish confidential keying algorithm does not have provisions to establish confidential keying
material between the RADIUS/TLS client (i.e. the server which material between the RADIUS/TLS client (i.e. the server which
executes the discovery algorithm) and the RADIUS/TLS server which was executes the discovery algorithm) and the RADIUS/TLS server which was
discovered, TLS-PKS ciphersuites cannot be used for in the subsequent discovered, TLS-PKS ciphersuites cannot be used for in the subsequent
TLS handshake. 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 an 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
skipping to change at page 8, line 33 skipping to change at page 8, line 29
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).
The authorization can be sketched using DNSSEC+DANE as follows: if The authorization can be sketched using DNSSEC+DANE as follows: if
DANE/TLSA records of all authorized servers are put into a DNSSEC DANE/TLSA records of all authorized servers are put into a DNSSEC
zone with a common, consortium-specific branch of the DNS tree, then zone with a common, consortium-specific branch of the DNS tree, then
the entity executing the algorithm can retrieve TLSA RRs for the the entity executing the algorithm can retrieve TLSA Resource Records
label "realm.commonroot" and verify that the presented server (TLSA RR) for the label "realm.commonroot" and verify that the
certificate during the RADIUS/TLS handshake matches the information presented server certificate during the RADIUS/TLS handshake matches
in the TLSA record. the information in the TLSA record.
Example: Example:
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.
skipping to change at page 9, line 26 skipping to change at page 9, line 26
This specification defines two SRV prefixes (i.e. two values for the This specification defines two SRV prefixes (i.e. two values for the
"_service._proto" part of an SRV RR as per [RFC2782]): "_service._proto" part of an SRV RR as per [RFC2782]):
+-----------------+-----------------------------------------+ +-----------------+-----------------------------------------+
| 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 [RFC7360] |
+-----------------+-----------------------------------------+ +-----------------+-----------------------------------------+
Figure 3: 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
skipping to change at page 10, line 13 skipping to change at page 10, line 13
associated to DNS names or special-purpose consortia where a globally associated to DNS names or special-purpose consortia where a globally
valid discovery is not a use case. Such other labels require a valid discovery is not a use case. Such other labels require a
consortium-wide agreement about the transformation from realm name to consortium-wide agreement about the transformation from realm name to
lookup label, and/or which service tag to use. lookup label, and/or which service tag to use.
Examples: Examples:
a. A general-purpose RADIUS server for realm example.com might have a. A general-purpose RADIUS server for realm example.com might have
DNS entries as follows: DNS entries as follows:
example.com. IN NAPTR 50 50 "s" "aaa+auth:radius.tls" "" example.com. IN NAPTR 50 50 "s" "aaa+auth:radius.tls.tcp" ""
_radiustls._tcp.foobar.example.com. _radiustls._tcp.foobar.example.com.
_radiustls._tcp.foobar.example.com. IN SRV 0 10 2083 _radiustls._tcp.foobar.example.com. IN SRV 0 10 2083
radsec.example.com. radsec.example.com.
b. The consortium "foo" provides roaming services for its members b. The consortium "foo" provides roaming services for its members
only. The realms used are of the form enterprise-name.example. only. The realms used are of the form enterprise-name.example.
The consortium operates a special purpose DNS server for the The consortium operates a special purpose DNS server for the
(private) TLD "example" which all RADIUS servers use to resolve (private) TLD "example" which all RADIUS servers use to resolve
realm names. "Company, Inc." is part of the consortium. On the realm names. "Company, Inc." is part of the consortium. On the
consortium's DNS server, realm company.example might have the consortium's DNS server, realm company.example might have the
following DNS entries: following DNS entries:
company.example IN NAPTR 50 50 "a" "aaa+auth:radius.dtls" "" company.example IN NAPTR 50 50 "a" "aaa+auth:radius.dtls.udp"
roamserv.company.example "" roamserv.company.example
c. The eduroam consortium uses realms based on DNS, but provides its c. The eduroam consortium (see [I-D.wierenga-ietf-eduroam] uses
services to a closed community only. However, a AAA domain realms based on DNS, but provides its services to a closed
participating in eduroam may also want to expose AAA services to community only. However, a AAA domain participating in eduroam
other, general-purpose, applications (on the same or other RADIUS may also want to expose AAA services to other, general-purpose,
servers). Due to that, the eduroam consortium uses the service applications (on the same or other RADIUS servers). Due to that,
tag "x-eduroam" for authentication purposes and eduroam RADIUS the eduroam consortium uses the service tag "x-eduroam" for
servers use this tag to look up other eduroam servers. An authentication purposes and eduroam RADIUS servers use this tag
eduroam participant example.org which also provides general- to look up other eduroam servers. An eduroam participant
purpose AAA on a different server uses the general "aaa+auth" example.org which also provides general-purpose AAA on a
tag: different server uses the general "aaa+auth" tag:
example.org. IN NAPTR 50 50 "s" "x-eduroam:radius.tls" "" example.org. IN NAPTR 50 50 "s" "x-eduroam:radius.tls.tcp" ""
_radiustls._tcp.eduroam.example.org. _radiustls._tcp.eduroam.example.org.
example.org. IN NAPTR 50 50 "s" "aaa+auth:radius.tls" "" example.org. IN NAPTR 50 50 "s" "aaa+auth:radius.tls.tcp" ""
_radiustls._tcp.aaa.example.org _radiustls._tcp.aaa.example.org
_radiustls._tcp.eduroam.example.org. IN SRV 0 10 2083 aaa- _radiustls._tcp.eduroam.example.org. IN SRV 0 10 2083 aaa-
eduroam.example.org. eduroam.example.org.
_radiustls._tcp.aaa.example.org. IN SRV 0 10 2083 aaa- _radiustls._tcp.aaa.example.org. IN SRV 0 10 2083 aaa-
default.example.org. default.example.org.
2.2. Definition of the X.509 certificate property 2.2. Definition of the X.509 certificate property
SubjectAltName:otherName:NAIRealm SubjectAltName:otherName:NAIRealm
This specification retrieves IP addresses and port numbers from the This specification retrieves IP addresses and port numbers from the
Domain Name System which are subsequently used to authenticate users Domain Name System which are subsequently used to authenticate users
via the RADIUS/TLS protocol. Since the Domain Name System is not via the RADIUS/TLS protocol. Since the Domain Name System is not
necessarily trustworthy (e.g. if DNSSEC is not deployed for the necessarily trustworthy (e.g. if DNSSEC is not deployed for the
queried domain name), it is important to verify that the server which queried domain name), it is important to verify that the server which
was contacted is authorized to service requests for the user which was contacted is authorized to service requests for the user which
triggered the discovery process. triggered the discovery process.
The input to the algorithm is a NAI realm as specified in The input to the algorithm is an NAI realm as specified in
Section 3.4.1. As a consequence, the X.509 certificate of the server Section 3.4.1. As a consequence, the X.509 certificate of the server
which is ultimately contacted for user authentication needs to be which is ultimately contacted for user authentication needs to be
able to express that it is authorized to handle requests for that able to express that it is authorized to handle requests for that
realm. realm.
Current subjectAltName fields do not semantically allow to express an Current subjectAltName fields do not semantically allow to express an
NAI realm; the field subjectAltName:dNSName is syntactically a good NAI realm; the field subjectAltName:dNSName is syntactically a good
match but would inappropriately conflate DNS names and NAI realm match but would inappropriately conflate DNS names and NAI realm
names. Thus, this specification defines a new subjectAltName field names. Thus, this specification defines a new subjectAltName field
to hold either a single NAI realm name or a wildcard name matching a to hold either a single NAI realm name or a wildcard name matching a
skipping to change at page 12, line 12 skipping to change at page 12, line 12
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 The comparison of an NAIRealm to the NAI realm as derived from user
input with this algorithm is a byte-by-byte comparison, except for 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.
Since multiple names and multiple name forms may occur in the Since multiple names and multiple name forms may occur in the
subjectAltName extension, an arbitrary number of NAIRealms can be subjectAltName extension, an arbitrary number of NAIRealms can be
skipping to change at page 13, line 13 skipping to change at page 13, line 13
Authorization) where a RADIUS entity which acts as a forwarding Authorization) where a RADIUS entity which acts as a forwarding
server for one or more realms receives a request with a realm 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 which it is not authoritative, and which no explicit next hop is
configured. It is only applicable for 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. the first accounting ticket for a user session b. the first accounting ticket for a user session.
c. the first RADIUS DynAuth packet 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 48 skipping to change at page 14, line 48
Note well: The attribute User-Name is defined to contain UTF-8 text. Note well: The attribute User-Name is defined to contain UTF-8 text.
In practice, the content may or may not be UTF-8. Even if UTF-8, it In practice, the content may or may not be UTF-8. Even if UTF-8, it
may or may not map to a domain name in the realm part. Implementors may or may not map to a domain name in the realm part. Implementors
MUST take possible conversion error paths into consideration when MUST take possible conversion error paths into consideration when
parsing incoming User-Name attributes. This document describes parsing incoming User-Name attributes. This document describes
server discovery only for well-formed realms mapping to DNS domain server discovery only for well-formed realms mapping to DNS domain
names in UTF-8 encoding. The result of all other possible contents names in UTF-8 encoding. The result of all other possible contents
of User-Name is unspecified; this includes, but is not limited to: of User-Name is unspecified; this includes, but is not limited to:
Usage of separators other than @ Usage of separators other than @.
Encoding of User-Name in local encodings Encoding of User-Name in local encodings.
UTF-8 realms which fail the conversion rules as per [RFC5891]
UTF-8 realms which fail the conversion rules as per [RFC5891].
UTF-8 realms which end with a . ("dot") character. UTF-8 realms which end with a . ("dot") character.
For the last bullet point, "trailing dot", special precautions should For the last bullet point, "trailing dot", special precautions should
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.
skipping to change at page 18, line 16 skipping to change at page 18, line 16
The host's name resolution library may need to contact outside The host's name resolution library may need to contact outside
entities to perform the name resolution (e.g. authoritative name entities to perform the name resolution (e.g. authoritative name
servers for a domain), and since the NAI discovery algorithm is based servers for a domain), and since the NAI discovery algorithm is based
on uncontrollable user input, the destination of the lookups is out on uncontrollable user input, the destination of the lookups is out
of control of the server that performs NAI discovery. If such of control of the server that performs NAI discovery. If such
outside entities are misconfigured or unreachable, the algorithm outside entities are misconfigured or unreachable, the algorithm
above may need an unacceptably long time to terminate. Many RADIUS above may need an unacceptably long time to terminate. Many RADIUS
implementations time out after five seconds of delay between Request implementations time out after five seconds of delay between Request
and Response. It is not useful to wait until the host name and Response. It is not useful to wait until the host name
resolution library signals a time-out of its name resolution resolution library signals a timeout of its name resolution
algorithms. The algorithm therefore control execution time with algorithms. The algorithm therefore control execution time with
TIMER. Execution of the NAI discovery algorithm SHOULD be non- TIMER. Execution of the NAI discovery algorithm SHOULD be non-
blocking (i.e. allow other requests to be processed in parallel to blocking (i.e. allow other requests to be processed in parallel to
the execution of the algorithm). the execution of the algorithm).
3.4.6. Example 3.4.6. Example
Assume Assume
a user from the Technical University of Munich, Germany, has a a user from the Technical University of Munich, Germany, has a
skipping to change at page 18, line 50 skipping to change at page 18, line 50
DNS_TIMEOUT = 3 seconds DNS_TIMEOUT = 3 seconds
MIN_EFF_TTL = 60 seconds MIN_EFF_TTL = 60 seconds
BACKOFF_TIME = 3600 seconds BACKOFF_TIME = 3600 seconds
If DNS contains the following records: If DNS contains the following records:
xn--tu-mnchen-t9a.example. IN NAPTR 50 50 "s" xn--tu-mnchen-t9a.example. IN NAPTR 50 50 "s"
"aaa+auth:radius.tls" "" _myradius._tcp.xn--tu-mnchen-t9a.example. "aaa+auth:radius.tls.tcp" "" _myradius._tcp.xn--tu-mnchen-
t9a.example.
xn--tu-mnchen-t9a.example. IN NAPTR 50 50 "s" xn--tu-mnchen-t9a.example. IN NAPTR 50 50 "s"
"fooservice:bar.dccp" "" _abc123._def.xn--tu-mnchen-t9a.example. "fooservice:bar.dccp" "" _abc123._def.xn--tu-mnchen-t9a.example.
_myradius._tcp.xn--tu-mnchen-t9a.example. IN SRV 0 10 2083 _myradius._tcp.xn--tu-mnchen-t9a.example. IN SRV 0 10 2083
radsecserver.xn--tu-mnchen-t9a.example. radsecserver.xn--tu-mnchen-t9a.example.
_myradius._tcp.xn--tu-mnchen-t9a.example. IN SRV 0 20 2083 _myradius._tcp.xn--tu-mnchen-t9a.example. IN SRV 0 20 2083
backupserver.xn--tu-mnchen-t9a.example. backupserver.xn--tu-mnchen-t9a.example.
skipping to change at page 19, line 37 skipping to change at page 19, line 37
2. R = "tu-m[U+00FC]nchen.example" 2. R = "tu-m[U+00FC]nchen.example"
3. NOOP 3. NOOP
4. name resolution library converts R to xn--tu-mnchen-t9a.example 4. name resolution library converts R to xn--tu-mnchen-t9a.example
5. TIMER starts. 5. TIMER starts.
6. Result: 6. Result:
(TTL = 47) 50 50 "s" "aaa+auth:radius.tls" "" (TTL = 47) 50 50 "s" "aaa+auth:radius.tls.tcp" ""
_myradius._tcp.xn--tu-mnchen-t9a.example. _myradius._tcp.xn--tu-mnchen-t9a.example.
(TTL = 522) 50 50 "s" "fooservice:bar.dccp" "" (TTL = 522) 50 50 "s" "fooservice:bar.dccp" ""
_abc123._def.xn--tu-mnchen-t9a.example. _abc123._def.xn--tu-mnchen-t9a.example.
7. Result: 7. Result:
(TTL = 47) 50 50 "s" "aaa+auth:radius.tls" "" (TTL = 47) 50 50 "s" "aaa+auth:radius.tls.tcp" ""
_myradius._tcp.xn--tu-mnchen-t9a.example. _myradius._tcp.xn--tu-mnchen-t9a.example.
8. NOOP 8. NOOP
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.
skipping to change at page 21, line 34 skipping to change at page 21, line 34
5. Security Considerations 5. 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 timeout 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
responses). responses).
To mitigate this DoS vector, implementations SHOULD consider rate- To mitigate this DoS vector, implementations SHOULD consider rate-
limiting either their amount of new executions of the dynamic limiting either their amount of new executions of the dynamic
discovery algorithm as a whole, or the amount of intermediate discovery algorithm as a whole, or the amount of intermediate
skipping to change at page 24, line 20 skipping to change at page 24, line 20
o S-NAPTR Application Service Tags registry o S-NAPTR Application Service Tags registry
* aaa+auth * aaa+auth
* aaa+acct * aaa+acct
* aaa+dynauth * aaa+dynauth
o S-NAPTR Application Protocol Tags registry o S-NAPTR Application Protocol Tags registry
* radius.tls * radius.tls.tcp
* radius.dtls * radius.dtls.udp
This document reserves the use of the "radiustls" and "radiusdtls" This document reserves the use of the "radiustls" and "radiusdtls"
service names. Registration information as per [RFC6335] section service names. Registration information as per [RFC6335] section
8.1.1 is as follows: 8.1.1 is as follows:
Service Name: radiustls; radiusdtls Service Name: radiustls; radiusdtls
Transport Protocols: TCP, UDP Transport Protocols: TCP, UDP
Assignee: IESG <iesg@ietf.org> Assignee: IESG <iesg@ietf.org>
skipping to change at page 24, line 45 skipping to change at page 24, line 45
Description: Authentication, Accounting and Dynamic authorization Description: Authentication, Accounting and Dynamic authorization
via the RADIUS protocol. These service names are used to via the RADIUS protocol. These service names are used to
construct the SRV service labels "_radiustls" and "_radiusdtls" construct the SRV service labels "_radiustls" and "_radiusdtls"
for discovery of RADIUS/TLS and RADIUS/DTLS servers, respectively. for discovery of RADIUS/TLS and RADIUS/DTLS servers, respectively.
Reference: RFC Editor Note: please insert the RFC number of this Reference: RFC Editor Note: please insert the RFC number of this
document. The protocol does not use broadcast, multicast or document. The protocol does not use broadcast, multicast or
anycast communication. anycast communication.
This document requests the creation of a new IANA registry named This specification makes use of the SRV Protocol identifiers "_tcp"
"RADIUS/TLS SRV Protocol Registry" with the following initial and "_udp" which are mentioned as early as [RFC2782] but do not
entries: appear to be assigned in an actual registry. Since they are in wide-
spread use in other protocols, this specification refrains from
o _tcp requesting a new registry "RADIUS/TLS SRV Protocol Registry" and
continues to make use of these tags implicitly.
o _udp
This document requires that a number of Object Identifiers be This document requires that a number of Object Identifiers be
assigned. They re now under the control of IANA following [I-D assigned. They are now under the control of IANA following [RFC7299]
.housley-pkix-oids].
IANA is requested to assign the following identifiers: IANA is requested to assign the following identifiers:
TBD99 is to be assigned from the "SMI Security for PKIX Module TBD99 is to be assigned from the "SMI Security for PKIX Module
Identifier Registry". The suggested description is id-mod-nai- Identifier Registry". The suggested description is id-mod-nai-
realm-08. realm-08.
TBD98 is to be assigned from the "SMI Security for PKIX Other Name TBD98 is to be assigned from the "SMI Security for PKIX Other Name
Forms Registry." The suggested description is id-on-nai. Forms Registry." The suggested description is id-on-nai.
skipping to change at page 26, line 17 skipping to change at page 26, line 12
Infrastructure Certificate and Certificate Revocation List Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, May 2008. (CRL) Profile", RFC 5280, May 2008.
[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]
DeKok, A., "DTLS as a Transport Layer for RADIUS", draft-
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.
[RFC7360] DeKok, A., "Datagram Transport Layer Security (DTLS) as a
Transport Layer for RADIUS", RFC 7360, September 2014.
[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-05 (work in progress), November 2013. radext-nai-08 (work in progress), September 2014.
8.2. Informative References 8.2. Informative References
[RFC4017] Stanley, D., Walker, J., and B. Aboba, "Extensible [RFC4017] Stanley, D., Walker, J., and B. Aboba, "Extensible
Authentication Protocol (EAP) Method Requirements for Authentication Protocol (EAP) Method Requirements for
Wireless LANs", RFC 4017, March 2005. Wireless LANs", RFC 4017, March 2005.
[RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S.
Cheshire, "Internet Assigned Numbers Authority (IANA) Cheshire, "Internet Assigned Numbers Authority (IANA)
Procedures for the Management of the Service Name and Procedures for the Management of the Service Name and
Transport Protocol Port Number Registry", BCP 165, RFC Transport Protocol Port Number Registry", BCP 165, RFC
6335, August 2011. 6335, August 2011.
[RFC6733] Fajardo, V., Arkko, J., Loughney, J., and G. Zorn, [RFC6733] Fajardo, V., Arkko, J., Loughney, J., and G. Zorn,
"Diameter Base Protocol", RFC 6733, October 2012. "Diameter Base Protocol", RFC 6733, October 2012.
[RFC7299] Housley, R., "Object Identifier Registry for the PKIX
Working Group", RFC 7299, July 2014.
[I-D.wierenga-ietf-eduroam]
Wierenga, K., Winter, S., and T. Wolniewicz, "The eduroam
architecture for network roaming", draft-wierenga-ietf-
eduroam-04 (work in progress), August 2014.
Appendix A. Appendix A: ASN.1 Syntax of NAIRealm Appendix A. Appendix A: ASN.1 Syntax of NAIRealm
PKIXNaiRealm08 {iso(1) identified-organization(3) dod(6) PKIXNaiRealm08 {iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-nai-realm-08 (TBD99) } id-mod-nai-realm-08 (TBD99) }
DEFINITIONS EXPLICIT TAGS ::= DEFINITIONS EXPLICIT TAGS ::=
BEGIN BEGIN
 End of changes. 43 change blocks. 
69 lines changed or deleted 73 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/