--- 1/draft-ietf-radext-radsec-09.txt 2012-01-09 16:14:00.318671479 +0100 +++ 2/draft-ietf-radext-radsec-10.txt 2012-01-09 16:14:00.358671488 +0100 @@ -1,23 +1,23 @@ RADIUS Extensions Working Group S. Winter Internet-Draft RESTENA Intended status: Experimental M. McCauley -Expires: January 9, 2012 OSC +Expires: July 12, 2012 OSC S. Venaas UNINETT K. Wierenga Cisco - July 8, 2011 + January 9, 2012 TLS encryption for RADIUS - draft-ietf-radext-radsec-09 + draft-ietf-radext-radsec-10 Abstract This document specifies security on the transport layer (TLS) for the RADIUS protocol when transmitted over TCP. This enables dynamic trust relationships between RADIUS servers. Status of This Memo This Internet-Draft is submitted in full conformance with the @@ -26,25 +26,25 @@ 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 January 9, 2012. + This Internet-Draft will expire on July 12, 2012. Copyright Notice - Copyright (c) 2011 IETF Trust and the persons identified as the + Copyright (c) 2012 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 carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as @@ -78,23 +78,23 @@ 3.2. Ciphersuites and Compression Negotiation Considerations . 9 3.3. RADIUS Datagram Considerations . . . . . . . . . . . . . . 10 4. Compatibility with other RADIUS transports . . . . . . . . . . 11 5. Diameter Compatibility . . . . . . . . . . . . . . . . . . . . 11 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 9.1. Normative References . . . . . . . . . . . . . . . . . . . 13 9.2. Informative References . . . . . . . . . . . . . . . . . . 14 - Appendix A. Implementation Overview: Radiator . . . . . . . . . . 15 - Appendix B. Implementation Overview: radsecproxy . . . . . . . . 16 - Appendix C. Assessment of Crypto-Agility Requirements . . . . . . 17 + Appendix A. Implementation Overview: Radiator . . . . . . . . . . 16 + Appendix B. Implementation Overview: radsecproxy . . . . . . . . 17 + Appendix C. Assessment of Crypto-Agility Requirements . . . . . . 18 1. Introduction The RADIUS protocol [RFC2865] is a widely deployed authentication and authorisation protocol. The supplementary RADIUS Accounting specification [RFC2866] also provides accounting mechanisms, thus delivering a full AAA solution. However, RADIUS is experiencing several shortcomings, such as its dependency on the unreliable transport protocol UDP and the lack of security for large parts of its packet payload. RADIUS security is based on the MD5 algorithm, @@ -122,21 +122,21 @@ of overhead in terms of possible points of failure, longer transmission times as well as middleboxes through which authentication traffic flows. These middleboxes may learn privacy- relevant data while forwarding requests. The new features in RADIUS over TLS obsolete the use of IP addresses and shared MD5 secrets to identify other peers and thus allow the dynamic establishment of connections to peers that are not previously configured, and thus makes it possible to avoid aggregation-only RADIUS proxies and reduce the number of middleboxes which can eavesdrop on traffic. One mechanism to discover RADIUS over TLS peers with DNS is specified in - [I-D.winter-dynamic-discovery]. + [I-D.ietf-radext-dynamic-discovery]. 1.1. Requirements Language In this document, several words are used to signify the requirements of the specification. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. [RFC2119] 1.2. Terminology @@ -386,33 +386,33 @@ (2) If a RADIUS/TLS server is in possession of multiple certificates from different CAs (i.e. is part of multiple roaming consortia), it will need to select one of its certificates to present to the RADIUS/ TLS client. If the client sends the Trusted CA Indication, this hint can make the server select the appropriate certificate and prevent a handshake failure. Omitting this indication makes it impossible to deterministically select the right certificate in this case. If there is no risk of confusing multiple roaming consortia, providing this indication in the handshake is not crucial. - (3) If dynamic peer discovery as per [I-D.winter-dynamic-discovery] - is used, peer authentication alone is not sufficient; the peer must - also be authorised to perform user authentications. In these cases, - the trust fabric cannot depend on peer authentication methods like - DNSSEC to identify RADIUS/TLS nodes. The nodes also need to be - properly authorised. Typically, this can be achieved by adding - appropriate authorisation fields into a X.509 certificate. Such - fields include SRV authority [RFC4985], subjectAltNames, or a defined - list of certificate fingerprints. Operators of a RADIUS/TLS - infrastructure should define their own authorisation trust model and - apply this model to the certificates. The checks enumerated in - Section 2.3 provide sufficient flexibility for the implementation of - authorisation trust models. + (3) If dynamic peer discovery as per + [I-D.ietf-radext-dynamic-discovery] is used, peer authentication + alone is not sufficient; the peer must also be authorised to perform + user authentications. In these cases, the trust fabric cannot depend + on peer authentication methods like DNSSEC to identify RADIUS/TLS + nodes. The nodes also need to be properly authorised. Typically, + this can be achieved by adding appropriate authorisation fields into + a X.509 certificate. Such fields include SRV authority [RFC4985], + subjectAltNames, or a defined list of certificate fingerprints. + Operators of a RADIUS/TLS infrastructure should define their own + authorisation trust model and apply this model to the certificates. + The checks enumerated in Section 2.3 provide sufficient flexibility + for the implementation of authorisation trust models. 3.2. Ciphersuites and Compression Negotiation Considerations Not all TLS ciphersuites in [RFC5246] are supported by available TLS tool kits, and licenses may be required in some cases. The existing implementations of RADIUS/TLS use OpenSSL as cryptographic backend, which supports all of the ciphersuites listed in the rules in the normative section. The TLS ciphersuite TLS_RSA_WITH_3DES_EDE_CBC_SHA is mandatory-to- @@ -516,43 +516,44 @@ 6. Security Considerations The computational resources to establish a TLS tunnel are significantly higher than simply sending mostly unencrypted UDP datagrams. Therefore, clients connecting to a RADIUS/TLS node will more easily create high load conditions and a malicious client might create a Denial-of-Service attack more easily. In the case of dynamic peer discovery as per - [I-D.winter-dynamic-discovery], a RADIUS/TLS node needs to be able to - accept connections from a large, not previously known, group of - hosts, possibly the whole internet. In this case, the server's + [I-D.ietf-radext-dynamic-discovery], a RADIUS/TLS node needs to be + able to accept connections from a large, not previously known, group + of hosts, possibly the whole internet. In this case, the server's RADIUS/TLS port can not be protected from unauthorised connection attempts with measures on the network layer, i.e. access lists and firewalls. This opens more attack vectors for Distributed Denial of Service attacks, just like any other service that is supposed to serve arbitrary clients (like for example web servers). In the case of dynamic peer discovery as per - [I-D.winter-dynamic-discovery], X.509 certificates are the only proof - of authorisation for a connecting RADIUS/TLS nodes. Special care - needs to be taken that certificates get verified properly according - to the chosen trust model (particularly: consulting CRLs, checking - critical extensions, checking subjectAltNames etc.) to prevent - unauthorised connections. + [I-D.ietf-radext-dynamic-discovery], X.509 certificates are the only + proof of authorisation for a connecting RADIUS/TLS nodes. Special + care needs to be taken that certificates get verified properly + according to the chosen trust model (particularly: consulting CRLs, + checking critical extensions, checking subjectAltNames etc.) to + prevent unauthorised connections. Some TLS ciphersuites only provide integrity validation of their payload, and provide no encryption. This specification forbids the use of such ciphersuites. Since the RADIUS payload's shared secret - is fixed and well-known, failure to comply with this requirement will - expose the entire datagram payload in plain text, including User- - Password, to intermediate IP nodes. + is fixed to the well-known term "radsec" (see Section 2.3 (4) ) , + failure to comply with this requirement will expose the entire + datagram payload in plain text, including User-Password, to + intermediate IP nodes. If peer communication between two devices is configured for both RADIUS/TLS and RADIUS/UDP, a failover from TLS security to classic RADIUS security opens the way for a down-bidding attack if an adversary can maliciously close the TCP connection, or prevent it from being established. In this case, security of the packet payload is reduced from the selected TLS cipher suite packet encryption to the classic MD5 per-attribute encryption. Such an attack can be mitigated by delisting the RADIUS/UDP client from the server configuration after successfully migrating that client to RADIUS/TLS. @@ -580,130 +581,142 @@ Funding and input for the development of this Internet Draft was provided by the European Commission co-funded project "GEANT2" [geant2] and further feedback was provided by the TERENA Task Force Mobility [terena]. 9. References 9.1. Normative References - [RFC2119] Bradner, S., "Key words for use in - RFCs to Indicate Requirement + [RFC2119] Bradner, S., "Key words for use + in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. - [RFC2865] Rigney, C., Willens, S., Rubens, A., - and W. Simpson, "Remote - Authentication Dial In User Service - (RADIUS)", RFC 2865, June 2000. + [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. - [RFC4279] Eronen, P. and H. Tschofenig, "Pre- - Shared Key Ciphersuites for + [RFC4279] Eronen, P. and H. Tschofenig, + "Pre-Shared Key Ciphersuites for Transport Layer Security (TLS)", RFC 4279, December 2005. - [RFC4785] Blumenthal, U. and P. Goel, "Pre- - Shared Key (PSK) Ciphersuites with - NULL Encryption for Transport Layer + [RFC4785] Blumenthal, U. and P. Goel, + "Pre-Shared Key (PSK) + Ciphersuites with NULL + Encryption for Transport Layer Security (TLS)", RFC 4785, January 2007. [RFC4985] Santesson, S., "Internet X.509 - Public Key Infrastructure Subject - Alternative Name for Expression of - Service Name", RFC 4985, - August 2007. + Public Key Infrastructure + Subject Alternative Name for + Expression of Service Name", + RFC 4985, August 2007. - [RFC5280] Cooper, D., Santesson, S., Farrell, - S., Boeyen, S., Housley, R., and W. - Polk, "Internet X.509 Public Key + [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. + Certificate Revocation List + (CRL) Profile", RFC 5280, + May 2008. - [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. + [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. [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008. - [RFC5247] Aboba, B., Simon, D., and P. Eronen, - "Extensible Authentication Protocol - (EAP) Key Management Framework", + [RFC5247] Aboba, B., Simon, D., and P. + Eronen, "Extensible + Authentication Protocol (EAP) + Key Management Framework", RFC 5247, August 2008. - [I-D.ietf-radext-tcp-transport] DeKok, A., "RADIUS Over TCP", - draft-ietf-radext-tcp-transport-09 - (work in progress), October 2010. + [I-D.ietf-radext-tcp-transport] DeKok, A., "RADIUS Over TCP", dr + aft-ietf-radext-tcp-transport-09 + (work in progress), + October 2010. 9.2. Informative References [I-D.ietf-radext-dtls] DeKok, A., "DTLS as a Transport Layer for RADIUS", - draft-ietf-radext-dtls-01 (work in - progress), October 2010. + draft-ietf-radext-dtls-01 (work + in progress), October 2010. - [I-D.winter-dynamic-discovery] Winter, S. and M. McCauley, "NAI- - based Dynamic Peer Discovery for - RADIUS over TLS and DTLS", - draft-winter-dynamic-discovery-00 - (work in progress), February 2009. + [I-D.ietf-radext-dynamic-discovery] Winter, S. and M. McCauley, + "NAI-based Dynamic Peer + Discovery for RADIUS/TLS and + RADIUS/DTLS", draft-ietf-radext- + dynamic-discovery-03 (work in + progress), July 2011. - [RFC3588] Calhoun, P., Loughney, J., Guttman, - E., Zorn, G., and J. Arkko, - "Diameter Base Protocol", RFC 3588, - September 2003. + [RFC3588] Calhoun, P., Loughney, J., + Guttman, E., Zorn, G., and J. + Arkko, "Diameter Base Protocol", + RFC 3588, September 2003. [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006. - [radsec-whitepaper] Open System Consultants, "RadSec - a - secure, reliable RADIUS Protocol", - May 2005, . + [radsec-whitepaper] Open System Consultants, "RadSec + - a secure, reliable RADIUS + Protocol", May 2005, . [MD5-attacks] Black, J., Cochran, M., and T. Highland, "A Study of the MD5 - Attacks: Insights and Improvements", - October 2006, . + Attacks: Insights and + Improvements", October 2006, . [radsecproxy-impl] Venaas, S., "radsecproxy Project Homepage", 2007, . + software.uninett.no/ + radsecproxy/>. [eduroam] Trans-European Research and - Education Networking Association, - "eduroam Homepage", 2007, - . + Education Networking + Association, "eduroam Homepage", + 2007, . [geant2] Delivery of Advanced Network Technology to Europe, "European - Commission Information Society and - Media: GEANT2", 2008, + Commission Information Society + and Media: GEANT2", 2008, . - [terena] TERENA, "Trans-European Research and - Education Networking Association", - 2008, . + [terena] TERENA, "Trans-European Research + and Education Networking + Association", 2008, + . Appendix A. Implementation Overview: Radiator Radiator implements the RadSec protocol for proxying requests with the and clauses in the Radiator configuration file. The clause defines a RadSec client, and causes Radiator to send RADIUS requests to the configured RadSec server using the RadSec protocol.