--- 1/draft-ietf-radext-radsec-01.txt 2008-10-24 10:12:25.000000000 +0200 +++ 2/draft-ietf-radext-radsec-02.txt 2008-10-24 10:12:25.000000000 +0200 @@ -1,23 +1,23 @@ RADIUS Extensions Working Group S. Winter Internet-Draft RESTENA Intended status: Experimental M. McCauley -Expires: February 23, 2009 OSC +Expires: April 27, 2009 OSC S. Venaas UNINETT K. Wierenga Cisco - August 22, 2008 + October 24, 2008 TLS encryption for RADIUS over TCP (RadSec) - draft-ietf-radext-radsec-01 + draft-ietf-radext-radsec-02 Status of This Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that @@ -28,21 +28,21 @@ 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. - This Internet-Draft will expire on February 23, 2009. + This Internet-Draft will expire on April 27, 2009. Abstract This document specifies security on the transport layer (TLS) for the RADIUS protocol [RFC2865] when transmitted over TCP [I-D.dekok-radext-tcp-transport]. This enables dynamic trust relationships between RADIUS servers. Table of Contents @@ -55,22 +55,22 @@ 2.3. RADIUS Datagrams . . . . . . . . . . . . . . . . . . . . . 5 3. Informative: Design Decisions . . . . . . . . . . . . . . . . 6 3.1. X.509 Certificate Considerations . . . . . . . . . . . . . 6 3.2. Ciphersuites and Compression Negotiation Considerations . 8 3.3. RADIUS Datagram Considerations . . . . . . . . . . . . . . 8 4. Diameter Compatibility . . . . . . . . . . . . . . . . . . . . 9 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 - 8.1. Informative References . . . . . . . . . . . . . . . . . . 10 - 8.2. Normative References . . . . . . . . . . . . . . . . . . . 11 + 8.1. Normative References . . . . . . . . . . . . . . . . . . . 10 + 8.2. Informative References . . . . . . . . . . . . . . . . . . 11 Appendix A. DNS NAPTR Peer Discovery . . . . . . . . . . . . . . 12 Appendix B. Implementation Overview: Radiator . . . . . . . . . . 13 Appendix C. Implementation Overview: radsecproxy . . . . . . . . 14 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 @@ -109,21 +109,21 @@ of lookup mechanisms is out of scope of this document, but an implementation of a DNS NAPTR lookup based mechanism exists and is described as an example lookup mechanism in Appendix A. 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 - [RFC2119]. + RFC 2119. [RFC2119] 1.2. Terminology RadSec node: a RadSec client or server RadSec Client: a RadSec instance which initiates a new connection. RadSec Server: a RadSec instance which listens on a RadSec port and accepts new connections @@ -137,33 +137,36 @@ 2.2. Connection Setup RadSec nodes 1. establish TCP connections as per [I-D.dekok-radext-tcp-transport] 2. negotiate TLS sessions according to [RFC5246] or its predecessor TLS 1.1. The following restrictions apply: + * The authentication MUST be mutual, i.e. both the RadSec server + and the RadSec client authenticate each other. + * When using X.509 certificates, RadSec servers SHOULD indicate their acceptable Certification Authorities as per section 7.4.4 of [RFC5246] (see Section 3.1 (1) ) * When using X.509 certificates, the TLS Extension "Trusted CA Indication" from [RFC5246] or its TLS 1.1 predecessor SHOULD be used to indicate trusted CAs for the client (see Section 3.1 (2) ) * When using X.509 certificates, certificate validation is - performed as per [RFC5280] or its TLS 1.1 predecessor. The - client MAY perform additional checks to accomodate for - different trust models. + performed as per [RFC5280] or its predecessor. The client MAY + perform additional checks to accomodate for different trust + models. * The client MUST NOT negotiate cipher suites which only provide integrity protection. * The cipher suite TLS_RSA_WITH_3DES_EDE_CBC_SHA MUST be supported. * The cipher suites TLS_RSA_WITH_AES_128_CBC_SHA and TLS_RSA_WITH_RC4_128_SHA SHOULD be supported. (see Section 3.2 (1) ) @@ -346,27 +350,27 @@ 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, accounting and dynamic authorisation changes. RadSec allocates a - single port for all RADIUS packet types. Also in RadSec, 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. + single port for all RADIUS packet types. Nevertheless, in RadSec 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. (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 RadSec 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. @@ -387,20 +391,27 @@ In the case of dynamic peer discovery, a RadSec 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 RadSec 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, X.509 certificates are the + only proof of authorisation for a connecting RadSec nodes. Special + care needs to be taken that certificates get verified properly + according to the chosen trust model (particularly: consulting CRL + lists, 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. 6. IANA Considerations This document has no actions for IANA. The TCP port 2083 was already @@ -413,27 +424,64 @@ 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]. 8. References -8.1. Informative References +8.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 + Authentication Dial In User Service + (RADIUS)", RFC 2865, June 2000. + + [RFC2866] Rigney, C., "RADIUS Accounting", + RFC 2866, June 2000. + + [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. + + [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. + + [I-D.dekok-radext-tcp-transport] DeKok, A., "RADIUS Over TCP", + draft-dekok-radext-tcp-transport-00 + (work in progress), July 2008. + +8.2. Informative References + + [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, . [radiator-manual] Open System Consultants, "Radiator Radius Server - Installation and Reference Manual", 2006, . @@ -451,115 +499,79 @@ Technology to Europe, "European Commission Information Society and Media: GEANT2", 2008, . [terena] TERENA, "Trans-European Research and Education Networking Association", 2008, . -8.2. Normative References - - [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. - - [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. - - [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. - - [RFC3588] Calhoun, P., Loughney, J., Guttman, - E., Zorn, G., and J. Arkko, - "Diameter Base Protocol", RFC 3588, - September 2003. - - [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-dekok-radext-tcp-transport-00 - (work in progress), July 2008. - Appendix A. DNS NAPTR Peer Discovery - The following text is quoted from the file goodies/dnsroam.cfg in the - Radiator distribution; further documentation of the - feature in Radiator can be found at [radiator-manual]. It describes - an algorithm to retrieve the RadSec route information from the global - DNS using NAPTR and SRV records. The input of the algorithm is the - realm part of the user name. + The following text is paraphrased from the file goodies/dnsroam.cfg + in the Radiator distribution; further documentation of the feature in Radiator can be found at [radiator-manual]. It + describes an algorithm to retrieve the RadSec route information from + the global DNS using NAPTR and SRV records. The input of the + algorithm is the realm part of the user name. The following algorithm is used to discover a target server from a Realm using DNS: - 1. Look for NAPTR records for the Realm. + 1. Look for NAPTR records for the Realm. If found, continue at step + 2, otherwise continue at step 4. 2. For each NAPTR found record, examine the Service field and use that to determine the transport protocol and TLS requirements for the server. The Service field starts with 'AAA' for insecure and 'AAAS' for TLS secured. The Service field contains '+RADSECS' for RadSec over SCTP, '+RADSECT' for RadSec over TCP or '+RADIUS' for RADIUS protocol over UDP. The most common Service field you will see will be 'AAAS+RADSECT' for TLS secured RadSec over TCP. 3. A. If the NAPTR has the 'S' flag, look for SRV records for the name. For each SRV record found, note the Port number and then look for A and AAAA records corresponding to the name in the SRV record. B. If the NAPTR has the 'A' flag, look for a A and AAAA records for the name. - 4. If no NAPTR records are found, look for A and AAAA records based - directly on the realm name. For example, if the realm is - 'examplerealm.edu', it looks for records such as - '_radsec._tcp.examplerealm.edu', '_radsec._sctp.examplerealm.edu' - and '_radius._udp.examplerealm.edu', - - 5. All A and AAAA records found are ordered according to their Order + 4. All A and AAAA records found are ordered according to their Order and Preference fields. The most preferable server address is used as the target server address, along with any other server attributes discovered from DNS. If no SRV record was found for - the address, the DNSROAM configured Port is used. + the address, the DNSROAM configured Port is used. Algorithm + terminates. - For example, if the User-Name realm was 'examplerealm.edu', and DNS + 5. Look for A and AAAA records on the literal realm name, preceded + by "_radsec._tcp.". For example, if the realm is 'example.com', + it looks for the record '_radsec._tcp.example.com'. If more than + one result is returned, no ordering is assumed. Algorithm + terminates. + + For example, if the User-Name realm was 'example.com', and DNS contained the following records: - examplerealm.edu. IN NAPTR 50 50 "s" "AAAS+RADSECT" "" - _radsec._tcp.examplerealm.edu. + example.com. IN NAPTR 50 50 "s" "AAAS+RADSECT" "" + _radsec._tcp.example.com. - _radsec._tcp.examplerealm.edu. IN SRV 0 10 2083 - radsec.examplerealm.edu. + _radsec._tcp.example.com. IN SRV 0 10 2083 radsec.example.com. - radsec.examplerealm.edu. IN AAAA 2001::202:44ff:fe0a:f704 + radsec.example.com. IN AAAA 2001:0DB8::202:44ff:fe0a:f704 Then the target selected would be a RadSec server on port 2083 at - IPv6 address 2001::202:44ff:fe0a:f704. The connection would be made - over TCP/IP, and TLS encryption would be used. This complete + IPv6 address 2001:0DB8::202:44ff:fe0a:f704. The connection would be + made over TCP/IP, and TLS encryption would be used. This complete specification of the realm is the most flexible and is recommended. Appendix B. 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 @@ -576,30 +588,36 @@ Radiator is compliant to version 2 of RadSec if the following options are used: * Protocol tcp * UseTLS * TLS_CertificateFile + * Secret radsec * Protocol tcp * UseTLS + * TLS_RequireClientCert + * Secret radsec + As of Radiator 3.15, the default shared secret for RadSec connections - is "mysecret" (without quotes). The implementation uses TCP + is configurable and defaults to "mysecret" (without quotes). For + compliance with this document, this setting needs to be configured + for the shared secret "radsec". The implementation uses TCP keepalive socket options, but does not send Status-Server packets. Once established, TLS connections are kept open throughout the server instance lifetime. Appendix C. Implementation Overview: radsecproxy The RADIUS proxy named radsecproxy was written in order to allow use of RadSec in current RADIUS deployments. This is a generic proxy that supports any number and combination of clients and servers, supporting RADIUS over UDP and RadSec. The main idea is that it can