--- 1/draft-ietf-radext-radsec-07.txt 2011-03-14 10:15:11.000000000 +0100 +++ 2/draft-ietf-radext-radsec-08.txt 2011-03-14 10:15:11.000000000 +0100 @@ -1,23 +1,23 @@ RADIUS Extensions Working Group S. Winter Internet-Draft RESTENA Intended status: Experimental M. McCauley -Expires: January 13, 2011 OSC +Expires: September 15, 2011 OSC S. Venaas UNINETT K. Wierenga Cisco - July 12, 2010 + March 14, 2011 TLS encryption for RADIUS - draft-ietf-radext-radsec-07 + draft-ietf-radext-radsec-08 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 13, 2011. + This Internet-Draft will expire on September 15, 2011. Copyright Notice - Copyright (c) 2010 IETF Trust and the persons identified as the + Copyright (c) 2011 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 @@ -60,40 +60,40 @@ outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 - 2. Normative: Transport Layer Security for RADIUS over TCP . . . 4 + 2. Normative: Transport Layer Security for RADIUS/TCP . . . . . . 4 2.1. TCP port and packet types . . . . . . . . . . . . . . . . 4 2.2. TLS negotiation . . . . . . . . . . . . . . . . . . . . . 4 2.3. Connection Setup . . . . . . . . . . . . . . . . . . . . . 4 2.4. Connecting Client Identity . . . . . . . . . . . . . . . . 6 2.5. RADIUS Datagrams . . . . . . . . . . . . . . . . . . . . . 7 3. Informative: Design Decisions . . . . . . . . . . . . . . . . 8 3.1. X.509 Certificate Considerations . . . . . . . . . . . . . 8 3.2. Ciphersuites and Compression Negotiation Considerations . 9 3.3. RADIUS Datagram Considerations . . . . . . . . . . . . . . 9 - 4. Compatibility with other RADIUS transports . . . . . . . . . . 10 + 4. Compatibility with other RADIUS transports . . . . . . . . . . 11 5. Diameter Compatibility . . . . . . . . . . . . . . . . . . . . 11 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 - 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 - 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 - 9.1. Normative References . . . . . . . . . . . . . . . . . . . 12 - 9.2. Informative References . . . . . . . . . . . . . . . . . . 13 - Appendix A. Implementation Overview: Radiator . . . . . . . . . . 14 - Appendix B. Implementation Overview: radsecproxy . . . . . . . . 15 + 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 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, @@ -127,59 +127,67 @@ 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]. 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", "MAY", - and "OPTIONAL" in this document are to be interpreted as described in - RFC 2119. [RFC2119] + "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 RADIUS/TLS node: a RADIUS over TLS client or server RADIUS/TLS Client: a RADIUS over TLS instance which initiates a new connection. RADIUS/TLS Server: a RADIUS over TLS instance which listens on a RADIUS over TLS port and accepts new connections RADIUS/UDP: classic RADIUS transport over UDP as defined in [RFC2865] -2. Normative: Transport Layer Security for RADIUS over TCP +2. Normative: Transport Layer Security for RADIUS/TCP 2.1. TCP port and packet types The default destination port number for RADIUS over TLS is TCP/2083. There are no separate ports for authentication, accounting and - dynamic authorisation changes. The source port is arbitrary. + dynamic authorisation changes. The source port is arbitrary. See + section Section 3.3 (4) and (5) for considerations regarding + separation of authentication, accounting and dynauth traffic. 2.2. TLS negotiation - RADIUS has no notion of negotiating TLS in an established connection. - Servers and clients need to be preconfigured to use RADIUS/TLS for a - given endpoint. + RADIUS/TLS has no notion of negotiating TLS in an established + connection. Servers and clients need to be preconfigured to use + RADIUS/TLS for a given endpoint. 2.3. Connection Setup RADIUS/TLS nodes - 1. establish TCP connections as per [I-D.dekok-radext-tcp-transport] + 1. establish TCP connections as per [I-D.ietf-radext-tcp-transport]. + Failure to connect leads to continuous retries, with + exponentially growing intervals between every try. If multiple + servers are defined, the node MAY attempt to establish a + connection to these other servers in parallel, in order to + implement quick failover. - 2. immediately negotiate TLS sessions. The following restrictions - apply: according to [RFC5246] or its predecessor TLS 1.1. The - following restrictions apply: + 2. after completing the TCP handshake, immediately negotiate TLS + sessions. The following restrictions apply: according to + [RFC5246] or its predecessor TLS 1.1. The following restrictions + apply: * Support for TLS v1.1 [RFC4346] or later (e.g. TLS 1.2 [RFC5246]]) is REQUIRED. * Support for certificate-based mutual authentication is REQUIRED. * Negotiation of mutual authentication is REQUIRED. * Negotiation of a ciphersuite providing for confidentiality as @@ -192,20 +200,23 @@ * RADIUS/TLS implementations MUST at a minimum support negotiation of the TLS_RSA_WITH_3DES_EDE_CBC_SHA), and SHOULD support TLS_RSA_WITH_RC4_128_SHA and TLS_RSA_WITH_AES_128_CBC_SHA as well (see Section 3.2 (1) ). * In addition, RADIUS/TLS implementations MUST support negotiation of the mandatory-to-implement ciphersuites required by the versions of TLS that they support. + * RADIUS/TLS nodes MUST NOT negotiate ciphersuites with NULL + encryption (e.g. [RFC4785]). + 3. If TLS is used in an X.509 certificate based operation mode, the following list of certificate validation options applies: * Implementations MUST allow to configure a list of acceptable Certification Authorities for incoming connections. * Certificate validation MUST include the verification rules as per [RFC5280]. * Implementations SHOULD indicate their acceptable Certification @@ -237,25 +248,24 @@ * Implementations SHOULD allow to configure a set of acceptable values for subjectAltName:URI. 4. start exchanging RADIUS datagrams. Note Section 3.3 (1) ). The shared secret to compute the (obsolete) MD5 integrity checks and attribute encryption MUST be "radsec" (see Section 3.3 (2) ). 2.4. Connecting Client Identity In RADIUS/UDP, clients are uniquely identified by their IP address. - The IP address alone does not permit the server to determine whether - the connecting entity is a NAS or a different server which proxies a - request. When NAT is used on the path to the server, it also does - not permit to determine whether there is more than one entity - connecting from the same IP address. + Since the shared secret is associated with the origin IP address, if + more than one RADIUS client is associated with the same IP address, + then those clients also must utilize the same shared secret, a + practice which is inherently insecure as noted in [RFC5247].. RADIUS/TLS makes it possible to preserve this traditional RADIUS semantics by identifying a connecting client by the IP address which initiated the TLS connection. In addition, it permits a much more fine-grained identification. The parameters of the TLS connection can be attributed to the RADIUS packets inside the TLS connection. An implementation of RADIUS/TLS should expose as many details of the TLS connection which belongs to an incoming RADIUS packet as possible to the application layer to allow the administrator to define the identification criteria which are applicable to his desired @@ -408,21 +418,21 @@ (1) After the TLS session is established, RADIUS packet payloads are exchanged over the encrypted TLS tunnel. In RADIUS/UDP, the packet size can be determined by evaluating the size of the datagram that arrived. Due to the stream nature of TCP and TLS, this does not hold true for RADIUS/TLS packet exchange. Instead, packet boundaries of RADIUS packets that arrive in the stream are calculated by evaluating the packet's Length field. Special care needs to be taken on the packet sender side that the value of the Length field is indeed correct before sending it over the TLS tunnel, because incorrect packet lengths can no longer be detected by a differing datagram - boundary. See section 2.6.4 of [I-D.dekok-radext-tcp-transport] for + boundary. See section 2.6.4 of [I-D.ietf-radext-tcp-transport] for more details. (2) Within RADIUS [RFC2865], a shared secret is used for hiding of attributes such as User-Password, as well as in computation of the Response Authenticator. In RADIUS accounting [RFC2866], the shared secret is used in computation of both the Request Authenticator and the Response Authenticator. Since TLS provides integrity protection and encryption sufficient to substitute for RADIUS application-layer security, it is not necessary to configure a RADIUS shared secret. The use of a fixed string for the obsolete @@ -440,26 +450,36 @@ (4) RADIUS [RFC2865] used negative ICMP responses to a newly allocated UDP port to signal that a peer RADIUS server does not support reception and processing of the packet types in [RFC5176]. These packet types are listed as to be received in RADIUS/TLS implementations. Note well: it is not required for an implementation to actually process these packet types. It is sufficient that upon receiving such a packet, an unconditional NAK is sent back to indicate that the action is not supported. + (5) RADIUS [RFC2865] used negative ICMP responses to a newly + allocated UDP port to signal that a peer RADIUS server does not + support reception and processing of RADIUS Accounting packets. There + is no RADIUS datagram to signal an Accounting NAK. Clients may be + misconfigured to send Accounting packets to a RADIUS/TLS server which + does not wish to process their Accounting packet. The server will + need to silently drop the packet. The client will need to deduce + from the absence of replies that it is misconfigured; no negative + ICMP response will reveal this. + 4. Compatibility with other RADIUS transports Ongoing work in the IETF defines multiple alternative transports to the classic UDP transport model as defined in [RFC2865], namely - RADIUS over TCP [I-D.dekok-radext-tcp-transport], RADIUS over DTLS - [I-D.dekok-radext-dtls] and this present document on RADIUS over TLS. + RADIUS over TCP [I-D.ietf-radext-tcp-transport], RADIUS over DTLS + [I-D.ietf-radext-dtls] and this present document on RADIUS over TLS. RADIUS/TLS does not specify any inherent backwards compatibility to RADIUS/UDP or cross compatibility to the other transports, i.e. an implementation which implements RADIUS/TLS only will not be able to receive or send RADIUS packet payloads over other transports. An implementation wishing to be backward or cross compatible (i.e. wishes to serve clients using other transports than RADIUS/TLS) will need to implement these other transports along with the RADIUS/TLS transport and be prepared to send and receive on all implemented transports, which is called a multi-stack implementation. @@ -475,21 +495,21 @@ As a consequence, the selection of transports to communicate from a client to a server is a manual administrative action. An automatic fallback to RADIUS/UDP is NOT RECOMMENDED, as it may lead to down- bidding attacks on the peer communication. 5. Diameter Compatibility Since RADIUS/TLS is only a new transport profile for RADIUS, compatibility of RADIUS/TLS - Diameter [RFC3588] vs. RADIUS/UDP [RFC2865] - Diameter [RFC3588] is identical. The considerations - regarding payload size in [I-D.dekok-radext-tcp-transport] apply. + regarding payload size in [I-D.ietf-radext-tcp-transport] apply. 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 @@ -537,56 +557,62 @@ TLS. 7. IANA Considerations This document has no actions for IANA. The TCP port 2083 was already previously assigned by IANA for RadSec, an early implementation of RADIUS/TLS. No new RADIUS attributes or packet codes are defined. 8. Acknowledgements - RADIUS over TLS was first implemented as "RADSec" by Open Systems + RADIUS/TLS was first implemented as "RADSec" by Open Systems Consultants, Currumbin Waters, Australia, for their "Radiator" RADIUS server product (see [radsec-whitepaper]). 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 Levels", BCP 14, RFC 2119, March 1997. - [RFC2865] Rigney, C., Willens, S., Rubens, - A., and W. Simpson, "Remote + [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 Transport Layer Security (TLS)", RFC 4279, December 2005. [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006. + [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. [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and @@ -597,73 +623,77 @@ 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. - [I-D.dekok-radext-tcp-transport] DeKok, A., "RADIUS Over TCP", draft - -ietf-dekok-radext-tcp-transport-08 - (work in progress), July 2010. + [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. 9.2. Informative References - [I-D.dekok-radext-dtls] DeKok, A., "DTLS as a Transport + [I-D.ietf-radext-dtls] DeKok, A., "DTLS as a Transport Layer for RADIUS", - draft-dekok-radext-dtls-02 (work in - progress), March 2010. + draft-ietf-radext-dtls-01 (work in + progress), October 2010. - [I-D.winter-dynamic-discovery] Winter, S., "Dynamic Peer Discovery - for RADIUS over TLD and DTLS", + [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. [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003. - [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, . [radsecproxy-impl] Venaas, S., "radsecproxy Project Homepage", 2007, . [eduroam] Trans-European Research and Education Networking Association, "eduroam Homepage", 2007, . [geant2] Delivery of Advanced Network Technology to Europe, "European 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.