--- 1/draft-ietf-radext-dynamic-discovery-13.txt 2015-04-10 00:14:54.129776635 -0700 +++ 2/draft-ietf-radext-dynamic-discovery-14.txt 2015-04-10 00:14:54.185777975 -0700 @@ -1,19 +1,19 @@ RADIUS Extensions Working Group S. Winter Internet-Draft RESTENA Intended status: Experimental M. McCauley -Expires: September 7, 2015 AirSpayce - March 06, 2015 +Expires: October 12, 2015 AirSpayce + April 10, 2015 NAI-based Dynamic Peer Discovery for RADIUS/TLS and RADIUS/DTLS - draft-ietf-radext-dynamic-discovery-13 + draft-ietf-radext-dynamic-discovery-14 Abstract This document specifies a means to find authoritative RADIUS servers for a given realm. It is used in conjunction with either RADIUS/TLS and RADIUS/DTLS. Status of This Memo This Internet-Draft is submitted in full conformance with the @@ -22,21 +22,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on September 7, 2015. + This Internet-Draft will expire on October 12, 2015. Copyright Notice Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -205,25 +205,21 @@ 1.2. Terminology RADIUS/TLS Client: a RADIUS/TLS [RFC6614] instance which initiates a new connection. RADIUS/TLS Server: a RADIUS/TLS [RFC6614] instance which listens on a RADIUS/TLS port and accepts new connections RADIUS/TLS node: a RADIUS/TLS client or server - [RFC4282] and its designated successor [I-D.ietf-radext-nai] define - 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. + [I-D.ietf-radext-nai] defines the terms NAI, realm, consortium. 1.3. Document Status This document is an Experimental RFC. The communities expected to use this document are roaming consortia whose authentication services are based on the RADIUS protocol. The duration of the experiment is undetermined; as soon as enough experience is collected on the choice points mentioned below, it is @@ -237,21 +233,21 @@ The document provides a discovery mechanism for RADIUS which is very similar to the approach that is taken with the Diameter protocol [RFC6733]. As such, the basic approach (using Naming Authority Pointer (NAPTR) records in DNS domains which match NAI realms) is not of very experimental nature. However, the document offers a few choice points and extensions which go beyond the provisions for Diameter. The list of major additions/ 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) o much more in-depth guidance on DNS regarding timeouts, failure conditions, alteration of Time-To-Live (TTL) information than the Diameter counterpart o a partially correct routing error detection during DNS lookups 2. Definitions @@ -293,21 +289,21 @@ | - - - - - - - - | - - - - - - - - - - - - - - - - - - - - | | radius.dtls.udp | RADIUS transported over DTLS as defined | | | in [RFC7360] | +-----------------+-----------------------------------------+ Figure 4: List of Protocol Tags Note well: 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 human reading convenience - not for structure or namespacing; it MUST NOT be parsed in any way by the querying application or resolver. The use of the separator '.' is common also in other protocols' protocol tags. This is coincidence and does not imply a shared semantics with such protocols. @@ -331,39 +327,42 @@ instantly, it is not eligible for retry. Furthermore, the contacted RADIUS/TLS server verifies during connection setup whether or not it finds the connecting RADIUS/TLS client authorized or not. If the connecting RADIUS/TLS client is not found acceptable, the server will close the TLS connection immediately with an appropriate alert. Such TLS handshake failures 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. + 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, that target (as identified by IP address and port number) SHOULD be ignored from the result set of any subsequent executions of the - discovery algorithm at least until the target's Effective TTL has - expired or until the entity which executes the algorithm changes its - TLS context to either send a new client certificate or expect a - different server certificate. + discovery algorithm at least until the target's Effective TTL (see + Section 3.3) has expired or until the entity which executes the + algorithm changes its TLS context to either send a new client + certificate or expect a different server certificate. 2.1.1.3. Server Identification and Handshake After the algorithm in this document has been executed, a RADIUS/TLS session as per [RFC6614] is established. Since the dynamic discovery algorithm does not have provisions to establish confidential keying material between the RADIUS/TLS client (i.e. the server which executes the discovery algorithm) and the RADIUS/TLS server which was - discovered, TLS-PKS ciphersuites cannot be used for in the subsequent - TLS handshake. Only TLS ciphersuites using X.509 certificates can be + discovered, TLS-PSK ciphersuites cannot be used in the subsequent TLS + handshake. Only TLS ciphersuites using X.509 certificates can be used with this algorithm. There are numerous ways to define which certificates are acceptable for use in this context. This document defines one mandatory-to- implement mechanism which allows to verify whether the contacted host is authoritative for an NAI realm or not. It also gives one example of another mechanism which is currently in wide-spread deployment, and one possible approach based on DNSSEC which is yet unimplemented. For the approaches which use trust roots (see the following two @@ -435,29 +434,32 @@ (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 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 realm that triggered the discovery is actually served by the server that was discovered via DNS. However, this does not guarantee that 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 - DANE/TLSA records of all authorized servers are put into a DNSSEC - zone with a common, consortium-specific branch of the DNS tree, then - the entity executing the algorithm can retrieve TLSA Resource Records - (TLSA RR) for the label "realm.commonroot" and verify that the - presented server certificate during the RADIUS/TLS handshake matches - the information in the TLSA record. + The authorization can be sketched using DNSSEC+DANE as follows: DANE/ + TLSA records of all authorized servers are put into a DNSSEC zone + which contains all known and authorised realms; the zone is rooted in + a common, consortium-agreed branch of the DNS tree. The entity + executing the algorithm uses the realm information from the + authentication attempt, and then attempts to retrieve TLSA Resource + 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: Realm = "example.com" Common Branch = "idp.roaming-consortium.example. label for TLSA query = "example.com.idp.roaming- consortium.example. @@ -474,29 +476,29 @@ algorithm for a RADIUS client to contact and verify authorization of a RADIUS server only. During connection setup, the RADIUS server also needs to verify whether it considers the connecting RADIUS client authorized; this is outside the scope of this specification. 2.1.2. SRV This specification defines two SRV prefixes (i.e. two values for the "_service._proto" part of an SRV RR as per [RFC2782]): - +-----------------+-----------------------------------------+ + +-------------------+-----------------------------------------+ | SRV Label | Use | - +-----------------+-----------------------------------------+ + +-------------------+-----------------------------------------+ | _radiustls._tcp | RADIUS transported over TLS as defined | | | in [RFC6614] | - | - - - - - - - - | - - - - - - - - - - - - - - - - - - - - | - | _radiustls._udp | RADIUS transported over DTLS as defined | + | - - - - - - - - - | - - - - - - - - - - - - - - - - - - - - | + | _radiusdtls._udp | RADIUS transported over DTLS as defined | | | in [RFC7360] | - +-----------------+-----------------------------------------+ + +-------------------+-----------------------------------------+ Figure 5: List of SRV Labels Just like NAPTR records, the lookup and subsequent follow-up of SRV records may yield more than one server to contact in a prioritised list. [RFC2782] does not specify rules regarding "Definition of Conditions for Retry/Failure", nor "Server Identification and 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 used both for targets retrieved via an initial NAPTR RR as well as @@ -530,56 +532,56 @@ radsec.example.com. b. The consortium "foo" provides roaming services for its members only. The realms used are of the form enterprise-name.example. The consortium operates a special purpose DNS server for the (private) TLD "example" which all RADIUS servers use to resolve realm names. "Company, Inc." is part of the consortium. On the consortium's DNS server, realm company.example might have the following DNS entries: - company.example IN NAPTR 50 50 "a" "aaa+auth:radius.dtls.udp" - "" roamserv.company.example + company.example. IN NAPTR 50 50 "a" + "aaa+auth:radius.dtls.udp" "" roamserv.company.example. c. The eduroam consortium (see [I-D.wierenga-ietf-eduroam] uses realms based on DNS, but provides its services to a closed community only. However, a AAA domain participating in eduroam may also want to expose AAA services to other, general-purpose, applications (on the same or other RADIUS servers). Due to that, the eduroam consortium uses the service tag "x-eduroam" for authentication purposes and eduroam RADIUS servers use this tag to look up other eduroam servers. An eduroam participant example.org which also provides general-purpose AAA on a different server uses the general "aaa+auth" tag: example.org. IN NAPTR 50 50 "s" "x-eduroam:radius.tls.tcp" "" _radiustls._tcp.eduroam.example.org. 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- eduroam.example.org. _radiustls._tcp.aaa.example.org. IN SRV 0 10 2083 aaa- default.example.org. 2.2. Definition of the X.509 certificate property SubjectAltName:otherName:NAIRealm This specification retrieves IP addresses and port numbers from the Domain Name System which are subsequently used to authenticate users - via the RADIUS/TLS protocol. Since the Domain Name System is not - necessarily trustworthy (e.g. if DNSSEC is not deployed for the - queried domain name), it is important to verify that the server which - was contacted is authorized to service requests for the user which - triggered the discovery process. + via the RADIUS/TLS protocol. Regardless whether the results from DNS + discovery are trustworthy or not (e.g. DNSSEC in use), it is always + important to verify that the server which was contacted is authorized + to service requests for the user which triggered the discovery + process. 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 which is ultimately contacted for user authentication needs to be able to express that it is authorized to handle requests for that realm. Current subjectAltName fields do not semantically allow to express an NAI realm; the field subjectAltName:dNSName is syntactically a good match but would inappropriately conflate DNS names and NAI realm @@ -605,25 +607,25 @@ makes subjectAltName:otherName:sRVName unsuited for this purpose. This section defines the NAIRealm name as a form of otherName from the GeneralName structure in SubjectAltName defined in [RFC5280]. id-on-nai OBJECT IDENTIFIER ::= { id-on XXX } NAIRealm ::= UTF8String (SIZE (1..MAX)) 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- - separated part of the NAI with the single character "*" to indicate a - wildcard match for "all labels in this part". Further features of - regular expressions, such as a number of characters followed by a * - to indicate a common prefix inside the part, are not permitted. + [I-D.ietf-radext-nai]. It MAY substitute the leftmost dot-separated + label of the NAI with the single character "*" to indicate a wildcard + match for "all labels in this part". Further features of regular + expressions, such as a number of characters followed by a * to + indicate a common prefix inside the part, are not permitted. 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 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. @@ -889,21 +891,21 @@ it is safe to rely on the results of the name resolution. If these TTLs are very low, thrashing of connections becomes possible; the Effective TTL mitigates that risk. When a connection is open and the smallest of the Effective TTL value which was learned during discovering the server has not expired, subsequent new user sessions for the realm which corresponds to that open connection SHOULD re-use the existing connection and SHOULD NOT re-execute the dynamic discovery algorithm nor open a new connection. To allow for a change of configuration, a RADIUS server SHOULD re-execute the dynamic 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 of the connection should the result not have changed. Should the algorithm above terminate with O-1 = empty set, the RADIUS server SHOULD NOT attempt another execution of this algorithm for the same target realm before the timeout O-2 has passed. 3.4.5. Delay considerations The host's name resolution library may need to contact outside @@ -1063,25 +1065,25 @@ A roaming consortium's roaming agreement must include a profile of 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 interoperate based on that choice; this per-consortium interoperability is the intended scope of this document. 5. Security Considerations When using DNS without DNSSEC security extensions and validation for all of the replies to NAPTR, SRV and A/AAAA requests as described in - section Section 3, the result O can not be trusted. Even if it can - be trusted (i.e. DNSSEC is in use), actual authorization of the - discovered server to provide service for the given realm needs to be - verified. A mechanism from section Section 2.1.1.3 or equivalent - MUST be used to verify authorization. + section Section 3, the result of the discovery process can not be + trusted. Even if it can be trusted (i.e. DNSSEC is in use), actual + authorization of the discovered server to provide service for the + given realm needs to be verified. A mechanism from section + Section 2.1.1.3 or equivalent MUST be used to verify authorization. The algorithm has a configurable completion timeout DNS_TIMEOUT defaulting to three seconds for RADIUS' operational reasons. The lookup of DNS resource records based on unverified user input is an 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 particularly byzantine tree structure, or artificial delays in responses). To mitigate this DoS vector, implementations SHOULD consider rate- @@ -1207,21 +1209,21 @@ * radius.tls.tcp * radius.dtls.udp This document reserves the use of the "radiustls" and "radiusdtls" service names. Registration information as per [RFC6335] section 8.1.1 is as follows: Service Name: radiustls; radiusdtls - Transport Protocols: TCP, UDP + Transport Protocols: TCP (for radiustls), UDP (for radiusdtls) Assignee: IESG Contact: IETF Chair Description: Authentication, Accounting and Dynamic authorization via the RADIUS protocol. These service names are used to construct the SRV service labels "_radiustls" and "_radiusdtls" for discovery of RADIUS/TLS and RADIUS/DTLS servers, respectively. @@ -1265,23 +1267,20 @@ [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. [RFC3958] Daigle, L. and A. Newton, "Domain-Based Application Service Location Using SRV RRs and the Dynamic Delegation 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. Aboba, "Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS)", RFC 5176, January 2008. [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008. @@ -1317,21 +1316,21 @@ [RFC6733] Fajardo, V., Arkko, J., Loughney, J., and G. Zorn, "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. + eduroam-05 (work in progress), March 2015. Appendix A. Appendix A: ASN.1 Syntax of NAIRealm PKIXNaiRealm08 {iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-nai-realm-08 (TBD99) } DEFINITIONS EXPLICIT TAGS ::= BEGIN