draft-ietf-radext-dynamic-discovery-13.txt   draft-ietf-radext-dynamic-discovery-14.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 7, 2015 AirSpayce Expires: October 12, 2015 AirSpayce
March 06, 2015 April 10, 2015
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-13 draft-ietf-radext-dynamic-discovery-14
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 7, 2015. This Internet-Draft will expire on October 12, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 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 6, line 15 skipping to change at page 6, line 15
1.2. Terminology 1.2. Terminology
RADIUS/TLS Client: a RADIUS/TLS [RFC6614] instance which initiates a RADIUS/TLS Client: a RADIUS/TLS [RFC6614] instance which initiates a
new connection. new connection.
RADIUS/TLS Server: a RADIUS/TLS [RFC6614] instance which listens on a RADIUS/TLS Server: a RADIUS/TLS [RFC6614] instance which listens on a
RADIUS/TLS port and accepts new connections RADIUS/TLS port and accepts new connections
RADIUS/TLS node: a RADIUS/TLS client or server RADIUS/TLS node: a RADIUS/TLS client or server
[RFC4282] and its designated successor [I-D.ietf-radext-nai] define [I-D.ietf-radext-nai] defines the terms NAI, realm, consortium.
the terms NAI, realm, consortium. RFC Editor Note: please remove the
RFC4282 reference here and in the Normative References section prior
to publication and replace the draft NAI spec with its then-allocated
RFC number.
1.3. Document Status 1.3. Document Status
This document is an Experimental RFC. This document is an Experimental RFC.
The communities expected to use this document are roaming consortia The communities expected to use this document are roaming consortia
whose authentication services are based on the RADIUS protocol. whose authentication services are based on the RADIUS protocol.
The duration of the experiment is undetermined; as soon as enough The duration of the experiment is undetermined; as soon as enough
experience is collected on the choice points mentioned below, it is experience is collected on the choice points mentioned below, it is
skipping to change at page 6, line 47 skipping to change at page 6, line 43
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 Naming Authority [RFC6733]. As such, the basic approach (using Naming Authority
Pointer (NAPTR) records in DNS domains which match NAI realms) is not Pointer (NAPTR) records in DNS domains which match NAI realms) is not
of very experimental nature. 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 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 Time-To-Live (TTL) information than the conditions, alteration of Time-To-Live (TTL) information than the
Diameter counterpart Diameter counterpart
o a partially correct routing error detection during DNS lookups o a partially correct routing error detection during DNS lookups
2. Definitions 2. Definitions
skipping to change at page 8, line 8 skipping to change at page 8, line 6
| - - - - - - - - | - - - - - - - - - - - - - - - - - - - - | | - - - - - - - - | - - - - - - - - - - - - - - - - - - - - |
| radius.dtls.udp | RADIUS transported over DTLS as defined | | radius.dtls.udp | RADIUS transported over DTLS as defined |
| | in [RFC7360] | | | in [RFC7360] |
+-----------------+-----------------------------------------+ +-----------------+-----------------------------------------+
Figure 4: List of Protocol Tags Figure 4: 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
human reading convenience - not for structure or namespacing; it human reading convenience - not for structure or namespacing; it
MUST NOT be parsed in any way by the querying application or MUST NOT be parsed in any way by the querying application or
resolver. resolver.
The use of the separator '.' is common also in other protocols' The use of the separator '.' is common also in other protocols'
protocol tags. This is coincidence and does not imply a shared protocol tags. This is coincidence and does not imply a shared
semantics with such protocols. semantics with such protocols.
skipping to change at page 8, line 46 skipping to change at page 8, line 44
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, unless the are permanently fatal and not eligible for retry, unless the
connecting client has more X.509 certificates to try; in this case, a connecting client has more X.509 certificates to try; in this case, a
retry with the remainder of its set of certificates SHOULD be retry with the remainder of its set of certificates SHOULD be
attempted. attempted. Not trying all available client certificates potentially
creates a DoS for the end-user whose authentication attempt triggered
the discovery; one of the neglected certificates might have led to a
successful RADIUS connection and subsequent end-user authentication.
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 (see
expired or until the entity which executes the algorithm changes its Section 3.3) has expired or until the entity which executes the
TLS context to either send a new client certificate or expect a algorithm changes its TLS context to either send a new client
different server certificate. certificate or expect a 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 discovery 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-PSK ciphersuites cannot be used in the subsequent TLS
TLS handshake. Only TLS ciphersuites using X.509 certificates can be 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 an 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.
For the approaches which use trust roots (see the following two For the approaches which use trust roots (see the following two
skipping to change at page 11, line 5 skipping to change at page 11, line 6
(other RADIUS attributes pertaining to the authentication, such as (other RADIUS attributes pertaining to the authentication, such as
the EAP peer's Calling-Station-ID, can still be learned though). 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). The server still needs to present an X.509
certificate proving its authority to serve a particular realm.
The authorization can be sketched using DNSSEC+DANE as follows: if The authorization can be sketched using DNSSEC+DANE as follows: DANE/
DANE/TLSA records of all authorized servers are put into a DNSSEC TLSA records of all authorized servers are put into a DNSSEC zone
zone with a common, consortium-specific branch of the DNS tree, then which contains all known and authorised realms; the zone is rooted in
the entity executing the algorithm can retrieve TLSA Resource Records a common, consortium-agreed branch of the DNS tree. The entity
(TLSA RR) for the label "realm.commonroot" and verify that the executing the algorithm uses the realm information from the
presented server certificate during the RADIUS/TLS handshake matches authentication attempt, and then attempts to retrieve TLSA Resource
the information in the TLSA record. Records (TLSA RR) for the DNS label "realm.commonroot". It then
verifies that the presented server certificate during the RADIUS/TLS
handshake matches 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 12, line 5 skipping to change at page 12, line 5
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
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 | | _radiusdtls._udp | RADIUS transported over DTLS as defined |
| | in [RFC7360] | | | in [RFC7360] |
+-----------------+-----------------------------------------+ +-------------------+-----------------------------------------+
Figure 5: List of SRV Labels Figure 5: 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
skipping to change at page 13, line 13 skipping to change at page 13, line 13
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.udp" company.example. IN NAPTR 50 50 "a"
"" roamserv.company.example "aaa+auth:radius.dtls.udp" "" roamserv.company.example.
c. The eduroam consortium (see [I-D.wierenga-ietf-eduroam] uses c. The eduroam consortium (see [I-D.wierenga-ietf-eduroam] uses
realms based on DNS, but provides its services to a closed realms based on DNS, but provides its services to a closed
community only. However, a AAA domain participating in eduroam community only. However, a AAA domain participating in eduroam
may also want to expose AAA services to other, general-purpose, may also want to expose AAA services to other, general-purpose,
applications (on the same or other RADIUS servers). Due to that, applications (on the same or other RADIUS servers). Due to that,
the eduroam consortium uses the service tag "x-eduroam" for the eduroam consortium uses the service tag "x-eduroam" for
authentication purposes and eduroam RADIUS servers use this tag authentication purposes and eduroam RADIUS servers use this tag
to look up other eduroam servers. An eduroam participant to look up other eduroam servers. An eduroam participant
example.org which also provides general-purpose AAA on a example.org which also provides general-purpose AAA on a
different server uses the general "aaa+auth" tag: different server uses the general "aaa+auth" tag:
example.org. IN NAPTR 50 50 "s" "x-eduroam:radius.tls.tcp" "" 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.tcp" "" 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. Regardless whether the results from DNS
necessarily trustworthy (e.g. if DNSSEC is not deployed for the discovery are trustworthy or not (e.g. DNSSEC in use), it is always
queried domain name), it is important to verify that the server which important to verify that the server which was contacted is authorized
was contacted is authorized to service requests for the user which to service requests for the user which triggered the discovery
triggered the discovery process. process.
The input to the algorithm is an 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
skipping to change at page 14, line 39 skipping to change at page 14, line 39
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 the leftmost dot-separated
separated part of the NAI with the single character "*" to indicate a label of the NAI with the single character "*" to indicate a wildcard
wildcard match for "all labels in this part". Further features of match for "all labels in this part". Further features of regular
regular expressions, such as a number of characters followed by a * expressions, such as a number of characters followed by a * to
to indicate a common prefix inside the part, are not permitted. indicate a common prefix inside the part, are not permitted.
The comparison of an 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.
skipping to change at page 20, line 37 skipping to change at page 20, line 37
it is safe to rely on the results of the name resolution. If these it is safe to rely on the results of the name resolution. If these
TTLs are very low, thrashing of connections becomes possible; the TTLs are very low, thrashing of connections becomes possible; the
Effective TTL mitigates that risk. When a connection is open and the Effective TTL mitigates that risk. When a connection is open and the
smallest of the Effective TTL value which was learned during smallest of the Effective TTL value which was learned during
discovering the server has not expired, subsequent new user sessions discovering the server has not expired, subsequent new user sessions
for the realm which corresponds to that open connection SHOULD re-use for the realm which corresponds to that open connection SHOULD re-use
the existing connection and SHOULD NOT re-execute the dynamic the existing connection and SHOULD NOT re-execute the dynamic
discovery algorithm nor open a new connection. To allow for a change discovery algorithm nor open a new connection. To allow for a change
of configuration, a RADIUS server SHOULD re-execute the dynamic of configuration, a RADIUS server SHOULD re-execute the dynamic
discovery algorithm after the Effective TTL that is associated with discovery algorithm after the Effective TTL that is associated with
this connection has expired. The server MAY keep the session open this connection has expired. The server SHOULD keep the session open
during this re-assessment to avoid closure and immediate re-opening during this re-assessment to avoid closure and immediate re-opening
of the connection should the result not have changed. of the connection should the result not have changed.
Should the algorithm above terminate with O-1 = empty set, the RADIUS Should the algorithm above terminate with O-1 = empty set, the RADIUS
server SHOULD NOT attempt another execution of this algorithm for the server SHOULD NOT attempt another execution of this algorithm for the
same target realm before the timeout O-2 has passed. same target realm before the timeout O-2 has passed.
3.4.5. Delay considerations 3.4.5. Delay considerations
The host's name resolution library may need to contact outside The host's name resolution library may need to contact outside
skipping to change at page 24, line 22 skipping to change at page 24, line 22
A roaming consortium's roaming agreement must include a profile of A roaming consortium's roaming agreement must include a profile of
which choice points of this document to use. So long as the roaming which choice points of this document to use. So long as the roaming
consortium can settle on one deployment profile, they will be able to consortium can settle on one deployment profile, they will be able to
interoperate based on that choice; this per-consortium interoperate based on that choice; this per-consortium
interoperability is the intended scope of this document. interoperability is the intended scope of this document.
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 of the discovery process can not be
be trusted (i.e. DNSSEC is in use), actual authorization of the trusted. Even if it can be trusted (i.e. DNSSEC is in use), actual
discovered server to provide service for the given realm needs to be authorization of the discovered server to provide service for the
verified. A mechanism from section Section 2.1.1.3 or equivalent given realm needs to be verified. A mechanism from section
MUST be used to verify authorization. Section 2.1.1.3 or equivalent MUST be used to verify authorization.
The algorithm has a configurable completion timeout 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-
skipping to change at page 27, line 22 skipping to change at page 27, line 22
* radius.tls.tcp * radius.tls.tcp
* radius.dtls.udp * 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 (for radiustls), UDP (for radiusdtls)
Assignee: IESG <iesg@ietf.org> Assignee: IESG <iesg@ietf.org>
Contact: IETF Chair <chair@ietf.org> Contact: IETF Chair <chair@ietf.org>
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.
skipping to change at page 28, line 32 skipping to change at page 28, line 32
[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
2865, June 2000. 2865, June 2000.
[RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
[RFC3958] Daigle, L. and A. Newton, "Domain-Based Application [RFC3958] Daigle, L. and A. Newton, "Domain-Based Application
Service Location Using SRV RRs and the Dynamic Delegation Service Location Using SRV RRs and the Dynamic Delegation
Discovery Service (DDDS)", RFC 3958, January 2005. Discovery Service (DDDS)", RFC 3958, January 2005.
[RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The
Network Access Identifier", RFC 4282, December 2005.
[RFC5176] Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B. [RFC5176] Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B.
Aboba, "Dynamic Authorization Extensions to Remote Aboba, "Dynamic Authorization Extensions to Remote
Authentication Dial In User Service (RADIUS)", RFC 5176, Authentication Dial In User Service (RADIUS)", RFC 5176,
January 2008. January 2008.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, May 2008. (CRL) Profile", RFC 5280, May 2008.
skipping to change at page 29, line 37 skipping to change at page 29, line 33
[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 [RFC7299] Housley, R., "Object Identifier Registry for the PKIX
Working Group", RFC 7299, July 2014. Working Group", RFC 7299, July 2014.
[I-D.wierenga-ietf-eduroam] [I-D.wierenga-ietf-eduroam]
Wierenga, K., Winter, S., and T. Wolniewicz, "The eduroam Wierenga, K., Winter, S., and T. Wolniewicz, "The eduroam
architecture for network roaming", draft-wierenga-ietf- architecture for network roaming", draft-wierenga-ietf-
eduroam-04 (work in progress), August 2014. eduroam-05 (work in progress), March 2015.
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. 21 change blocks. 
59 lines changed or deleted 58 lines changed or added

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