--- 1/draft-ietf-radext-dtls-12.txt 2014-07-03 16:14:37.137411886 -0700 +++ 2/draft-ietf-radext-dtls-13.txt 2014-07-03 16:14:37.189413156 -0700 @@ -1,20 +1,20 @@ Network Working Group Alan DeKok INTERNET-DRAFT FreeRADIUS Category: Experimental - -Expires: November 8, 2014 -8 May 2014 + +Expires: January 4, 2015 +3 July 2014 DTLS as a Transport Layer for RADIUS - draft-ietf-radext-dtls-12 + draft-ietf-radext-dtls-13 Abstract The RADIUS protocol defined in RFC 2865 has limited support for authentication and encryption of RADIUS packets. The protocol transports data in the clear, although some parts of the packets can have obfuscated content. Packets may be replayed verbatim by an attacker, and client-server authentication is based on fixed shared secrets. This document specifies how the Datagram Transport Layer Security (DTLS) protocol may be used as a fix for these problems. It @@ -65,39 +65,39 @@ 1.2. Requirements Language ............................... 5 1.3. Document Status ..................................... 5 2. Building on Existing Foundations ......................... 7 2.1. Changes to RADIUS ................................... 7 2.2. Similarities with RADIUS/TLS ........................ 8 2.2.1. Changes from RADIUS/TLS to RADIUS/DTLS ......... 8 3. Interaction with RADIUS/UDP .............................. 9 3.1. DTLS Port and Packet Types .......................... 10 3.2. Server Behavior ..................................... 10 4. Client Behavior .......................................... 11 -5. Session Management ....................................... 11 +5. Session Management ....................................... 12 5.1. Server Session Management ........................... 12 - 5.1.1. Session Opening and Closing .................... 12 - 5.2. Client Session Management ........................... 14 -6. Implementation Guidelines ................................ 15 + 5.1.1. Session Opening and Closing .................... 13 + 5.2. Client Session Management ........................... 15 +6. Implementation Guidelines ................................ 16 6.1. Client Implementations .............................. 16 6.2. Server Implementations .............................. 17 -7. Diameter Considerations .................................. 17 -8. IANA Considerations ...................................... 17 +7. Diameter Considerations .................................. 18 +8. IANA Considerations ...................................... 18 9. Implementation Status .................................... 18 9.1. Radsecproxy ......................................... 18 - 9.2. jradius ............................................. 18 + 9.2. jradius ............................................. 19 10. Security Considerations ................................. 19 - 10.1. Crypto-Agility ..................................... 19 + 10.1. Crypto-Agility ..................................... 20 10.2. Legacy RADIUS Security ............................. 20 10.3. Resource Exhaustion ................................ 21 - 10.4. Client-Server Authentication with DTLS ............. 21 + 10.4. Client-Server Authentication with DTLS ............. 22 10.5. Network Address Translation ........................ 23 - 10.6. Wildcard Clients ................................... 23 + 10.6. Wildcard Clients ................................... 24 10.7. Session Closing .................................... 24 10.8. Client Subsystems .................................. 24 11. References .............................................. 25 11.1. Normative references ............................... 25 11.2. Informative references ............................. 26 1. Introduction The RADIUS protocol as described in [RFC2865], [RFC2866], [RFC5176], and others has traditionally used methods based on MD5 [RFC1321] for @@ -115,22 +115,23 @@ application. This specification takes a different approach. We define a method for using DTLS [RFC6347] as a RADIUS transport protocol. This approach has the benefit that the RADIUS application can directly monitor and control the security policies associated with the traffic that it processes. Another benefit is that RADIUS over DTLS continues to be a User Datagram Protocol (UDP) based protocol. The change from RADIUS/UDP - is largely only to add TLS support. This allows implementations to - remain UDP based, without changing to a TCP architecture. + is largely to add DTLS support, and make any necessary related + changes to RADIUS. This allows implementations to remain UDP based, + without changing to a TCP architecture. This specification does not, however, solve all of the problems associated with RADIUS/UDP. The DTLS protocol does not add reliable or in-order transport to RADIUS. DTLS also does not support fragmentation of application-layer messages, or of the DTLS messages themselves. This specification therefore shares with traditional RADIUS the issues of order, reliability, and fragmentation. These issues are dealt with in RADIUS/TCP [RFC6613] and RADIUS/TLS [RFC6614]. @@ -180,33 +181,32 @@ UDP, does not have head-of-line blocking issues. If this specification is indeed selected for advancement to Standards Track, certificate verification options ([RFC6614] Section 2.3, point 2) needs to be refined. Another experimental characteristic of this specification is the question of key management between RADIUS/DTLS peers. RADIUS/UDP only allowed for manual key management, i.e., distribution of a shared secret between a client and a server. RADIUS/DTLS allows - manual distribution of long-term proofs of peer identity as well (by - using TLS-PSK ciphersuites, or identifying clients by a certificate - fingerprint), but as a new feature enables use of X.509 certificates - in a PKIX infrastructure. It remains to be seen if one of these - methods will prevail or if both will find their place in real-life - deployments. The authors can imagine pre-shared keys (PSK) to be - popular in small-scale deployments (Small Office, Home Office (SOHO) - or isolated enterprise deployments) where scalability is not an issue - and the deployment of a Certification Authority (CA) is considered - too much of a hassle; however, the authors can also imagine large - roaming consortia to make use of PKIX. Readers of this specification - are encouraged to read the discussion of key management issues within - [RFC6421] as well as [RFC4107]. + manual distribution of long-term proofs of peer identity, by using + TLS-PSK ciphersuites. RADIUS/DTLS also allows the use of X.509 + certificates in a PKIX infrastructure. It remains to be seen if one + of these methods will prevail or if both will find their place in + real-life deployments. The authors can imagine pre-shared keys (PSK) + to be popular in small-scale deployments (Small Office, Home Office + (SOHO) or isolated enterprise deployments) where scalability is not + an issue and the deployment of a Certification Authority (CA) is + considered too much of a hassle; however, the authors can also + imagine large roaming consortia to make use of PKIX. Readers of this + specification are encouraged to read the discussion of key management + issues within [RFC6421] as well as [RFC4107]. It has yet to be decided whether this approach is to be chosen for Standards Track. One key aspect to judge whether the approach is usable on a large scale is by observing the uptake, usability, and operational behavior of the protocol in large-scale, real-life deployments. 2. Building on Existing Foundations Adding DTLS as a RADIUS transport protocol requires a number of @@ -354,68 +354,88 @@ This section describes how clients and servers should use RADIUS/DTLS, and how it interacts with RADIUS/UDP. 3.1. DTLS Port and Packet Types The default destination port number for RADIUS/DTLS is UDP/2083. There are no separate ports for authentication, accounting, and dynamic authorization changes. The source port is arbitrary. The text above in [RFC6614] Section 3.4 describes issues surrounding the use of one port for multiple packet types. We recognize that - implementations may allow the the use of RADIUS/DTLS over non- - standard ports. In that case, the references to UDP/2083 in this - document should be read as applying to any port used for transport of + implementations may allow the use of RADIUS/DTLS over non-standard + ports. In that case, the references to UDP/2083 in this document + should be read as applying to any port used for transport of RADIUS/DTLS traffic. 3.2. Server Behavior When a server receives packets on UDP/2083, all packets MUST be treated as being DTLS. RADIUS/UDP packets MUST NOT be accepted on this port. Servers MUST NOT accept DTLS packets on the old RADIUS/UDP ports. Early drafts of this specification permitted this behavior. It is forbidden here, as it depended on behavior in DTLS which may change without notice. + Servers MUST authenticate clients. RADIUS is designed to be used by + mutually trusted systems. Allowing anonymous clients would ensure + privacy for RADIUS/DTLS traffic, but would negate all other security + aspects of the protocol. + As RADIUS has no provisions for capability signalling, there is no - way for a RADIUS server to indicate to a client that it should - transition to using DTLS. This action has to be taken by the - administrators of the two systems, using a method other than RADIUS. - This method will likely be out of band, or manual configuration. + way for a server to indicate to a client that it should transition to + using DTLS. This action has to be taken by the administrators of the + two systems, using a method other than RADIUS. This method will + likely be out of band, or manual configuration. Some servers maintain a list of allowed clients per destination port. Others maintain a global list of clients, which are permitted to send packets to any port. Where a client can send packets to multiple ports, the server MUST maintain a "DTLS Required" flag per client. This flag indicates whether or not the client is required to use DTLS. When set, the flag indicates that the only traffic accepted from the client is over UDP/2083. When packets are received from a client on non-DTLS ports, for which DTLS is required, the server MUST silently discard these packets, as there is no RADIUS/UDP shared secret available. This flag will often be set by an administrator. However, if a server receives DTLS traffic from a client, it SHOULD notify the administrator that DTLS is available for that client. It MAY mark the client as "DTLS Required". + It is RECOMMENDED that servers support the following perfect forward + secrecy (PFS) cipher suites: + + o TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 + o TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 + Allowing RADIUS/UDP and RADIUS/DTLS from the same client exposes the traffic to downbidding attacks, and is NOT RECOMMENDED. 4. Client Behavior When a client sends packets to the assigned RADIUS/DTLS port, all packets MUST be DTLS. RADIUS/UDP packets MUST NOT be sent to this port. + Clients MUST authenticate themselves to servers, via credentials + which are unique to each client. + + It is RECOMMENDED that clients support the following PFS cipher + suites: + + o TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 + o TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 + RADIUS/DTLS clients SHOULD NOT probe servers to see if they support DTLS transport. Instead, clients SHOULD use DTLS as a transport layer only when administratively configured. If a client is configured to use DTLS and the server appears to be unresponsive, the client MUST NOT fall back to using RADIUS/UDP. Instead, the client should treat the server as being down. RADIUS clients often had multiple independent RADIUS implementations and/or processes that originate packets. This practice was simple to implement, but the result is that each independent subsystem must @@ -643,25 +663,25 @@ Where a TLS pre-shared key (PSK) method is used, implementations MUST support keys of at least 16 octets in length. Implementations SHOULD support key lengths of 32 octets, and SHOULD allow for longer keys. The key data MUST be capable of being any value (0 through 255, inclusive). Implementations MUST NOT limit themselves to using textual keys. It is RECOMMENDED that the administration interface allows for the keys to be entered as humanly readable strings in hex format. - When creating keys, it is RECOMMENDED that keys be derived from a - cryptographically secure pseudo-random number generator (CSPRNG) - instead of administrators inventing keys on their own. If managing - keys is too complicated, a certificate-based TLS method SHOULD be - used instead. + When creating keys for use with PSK cipher suites, it is RECOMMENDED + that keys be derived from a cryptographically secure pseudo-random + number generator (CSPRNG) instead of administrators inventing keys on + their own. If managing keys is too complicated, a certificate-based + TLS method SHOULD be used instead. 6.1. Client Implementations RADIUS/DTLS clients should use connected sockets where possible. Use of connected sockets means that the underlying kernel tracks the sessions, so that the client subsystem does not need to manage multiple sessions on one socket. RADIUS/DTLS clients should use a single source (IP + port) when sending packets to a particular RADIUS/DTLS server. Doing so @@ -726,23 +746,24 @@ 8. IANA Considerations No new RADIUS attributes or packet codes are defined. IANA is requested to update the "Service Name and Transport Protocol Port Number Registry". The entry corresponding to port service name "radsec", port number "2083", and transport protocol "UDP" should be updated as follows: o Assignee: change "Mike McCauley" to "IESG". - o Contact: change ""Mike McCauley" to "IETF Chair" + o Contact: change "Mike McCauley" to "IETF Chair" o Reference: Add this document as a reference + o Assignment Notes: add the text "The UDP port 2083 was already previously assigned by IANA for "RadSec", an early implementation of RADIUS/TLS, prior to issuance of this RFC." 9. Implementation Status This section records the status of known implementations of RADIUS/DTLS at the time of posting of this Internet- Draft, and is based on a proposal described in [RFC6982]. @@ -816,23 +837,21 @@ The fixed shared secret given above in Section 2.2.1 is acceptible only when DTLS is used with an non-null encryption method. When a DTLS session uses a null encryption method due to misconfiguration or implementation error, all of the RADIUS traffic will be readable by an observer. Implementations therefore MUST NOT use null encryption methods for RADIUS/DTLS. For systems which perform protocol-based firewalling and/or filtering, it is RECOMMENDED that they be configured to permit only - DTLS over the RADIUS/DTLS port. Where deep packet inspection is - possible, there should be further restrictions to allow only RADIUS - packets inside of the DTLS session. + DTLS over the RADIUS/DTLS port. 10.1. Crypto-Agility Section 4.2 of [RFC6421] makes a number of recommendations about security properties of new RADIUS proposals. All of those recommendations are satisfied by using DTLS as the transport layer. Section 4.3 of [RFC6421] makes a number of recommendations about backwards compatibility with RADIUS. Section 3, above, addresses these concerns in detail. @@ -953,21 +972,22 @@ discard all traffic from outside of those ranges. Since the client-server relationship is static, the authentication credentials for that relationship must also be statically configured. That is, a client connecting to a DTLS server SHOULD be pre- configured with the servers credentials (e.g. PSK or certificate). If the server fails to present the correct credentials, the DTLS session MUST be closed. Each server SHOULD be preconfigured with sufficient information to authenticate connecting clients. - The above requirements can be met by using a private Certificate + The requirement for clients to be individually configured with a + unique certificate can be met by using a private Certificate Authority (CA) for certificates used in RADIUS/DTLS environments. If a client were configured to use a public CA, then it could accept as valid any server which has a certificate signed by that CA. While the traffic would be secure from third-party observers, the server would, howrver, have unrestricted access to all of the RADIUS traffic, including all user credentials and passwords. Therefore, clients SHOULD NOT be pre-configured with a list of known public CAs by the vendor or manufacturer. Instead, the clients SHOULD start off with an empty CA list. The addition of a CA SHOULD @@ -987,42 +1007,44 @@ on the client, and associated with that hostname. This requirement does suggest that in the absence of a specification for dynamic discovery, clients SHOULD use only those servers which have been manually configured by an administrator. 10.5. Network Address Translation Network Address Translation (NAT) is fundamentally incompatible with RADIUS/UDP. RADIUS/UDP uses the source IP address to determine the shared secret for the client, and NAT hides many clients behind one - source IP address. + source IP address. As a result, RADIUS/UDP clients can not be + located behind a NAT gateway. In addition, port re-use on a NAT gateway means that packets from different clients may appear to come from the same source port on the NAT. That is, a RADIUS server may receive a RADIUS/DTLS packet from - a client IP/port combination, followed by the reception of a - RADIUS/UDP packet from that same client IP/port combination. If this - behavior is allowed, then the client would have an inconsistent - security profile, allowing an attacker to choose the most insecure - method. + one source IP/port combination, followed by the reception of a + RADIUS/UDP packet from that same source IP/port combination. If this + behavior is allowed, then the server would have an inconsistent view + of the clients security profile, allowing an attacker to choose the + most insecure method. - As a result, RADIUS/UDP clients SHOULD NOT be located behind a NAT - gateway. If clients are located behind a NAT gateway, then a secure - transport such as DTLS MUST be used. As discussed below, a method - for uniquely identifying each client MUST be used. + If more than one client is located behind a NAT gateway, then every + client behind the NAT MUST use a secure transport such as TLS or + DTLS. As discussed below, a method for uniquely identifying each + client MUST be used. 10.6. Wildcard Clients Some RADIUS server implementations allow for "wildcard" clients. That is, clients with an IPv4 netmask of other than 32, or an IPv6 netmask of other than 128. That practice is not recommended for - RADIUS/UDP, as it means multiple clients use the same shared secret. + RADIUS/UDP, as it means multiple clients will use the same shared + secret. The use of RADIUS/DTLS can allow for the safe usage of wildcards. When RADIUS/DTLS is used with wildcards, clients MUST be uniquely identified using TLS parameters, and any certificate or PSK used MUST be unique to each client. 10.7. Session Closing Section 5.1.1, above, requires that DTLS sessions be closed when the transported RADIUS packets are malformed, or fail the authenticator