--- 1/draft-ietf-radext-radsec-08.txt 2011-07-08 14:15:45.000000000 +0200 +++ 2/draft-ietf-radext-radsec-09.txt 2011-07-08 14:15:46.000000000 +0200 @@ -1,23 +1,23 @@ RADIUS Extensions Working Group S. Winter Internet-Draft RESTENA Intended status: Experimental M. McCauley -Expires: September 15, 2011 OSC +Expires: January 9, 2012 OSC S. Venaas UNINETT K. Wierenga Cisco - March 14, 2011 + July 8, 2011 TLS encryption for RADIUS - draft-ietf-radext-radsec-08 + draft-ietf-radext-radsec-09 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,21 +26,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 15, 2011. + This Internet-Draft will expire on January 9, 2012. Copyright Notice 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 @@ -69,31 +69,32 @@ 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 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 + 3.3. RADIUS Datagram Considerations . . . . . . . . . . . . . . 10 4. Compatibility with other RADIUS transports . . . . . . . . . . 11 5. Diameter Compatibility . . . . . . . . . . . . . . . . . . . . 11 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 - 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 + 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 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, @@ -232,60 +233,75 @@ use the ASCII label "sha-1" to identify the SHA-1 algorithm. The length of a SHA-1 hash is 20 bytes and the length of the corresponding fingerprint string is 65 characters. An example certificate fingerprint is: sha- 1:E1:2D:53:2B:7C:6B:8A:29:A2:76:C8:64:36:0B:08:4B:7A:F1:9E:9D * Peer validation always includes a check on whether the locally configured expected DNS name or IP address of the server that is contacted matches its presented certificate. DNS names and IP addresses can be contained in the Common Name (CN) or - subjectAltName entries. For verification, only one these + subjectAltName entries. For verification, only one of these entries is to be considered. The following precedence applies: for DNS name validation, subjectAltName:DNS has precedence over CN; for IP address validation, subjectAltName: iPAddr has precedence over CN. * 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. 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].. + 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 - operational model. In X.509 certificate operation, at least the - following parameters of the TLS connection should be exposed: + RADIUS/TLS supports multiple operation modes. + + In TLS-PSK operation, a client is uniquely identified by its TLS + identifier. + + In TLS-X.509 mode using fingerprints, a client is uniquely identified + by the fingerprint of the presented client certificate. + + In TLS-X.509 with PKI infrastructure, a client is uniquely identified + by the serial number of the tuple (presented client + certificate;Issuer). + + Note well: having identified a connecting entity does not mean the + server necessarily wants to communicate with that client. E.g. if + the Issuer is not in a trusted set of Issuers, the server may decline + to perform RADIUS transactions with this client. + + There are numerous trust models in PKI environments, and it is beyond + the scope of this document to define how a particular deployment + determines whether a client is trustworthy. Implementations which + want to support a wide variety of trust models should expose as many + details of the presented certificate to the administrator as possible + so that the trust model can be implemented by the administrator. As + a suggestion, at least the following parameters of the X.509 client + certificate should be exposed: o Originating IP address o Certificate Fingerprint o Issuer o Subject + o all X509v3 Extended Key Usage o all X509v3 Subject Alternative Name o all X509v3 Certificate Policies In TLS-PSK operation, at least the following parameters of the TLS connection should be exposed: o Originating IP address @@ -290,77 +306,71 @@ o Originating IP address o TLS Identifier 2.5. RADIUS Datagrams Authentication, Accounting and Authorization packets are sent according to the following rules: - RADIUS/TLS clients handle the following packet types from [RFC2865], - [RFC2866], [RFC5176] on the connection they initiated (see - Section 3.3 (3) and (4) ): - - o send Access-Request - - o send Accounting-Request - - o send Status-Server + RADIUS/TLS clients transmit the same packet types on the connection + they initiated as a RADIUS/UDP client would (see Section 3.3 (3) and + (4) ). E.g. they send - o send Disconnect-ACK + o Access-Request - o send Disconnect-NAK + o Accounting-Request - o send CoA-ACK + o Status-Server - o send CoA-NAK + o Disconnect-ACK - o receive Access-Challenge + o Disconnect-NAK - o receive Access-Accept + o ... - o receive Access-Reject + and they receive + o Access-Accept - o receive Accounting-Response + o Accounting-Response - o receive Disconnect-Request + o Disconnect-Request - o receive CoA-Request - RADIUS/TLS servers handle the following packet types from [RFC2865], - [RFC2866], [RFC5176] on the connections they serve to clients: + o ... - o receive Access-Request + RADIUS/TLS servers transmit the same packet types on connections they + have accepted as a RADIUS/UDP server would. E.g. they send - o receive Accounting-Request + o Access-Challenge - o receive Status-Server + o Access-Accept - o receive Disconnect-ACK + o Access-Reject - o receive Disconnect-NAK + o Accounting-Response - o receive CoA-ACK + o Disconnect-Request - o receive CoA-NAK + o ... - o send Access-Challenge + and they receive - o send Access-Accept + o Access-Request - o send Access-Reject + o Accounting-Request - o send Accounting-Response + o Status-Server - o send Disconnect-Request + o Disconnect-ACK - o send CoA-Request + o ... 3. Informative: Design Decisions This section explains the design decisions that led to the rules defined in the previous section. 3.1. X.509 Certificate Considerations (1) If a RADIUS/TLS client is in possession of multiple certificates from different CAs (i.e. is part of multiple roaming consortia) and @@ -421,50 +431,50 @@ 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.ietf-radext-tcp-transport] for more details. - (2) Within RADIUS [RFC2865], a shared secret is used for hiding + (2) Within RADIUS/UDP [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 shared secret eliminates possible node misconfigurations. - (3) RADIUS [RFC2865] uses different UDP ports for authentication, + (3) RADIUS/UDP [RFC2865] uses different UDP ports for authentication, accounting and dynamic authorisation changes. RADIUS/TLS allocates a single port for all RADIUS packet types. Nevertheless, in RADIUS/TLS the notion of a client which sends authentication requests and processes replies associated with it's users' sessions and the notion of a server which receives requests, processes them and sends the appropriate replies is to be preserved. The normative rules about acceptable packet types for clients and servers mirror the packet flow behaviour from RADIUS/UDP. - (4) RADIUS [RFC2865] used negative ICMP responses to a newly + (4) RADIUS/UDP [RFC2865] uses 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 + (5) RADIUS/UDP [RFC2865] uses 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 @@ -588,25 +598,20 @@ (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, @@ -650,20 +655,25 @@ 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. + [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, . [MD5-attacks] Black, J., Cochran, M., and T. Highland, "A Study of the MD5 Attacks: Insights and Improvements", October 2006,