--- 1/draft-ietf-radext-radsec-00.txt 2008-08-22 17:13:05.000000000 +0200 +++ 2/draft-ietf-radext-radsec-01.txt 2008-08-22 17:13:05.000000000 +0200 @@ -1,21 +1,23 @@ RADIUS Extensions Working Group S. Winter Internet-Draft RESTENA Intended status: Experimental M. McCauley -Expires: December 19, 2008 OSC +Expires: February 23, 2009 OSC S. Venaas UNINETT - June 17, 2008 + K. Wierenga + Cisco + August 22, 2008 TLS encryption for RADIUS over TCP (RadSec) - draft-ietf-radext-radsec-00 + draft-ietf-radext-radsec-01 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 @@ -26,144 +28,249 @@ 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 December 19, 2008. - -Copyright Notice - - Copyright (C) The IETF Trust (2008). + This Internet-Draft will expire on February 23, 2009. Abstract This document specifies security on the transport layer (TLS) for the - RADIUS protocol [2] when transmitted over TCP [9]. This enables - dynamic trust relationships between RADIUS servers. + RADIUS protocol [RFC2865] when transmitted over TCP + [I-D.dekok-radext-tcp-transport]. This enables dynamic trust + relationships between RADIUS servers. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 - 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 - 2. Transport Layer Security . . . . . . . . . . . . . . . . . . . 4 - 2.1. Operation . . . . . . . . . . . . . . . . . . . . . . . . 4 - 2.2. Ciphersuites and Compression Negotiation . . . . . . . . . 6 - 2.3. RADIUS Shared Secret Usage in RadSec . . . . . . . . . . . 6 - 3. Comparison of Diameter vs. RadSec . . . . . . . . . . . . . . 7 - 4. Diameter Compatibility . . . . . . . . . . . . . . . . . . . . 7 - 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 - 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 - 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 - 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 - 8.1. Informative References . . . . . . . . . . . . . . . . . . 9 - 8.2. Normative References . . . . . . . . . . . . . . . . . . . 9 - Appendix A. DNS NAPTR Peer Discovery . . . . . . . . . . . . . . 10 - Appendix B. Implementation Overview: Radiator . . . . . . . . . . 11 - Appendix C. Implementation Overview: radsecproxy . . . . . . . . 12 + 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 + 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 + 2. Normative: Transport Layer Security for RADIUS over TCP . . . 4 + 2.1. TCP port and packet types . . . . . . . . . . . . . . . . 4 + 2.2. Connection Setup . . . . . . . . . . . . . . . . . . . . . 4 + 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 + Appendix A. DNS NAPTR Peer Discovery . . . . . . . . . . . . . . 12 + Appendix B. Implementation Overview: Radiator . . . . . . . . . . 13 + Appendix C. Implementation Overview: radsecproxy . . . . . . . . 14 1. Introduction - The RADIUS protocol [2] is a widely deployed authentication and + The RADIUS protocol [RFC2865] is a widely deployed authentication and authorisation protocol. The supplementary RADIUS Accounting - specification [3] also provides accounting mechanisms, thus + 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. - - Several enhancements have been proposed to overcome RADIUS' - limitations. An IETF Standards Track protocol, Diameter [6], has - been designed to provide an AAA protocol that should deprecate - RADIUS. However, given that current implementations of Diameter are - either not freely accessible, or do not provide the flexibility of - current RADIUS deployments, or both, an intermediate solution that is - based on RADIUS but provides mechanisms to overcome many of its - drawbacks has been implemented by several vendors. These - implementations are interoperable and deployed in a world-wide - wireless roaming infrastructure. The protocol is called RadSec. - This document describes version 2 of the RadSec protocol. Version 1 - of RadSec is defined in the RadSec whitepaper [10]. The two - currently existing implementations of RadSec version 2 are described - in Appendix B and Appendix C. + its packet payload. RADIUS security is based on the MD5 algorithm, + which has been proven to be insecure. The main focus of RadSec is to provide a means to secure the communication between RADIUS/TCP peers on the transport layer. The most important use of RadSec lies in roaming environments where RADIUS packets need to be transferred through different administrative domains and untrusted, potentially hostile networks. An example for a world-wide roaming environment that uses RadSec to - secure communication is "eduroam", see [15]. - - The new features in RadSec obsolete the use of IP addresses and - shared secrets to identify other peers and thus allow the dynamic - establishment of connections to peers that are not previously - configured. The definition 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. + secure communication is "eduroam", see [eduroam]. - Transitioning from a plain RADIUS infrastructure to a RadSec - infrastructure is very easy, since the RADIUS packet payload is - identical in both protocols. Enabling RadSec can be done on a per- - server basis. Unlike in Diameter, the learning curve for a new - protocol does not exist, which makes it almost trivial for an - experienced RADIUS server administrator to switch to a RadSec-secured - transport for RADIUS packets. + There are multiple known attacks on the MD5 algorithm which is used + in RADIUS to provide integrity protection and a limited + confidentiality protection. RadSec wraps the entire RADIUS packet + payload into a TLS stream and thus mitigates the risk of attacks on + MD5. - The security layer does not require any new assignments of codepoints - for the RADIUS protocol. No new attributes are defined and no new - packet codes are used. + Because of the static trust establishment between RADIUS peers (IP + address and shared secret) the only scalable way of creating a + massive deployment of RADIUS-servers under control by different + administrative entities is to introduce some form of a proxy chain to + route the access requests to their home server. This creates a lot + 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 RadSec + 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 intermediate aggregation proxies. The definition + 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 - [1]. + [RFC2119]. -2. Transport Layer Security +1.2. Terminology -2.1. Operation + RadSec node: a RadSec client or server - Once the TCP connection between two RadSec nodes is established, a - TLS session is established. At least TLSv1.1 [7] is used. Both - nodes either mutually present a X.509 certificate which is verified - according to [5] or use a shared key authentication for TLS which - needs to be pre-configured out-of-band prior to the connection - attempt. + RadSec Client: a RadSec instance which initiates a new connection. - The list of Certification Authorities that a node which acts as a - server is willing to accept SHOULD be sent during the Certificate - Request message in the CertificateRequest struct (section 7.4.4 of - [7]). Rationale: If a RadSec node acts as a client and is in - possession of multiple certificates from different CAs (i.e. is part - of multiple roaming consortia) and dynamic discovery is used, and the - dynamic discovery mechanism does not provide sufficient meta - information to identify the server's roaming consortium, then it is - necessary to signal which consortium it is connecting to. + RadSec Server: a RadSec instance which listens on a RadSec port and + accepts new connections - The list of Certification Authorities that a node which acts as a - client is willing to accept can not be signaled within the TLS 1.1 - handshake. This makes it impossible to select the right certificate - if a RadSec node which is acting as a server for multiple roaming - consortia (in possession of multiple certificates from different CAs) - is contacted by a client. This situation is likely to change in TLS - 1.2, according to [8]. "Trusted CA Indication" as in [8], section 6, - SHOULD be used. +2. Normative: Transport Layer Security for RADIUS over TCP - When using X.509 certificate validation, peer validation always +2.1. TCP port and packet types + + The default destination port number for RadSec is TCP/2083. There + are no separate ports for authentication, accounting and dynamic + authorisation changes. The source port is arbitrary. + +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: + + * 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. + + * 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) ) + + 3. 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.3. RADIUS Datagrams + + Authentication, Accounting and Authorization packets are sent + according to the following rules: + + RadSec 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 + + o send Disconnect-ACK + + o send Disconnect-NAK + + o send CoA-ACK + + o send CoA-NAK + + o receive Access-Challenge + + o receive Access-Accept + + o receive Access-Reject + + o receive Accounting-Response + + o receive Disconnect-Request + + o receive CoA-Request + + RadSec servers handle the following packet types from [RFC2865], + [RFC2866], [RFC5176] on the connections they serve to clients: + + o receive Access-Request + o receive Accounting-Request + + o receive Status-Server + + o receive Disconnect-ACK + + o receive Disconnect-NAK + + o receive CoA-ACK + + o receive CoA-NAK + + o send Access-Challenge + + o send Access-Accept + + o send Access-Reject + + o send Accounting-Response + + o send Disconnect-Request + + o send CoA-Request + +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 RadSec client is in possession of multiple certificates from + different CAs (i.e. is part of multiple roaming consortia) and + dynamic discovery is used, the discovery mechanism possibly does not + yield sufficient information to identify the consortium uniquely + (e.g. DNS discovery). Subsequently, the client may not know by + itself which client certificate to use for the TLS handshake. Then + it is necessary to for the server to signal which consortium it + belongs to, and which certificates it expects. If there is no risk + of confusing multiple roaming consortia, providing this information + in the handshake is not crucial. + + (2) If a RadSec 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 RadSec + 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) When using X.509 certificate validation, peer validation always includes a check on whether the DNS name or the IP address of the server that is contacted matches its certificate. When a RadSec peer establishes a new connection (acts as a client) to another peer, the following rules of precedence are used during validation: o If the client expects a certain fully qualified domain name (FQDN) and the presented certificate contains both at least one instance of the subjectAltName field with type dNSName and a Common Name, then the certificate is considered a match if any one of those subjectAltName fields matches the expected FQDN. The Common Name @@ -161,311 +268,295 @@ server that is contacted matches its certificate. When a RadSec peer establishes a new connection (acts as a client) to another peer, the following rules of precedence are used during validation: o If the client expects a certain fully qualified domain name (FQDN) and the presented certificate contains both at least one instance of the subjectAltName field with type dNSName and a Common Name, then the certificate is considered a match if any one of those subjectAltName fields matches the expected FQDN. The Common Name field is not evaluated in this case. + o If the client expects a certain fully qualified domain name (FQDN) and the presented certificate does not contain any subjectAltName field with type dNSName, then the certificate is considered a match if the Common Name field matches the expected FQDN. + o If the client expects a certain IP address and the presented certificate contains both at least one instance of the subjectAltName field with type iPAddr and a Common Name, then the certificate is considered a match if any one of those subjectAltName fields matches the expected IP address. The Common Name field is not evaluated in this case. + o If the client expects a certain IP address and the presented certificate does not contain any subjectAltName field with type iPAddr, then the certificate is considered a match if the Common Name field matches the expected IP address. - Further restrictions on the certificate MAY be verified, depending on - the trust fabric of the peering agreement. - - If dynamic peer resolution is used, the above verification steps MAY - not be sufficient to ensure that a connecting peer is authorised to - perform user authentications. In these cases, the trust fabric - SHOULD NOT depend on untrusted peer resolution methods like DNS to - identify and authorise nodes. Instead, the operators of the RadSec - infrastructure SHOULD define their own trust model and apply this - model to the certificates after they have passed the standard - validity checks above. Current RadSec implementations offer varying - degrees of versatility for defining criteria which certificates to - accept. - - NOTE WELL: None of the current implementations provide configuration - options for using TLS with pre-shared keys. However, the underlying - libraries support it, so support for that should be implementable - easily. - After the TLS session is established, RADIUS packet payloads are - exchanged over the encrypted TLS tunnel. In plain RADIUS, 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 RadSec packet exchange. Instead, packet boundaries of - RADIUS packets that arrive in the stream are calculated by evaluating - the packet's Length field. Special care MUST 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. + (4) If dynamic peer resolution is used, the above verification steps + may not be sufficient to ensure that a connecting peer is authorised + to perform user authentications. In these cases, the trust fabric + cannot depend on peer authentication methods like DNSSEC to identify + RadSec nodes. The RadSec nodes also need to be properly authorised. + Operators of a RadSec infrastructure should define their own + authorisation trust model and apply this model to the certificates + after they have passed the standard validity checks above. Current + RadSec implementations offer varying degrees of versatility for + defining criteria which certificates to accept. -2.2. Ciphersuites and Compression Negotiation +3.2. Ciphersuites and Compression Negotiation Considerations RadSec implementations need not necessarily support all TLS - ciphersuites listed in [7]. Not all TLS ciphersuites are supported by - available TLS tool kits and licenses may be required in some cases. - The existing implementations of RadSec use OpenSSL as cryptographic - backend, which supports all of the ciphersuites listed in the rules - below: - - To ensure interoperability, RadSec clients and servers MUST - support the TLS [7] mandatory-to-implement ciphersuite: - TLS_RSA_WITH_3DES_EDE_CBC_SHA. - - In addition, RadSec servers SHOULD support and be able to - negotiate all of the following TLS ciphersuites: - o TLS_RSA_WITH_RC4_128_MD5 - o TLS_RSA_WITH_RC4_128_SHA - o TLS_RSA_WITH_AES_128_CBC_SHA - In addition, RadSec clients SHOULD support the following - TLS ciphersuites [4]: - o TLS_RSA_WITH_AES_128_CBC_SHA - o TLS_RSA_WITH_RC4_128_SHA - Since TLS supports ciphersuite negotiation, peers completing the - TLS negotiation will also have selected a ciphersuite, which - includes encryption and hashing methods. - - TLS also supports compression as well as ciphersuite - negotiation. During the RadSec conversation the client and server MAY - negotiate compression. However, a peer MUST continue the - conversation even if the other peer rejects compression. - -2.3. RADIUS Shared Secret Usage in RadSec + ciphersuites listed in [RFC5246]. Not all TLS ciphersuites + are supported by available TLS tool kits and licenses may be required + in some cases. The existing implementations of RadSec use OpenSSL as + cryptographic backend, which supports all of the ciphersuites listed + in the rules in the normative section. - Within RADIUS [2], 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 [3], the shared secret is used - in computation of both the Request Authenticator and the Response - Authenticator. + The TLS cphersuite TLS_RSA_WITH_3DES_EDE_CBC_SHA is mandatory-to- + implement according to [RFC5246] and thus has to be supported by + RadSec nodes. - Since in RADIUS a shared secret is used to provide confidentiality - as well as integrity protection and authentication, the use of TLS - ciphers which encrypt the stream payload in RadSec can provide - security services sufficient to substitute for RADIUS application- - layer security. Therefore, where TLS ciphers that provide encryption - are used, it will not be necessary to configure a RADIUS shared - secret. + The two other ciphersuites in the normative section + (TLS_RSA_WITH_RC4_128_SHA and TLS_RSA_WITH_AES_128_CBC_SHA) are + widely implemented in TLS toolkits and are considered good practice + to implement. - Then, the secret shared between two RadSec peers MAY not - be configured. In this case, the shared secret defaults to "radsec" - (without the quotes). However, if the RadSec nodes negotiated a TLS - cipher that provides integrity assurance only, the connection MUST be - configured with a non-default RADIUS shared secret. + TLS also supports compression. Compression is an optional + feature. During the RadSec conversation the client and server may + negotiate compression, but must continue the conversation even if the + other peer rejects compression. -3. Comparison of Diameter vs. RadSec +3.3. RADIUS Datagram Considerations - The feature set in the Diameter Base Protocol is almost a superset of - the features present in RadSec. Sophisticated mechanisms for - keepalive, reliable transmission and payload security exist. The - reason for specifying a short-term intermediate solution as opposed - to using Diameter at the moment are the lack of suitable, publicly - available and versatile implementations. + (1) After the TLS session is established, RADIUS packet payloads are + exchanged over the encrypted TLS tunnel. In plain RADIUS, 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 RadSec 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. - Typically, RADIUS servers do not only support the RADIUS protocol - itself, but also provide interfaces to a wide variety of backends - (credential stores) to actually verify a user's credentials. In - highly heterogeneous environments like eduroam, where a lot of - different backends are in use by the participating home servers - (OpenLDAP, Novell eDirectory, ActiveDirectory, SQL databases or plain - text files, just to name a few), such versatility is a requirement. - Current Diameter server implementations focus on the validation of a - small set of EAP methods (mostly EAP-SIM and EAP-TLS) and - consequently on a small set of backends to verify these credentials. + (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 + shared secret eliminates possible node misconfigurations. - A further requirement in environments like eduroam is affordability. - Public institutions like schools and universities often face tight - budgets, and so an open source implementation of Diameter would be - desirable (just as FreeRADIUS is for the RADIUS protocol). - Unfortunately, the few Open Source Software implementations of the - Diameter protocol like OpenDiameter [12] or JDiameter [13] only - provide a set of libraries, but no server at all. + (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. - Diameter's ability to resolve peers dynamically is limited to using - either SLPv2 or DNS, whereas RadSec allows arbitrary peer resolution - mechanisms. This greater amount of flexibility can pay off in many - roaming federations. In eduroam's case, a central SAML-based meta - data repository ("eduGAIN-MDS") is in place which is able to provide - peer addresses. Using RadSec it is possible to resolve a peer's - address through such a meta data system, whereas with Diameter it is - not possible to use this repository natively. + (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. 4. Diameter Compatibility Since RadSec is only a new transport profile for RADIUS, - compatibility of RadSec - Diameter vs. RADIUS - Diameter is - identical. The considerations regarding payload size in [9] apply. + compatibility of RadSec - Diameter [RFC3588] vs. RADIUS [RFC2865] - + Diameter [RFC3588] is identical. The considerations regarding + payload size in [I-D.dekok-radext-tcp-transport] apply. 5. 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 RadSec 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, 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). Some TLS ciphersuites only provide integrity validation of their - payload, and provide no encryption. When such ciphersuites are - negotiated in a RadSec TLS handshake, the only means of protecting - sensitive payload contents is the RADIUS shared secret. If the - RADIUS shared secret is set to the default "radsec" and a non- - encrypting TLS ciphersuite is used, implementations should either - forbid transmitting payload over this connection completely or at - least issue a warning to whatever logging destination is configured - by the administrator. + 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 - previously assigned by IANA for RadSec. The Status-Server packet was - already assigned by IANA for [2]. + previously assigned by IANA for RadSec. No new RADIUS attributes or + packet codes are defined. 7. Acknowledgements RadSec version 1 was first implemented by Open Systems Consultants, Currumbin Waters, Australia, for their "Radiator" RADIUS server - product. + product (see [radsec-whitepaper]). Funding and input for the development of this Internet Draft was - provided by the European Commission co-funded project "GEANT2" [16] - and further feedback was provided by the TERENA Task Force Mobility - [17]. + 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 - [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement - Levels", RFC 2119, March 1997. - -8.2. Normative References - - [2] Rigney, C., Rubens, A., Simpson, W., and S. Willens, "Remote - Authentication Dial In User Service (RADIUS)", RFC 2865, - June 2000. - - [3] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. + [RFC2119] Bradner, S., "Key words for use in + RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, + March 1997. - [4] Chown, P., "Advanced Encryption Standard (AES) Ciphersuites for - Transport Layer Security (TLS)", RFC 3268, June 2002. + [radsec-whitepaper] Open System Consultants, "RadSec - + a secure, reliable RADIUS + Protocol", May 2005, . - [5] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, - R., and T. Polk, "Internet X.509 Public Key Infrastructure - Certificate and Certificate Revocation List (CRL) Profile", - RFC 5280, May 2008. + [radiator-manual] Open System Consultants, "Radiator + Radius Server - Installation and + Reference Manual", 2006, . - [6] Calhoun, P., Laughney, J., Arkko, J., Guttman, E., and G. Zorn, - "Diameter Base Protocol", RFC 3588, September 2003. + [radsecproxy-impl] Venaas, S., "radsecproxy Project + Homepage", 2007, . - [7] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) - Protocol Version 1.1", RFC 4346, April 2006. + [eduroam] Trans-European Research and + Education Networking Association, + "eduroam Homepage", 2007, + . - [8] Eastlake 3rd, D., "Transport Layer Security (TLS) Extensions: - Extension Definitions", February 2008, . + [geant2] Delivery of Advanced Network + Technology to Europe, "European + Commission Information Society and + Media: GEANT2", 2008, + . - [9] Winter, S., "Reliable Transport Profile for RADIUS", July 2008, - . + [terena] TERENA, "Trans-European Research + and Education Networking + Association", 2008, + . - [10] Open System Consultants, "RadSec - a secure, reliable RADIUS - Protocol", May 2005, - . +8.2. Normative References - [11] Open System Consultants, "Radiator Radius Server - Installation - and Reference Manual", 2006, - . + [RFC2865] Rigney, C., Willens, S., Rubens, + A., and W. Simpson, "Remote + Authentication Dial In User Service + (RADIUS)", RFC 2865, June 2000. - [12] Open Diameter Project, "Open Diameter", 2006, - . + [RFC2866] Rigney, C., "RADIUS Accounting", + RFC 2866, June 2000. - [13] Svenson, E., "JDiameter Project Homepage", 2006, - . + [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. - [14] Venaas, S., "radsecproxy Project Homepage", 2007, - . + [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. - [15] Trans-European Research and Education Networking Association, - "eduroam Homepage", 2007, . + [RFC3588] Calhoun, P., Loughney, J., Guttman, + E., Zorn, G., and J. Arkko, + "Diameter Base Protocol", RFC 3588, + September 2003. - [16] Delivery of Advanced Network Technology to Europe, "European - Commission Information Society and Media: GEANT2", 2008, - . + [RFC5246] Dierks, T. and E. Rescorla, "The + Transport Layer Security (TLS) + Protocol Version 1.2", RFC 5246, + August 2008. - [17] TERENA, "Trans-European Research and Education Networking - Association", 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 [11]. 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. + 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. + 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 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. + For example, if the User-Name realm was 'examplerealm.edu', and DNS contained the following records: + examplerealm.edu. IN NAPTR 50 50 "s" "AAAS+RADSECT" "" _radsec._tcp.examplerealm.edu. + _radsec._tcp.examplerealm.edu. IN SRV 0 10 2083 radsec.examplerealm.edu. + radsec.examplerealm.edu. IN AAAA 2001::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 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. @@ -541,21 +640,21 @@ certificate will be verified, including checking that the configured FQDN or IP address matches what is in the certificate. Requests are sent to a RadSec server just like they would to a UDP server. The proxy supports Status-Server messages. They are only sent to a server if enabled for that particular server. Status-Server requests are always responded to. This RadSec implementation has been successfully tested together with Radiator. It is a freely available open-source implementation. For - source code and documentation, see [14]. + source code and documentation, see [radsecproxy-impl]. Authors' Addresses Stefan Winter Fondation RESTENA 6, rue Richard Coudenhove-Kalergi Luxembourg 1359 LUXEMBOURG Phone: +352 424409 1 @@ -578,20 +677,31 @@ UNINETT Abels gate 5 - Teknobyen Trondheim 7465 NORWAY Phone: +47 73 55 79 00 Fax: +47 73 55 79 01 EMail: stig.venaas@uninett.no URI: http://www.uninett.no. + Klaas Wierenga + Cisco Systems International BV + Haarlerbergweg 13-19 + Amsterdam 1101 CH + The Netherlands + + Phone: +31 (0)20 3571752 + Fax: + EMail: kwiereng@cisco.com + URI: http://www.cisco.com. + Full Copyright Statement Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS @@ -618,16 +728,14 @@ such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. -Acknowledgements +Acknowledgement - Funding for the RFC Editor function is provided by the IETF - Administrative Support Activity (IASA). This document was produced - using xml2rfc v1.32 (of http://xml.resource.org/) from a source in - RFC-2629 XML format. + This document was produced using xml2rfc v1.33 (of + http://xml.resource.org/) from a source in RFC-2629 XML format.