--- 1/draft-ietf-radext-dtls-09.txt 2014-04-16 10:14:42.380345624 -0700 +++ 2/draft-ietf-radext-dtls-10.txt 2014-04-16 10:14:42.432346875 -0700 @@ -1,20 +1,20 @@ Network Working Group Alan DeKok INTERNET-DRAFT FreeRADIUS Category: Experimental - -Expires: October 5, 2014 -5 February 2014 + +Expires: October 15, 2015 +16 April 2014 DTLS as a Transport Layer for RADIUS - draft-ietf-radext-dtls-09 + draft-ietf-radext-dtls-10 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 @@ -35,21 +35,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 October 5, 2014 + This Internet-Draft will expire on October 15, 2014 Copyright Notice Copyright (c) 2014 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 @@ -72,34 +72,37 @@ 3.1. DTLS Port and Packet Types .......................... 10 3.2. Server Behavior ..................................... 10 4. Client Behavior .......................................... 11 5. Session Management ....................................... 11 5.1. Server Session Management ........................... 12 5.1.1. Session Opening and Closing .................... 12 5.2. Client Session Management ........................... 14 6. Implementation Guidelines ................................ 15 6.1. Client Implementations .............................. 16 6.2. Server Implementations .............................. 17 -7. Implementation Experience ................................ 17 -8. Diameter Considerations .................................. 18 -9. IANA Considerations ...................................... 18 -10. Security Considerations ................................. 18 - 10.1. Legacy RADIUS Security ............................. 19 - 10.2. Resource Exhaustion ................................ 20 - 10.3. Client-Server Authentication with DTLS ............. 20 - 10.4. Network Address Translation ........................ 21 - 10.5. Wildcard Clients ................................... 22 - 10.6. Session Closing .................................... 22 - 10.7. Client Subsystems .................................. 22 -11. References .............................................. 23 - 11.1. Normative references ............................... 23 - 11.2. Informative references ............................. 24 +7. Diameter Considerations .................................. 17 +8. IANA Considerations ...................................... 17 +9. Implementation Status .................................... 18 + 9.1. Radsecproxy ......................................... 18 + 9.2. jradius ............................................. 18 +10. Security Considerations ................................. 19 + 10.1. Crypto-Agility ..................................... 19 + 10.2. Legacy RADIUS Security ............................. 20 + 10.3. Resource Exhaustion ................................ 21 + 10.4. Client-Server Authentication with DTLS ............. 21 + 10.5. Network Address Translation ........................ 22 + 10.6. Wildcard Clients ................................... 23 + 10.7. Session Closing .................................... 23 + 10.8. Client Subsystems .................................. 23 +11. References .............................................. 24 + 11.1. Normative references ............................... 24 + 11.2. Informative references ............................. 25 1. Introduction The RADIUS protocol as described in [RFC2865], [RFC2866], [RFC5176], and others has traditionally used methods based on MD5 [RFC1321] for per-packet authentication and integrity checks. However, the MD5 algorithm has known weaknesses such as [MD5Attack] and [MD5Break]. As a result, some specifications such as [RFC5176] have recommended using IPSec to secure RADIUS traffic. @@ -116,22 +119,22 @@ 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. This specification does not, however, solve all of the problems - associated with RADIUS. The DTLS protocol does not add reliable or - in-order transport to RADIUS. DTLS also does not support + 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]. 1.1. Terminology This document uses the following terms: @@ -441,43 +444,47 @@ [RFC5080] section 2.2.2 describes how duplicate RADIUS/UDP requests result in the retransmission of a previously cached RADIUS/UDP response. Due to DTLS sequence window requirements, a server MUST NOT retransmit a previously sent DTLS packet. Instead, it should cache the RADIUS response packet, and re-process it through DTLS to create a new RADIUS/DTLS packet, every time it is necessary to retransmit a RADIUS response. 5.1. Server Session Management - A RADIUS/DTLS server MUST track ongoing DTLS client session based the - following 4-tuple: + A RADIUS/DTLS server MUST track ongoing DTLS sessions for each based + the following 4-tuple: * source IP address * source port * destination IP address * destination port Note that this 4-tuple is independent of IP address version (IPv4 or IPv6). - Each 4-tuple points to a unique session entry, which contains the - following information: + Each 4-tuple points to a unique session entry, which usually contain + the following information: -DTLS Data - An implementation-specific variable containing information about - the active DTLS session. +DTLS Session + Any information required to maintain and manage the DTLS session. Last Taffic A variable containing a timestamp which indicates when this session - last received valid traffic. + last received valid traffic. If "Last Traffic" is not used, this + variable may not exist. - Each entry may contain other information, such as idle timeouts, +DTLS Data + An implementation-specific variable which may information about the + active DTLS session. This variable may be empty or non existent. + + This data will typically contain information such as idle timeouts, session lifetimes, and other implementation-specific data. 5.1.1. Session Opening and Closing Session tracking is subject to Denial of Service (DoS) attacks due to the ability of an attacker to forge UDP traffic. RADIUS/DTLS servers SHOULD use the stateless cookie tracking technique described in [RFC6347] Section 4.2.1. DTLS sessions SHOULD NOT be tracked until a ClientHello packet has been received with an appropriate Cookie value. Server implementation SHOULD have a way of tracking partially @@ -598,23 +605,22 @@ When client fails to implement both DTLS heartbeats and watchdog packets, it has no way of knowing that a DTLS session has been closed. There is therefore the possibility that the server closes the session without the client knowing. When that happens, the client may later transmit packets in a session, and those packets will be ignored by the server. The client is then forced to time out those packets and then the session, leading to delays and network instabilities. - For these reasons, it is RECOMMENDED that RADIUS/DTLS clients - implement DTLS heartbeats and/or watchdog packets for all DTLS - sessions. + For these reasons, it is RECOMMENDED that all DTLS sessions are + configured to use DTLS heartbeats and/or watchdog packets. DTLS sessions MUST also be deleted when a RADIUS packet fails validation due to a packet being malformed, or when it has an invalid Message-Authenticator, or invalid Response Authenticator. There are other cases when the specifications require that a packet received via a DTLS session be "silently discarded". In those cases, implementations MAY delete the underlying DTLS session. RADIUS/DTLS clients should not send both RADIUS/UDP and RADIUS/DTLS packets to different servers from the same source socket. This @@ -703,66 +710,91 @@ individual subsystem on the client. 6.2. Server Implementations RADIUS/DTLS servers should not use connected sockets to read DTLS packets from a client. This recommendation is because a connected UDP socket will accept packets only from one source IP address and port. This limitation would prevent the server from accepting packets from multiple clients on the same port. -7. Implementation Experience - - Two implementations of RADIUS/DTLS exist, Radsecproxy, and jradius - (http://www.coova.org/JRadius). Some experimental tests have been - performed, but there are at this time no production implementations - using RADIUS/DTLS. - - 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. - - Section 4.4 of [RFC6421] recommends that change control be ceded to - the IETF, and that interoperability is possible. Both requirements - are satisfied. - - Section 4.5 of [RFC6421] requires that the new security methods apply - to all packet types. This requirement is satisfied by allowing DTLS - to be used for all RADIUS traffic. In addition, Section 3, above, - addresses concerns about documenting the transition from legacy - RADIUS to crypto-agile RADIUS. - - Section 4.6 of [RFC6421] requires automated key management. This - requirement is satisfied by leveraging DTLS. - -8. Diameter Considerations +7. Diameter Considerations This specification defines a transport layer for RADIUS. It makes no other changes to the RADIUS protocol. As a result, there are no Diameter considerations. -9. IANA Considerations +8. IANA Considerations No new RADIUS attributes or packet codes are defined. IANA is - requested to update the already-assigned UDP port number 2083 in the - following ways: + 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 Reference: list the RFC number of this document as the reference + o Assignee: change "Mike McCauley" to "IESG". + + 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]. + + The description of implementations in this section is intended to + assist the IETF in its decision processes in progressing drafts to + RFCs. + +9.1. Radsecproxy + + Organization: Radsecproxy + + URL: https://software.uninett.no/radsecproxy/ + + Maturity: Widely-used software based on early drafts of this + document. + The use of the DTLS functionality is not clear. + + Coverage: The bulk of this specification is implemented, based on + earlier versions of this document. Exact revisions + which were implemented are unknown. + + Licensing: Freely distributable with acknowledgement + + Implementation experience: No comments from implementors. + +9.2. jradius + + Organization: Coova + + URL: http://www.coova.org/JRadius/RadSec + + Maturity: Production software based on early drafts of this + document. + The use of the DTLS functionality is not clear. + + Coverage: The bulk of this specification is implemented, based on + earlier versions of this document. Exact revisions + which were implemented are unknown. + + Licensing: Freely distributable with requirement to + redistribute source. + + Implementation experience: No comments from implementors. + 10. Security Considerations The bulk of this specification is devoted to discussing security considerations related to RADIUS. However, we discuss a few additional issues here. This specification relies on the existing DTLS, RADIUS/UDP, and RADIUS/TLS specifications. As a result, all security considerations for DTLS apply to the DTLS portion of RADIUS/DTLS. Similarly, the TLS and RADIUS security issues discussed in [RFC6614] also apply to @@ -789,27 +821,51 @@ 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. -10.1. Legacy RADIUS Security +10.1. Crypto-Agility - protocol. We suggest that RADIUS clients and servers implement - either this specification, or [RFC6614]. New attacks on MD5 have - appeared over the past few years, and there is a distinct possibility - that MD5 may be completely broken in the near future. Such a break - would mean that RADIUS/UDP was completely insecure. + 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. + + Section 4.4 of [RFC6421] recommends that change control be ceded to + the IETF, and that interoperability is possible. Both requirements + are satisfied. + + Section 4.5 of [RFC6421] requires that the new security methods apply + to all packet types. This requirement is satisfied by allowing DTLS + to be used for all RADIUS traffic. In addition, Section 3, above, + addresses concerns about documenting the transition from legacy + RADIUS to crypto-agile RADIUS. + + Section 4.6 of [RFC6421] requires automated key management. This + requirement is satisfied by using DTLS key management. + +10.2. Legacy RADIUS Security + + We reiterate here the poor security of the legacy RADIUS protocol. + We suggest that RADIUS clients and servers implement either this + specification, or [RFC6614]. New attacks on MD5 have appeared over + the past few years, and there is a distinct possibility that MD5 may + be completely broken in the near future. Such a break would mean + that RADIUS/UDP was completely insecure. The existence of fast and cheap attacks on MD5 could result in a loss of all network security which depends on RADIUS. Attackers could obtain user passwords, and possibly gain complete network access. We cannot overstate the disastrous consequences of a successful attack on RADIUS. We also caution implementors (especially client implementors) about using RADIUS/DTLS. It may be tempting to use the shared secret as the basis for a TLS pre-shared key (PSK) method, and to leave the @@ -820,63 +876,64 @@ the benefits found by using DTLS. RADIUS/DTLS client implementors MUST expose a configuration that allows the administrator to choose the cipher suite. Where certificates are used, RADIUS/DTLS client implementors MUST expose a configuration which allows an administrator to configure all certificates necessary for certificate-based authentication. These certificates include client, server, and root certificates. TLS-PSK methods are susceptible to dictionary attacks. Section 6, - above, recommends deriving TLS-PSK keys from a CSPRNG, which makes + above, recommends deriving TLS-PSK keys from a Cryptographically + Secure Pseudo-Random Number Generator (CSPRNG), which makes dictionary attacks significantly more difficult. Servers SHOULD track failed client connections by TLS-PSK ID, and block TLS-PSK IDs which seem to be attempting brute-force searchs of the keyspace. The historic RADIUS practice of using shared secrets (here, PSKs) that are minor variations of words is NOT RECOMMENDED, as it would negate all of the security of DTLS. -10.2. Resource Exhaustion +10.3. Resource Exhaustion The use of DTLS allows DoS attacks, and resource exhaustion attacks which were not possible in RADIUS/UDP. These attacks are the similar to those described in [RFC6614] Section 6, for TCP. Session tracking as described in Section 5.1 can result in resource exhaustion. Servers MUST therefore limit the absolute number of sessions that they track. When the total number of sessions tracked is going to exceed the configured limit, servers MAY free up resources by closing the session which has been idle for the longest time. Doing so may free up idle resources which then allow the server to accept a new session. Servers MUST limit the number of partially open DTLS sessions. These limits SHOULD be exposed to the administrator as configurable settings. -10.3. Client-Server Authentication with DTLS +10.4. Client-Server Authentication with DTLS We expect that the initial deployment of DTLS will be follow the RADIUS/UDP model of statically configured client-server relationships. The specification for dynamic discovery of RADIUS servers is under development, so we will not address that here. Static configuration of client-server relationships for RADIUS/UDP means that a client has a fixed IP address for a server, and a shared secret used to authenticate traffic sent to that address. The server in turn has a fixed IP address for a client, and a shared secret used to authenticate traffic from that address. This model needs to be extended for RADIUS/DTLS. When DTLS is used, the fixed IP address model can be relaxed. As - discussed earlier in Section 2.2.1, client identies should be + discussed earlier in Section 2.2.1, client identities should be determined from TLS parameters. Any authentication credentials for that client are then determined solely from the client identity, and not from an IP address. See [RFC6614] Section 2.4 for a discussion of how to match a certificate to a client identity. However, servers SHOULD use IP address filtering to minimize the possibility of attacks. That is, they SHOULD permit clients only from a particular IP address range or ranges. They SHOULD silently discard all traffic from outside of those ranges. @@ -909,72 +966,72 @@ servers. This requirement does not prevent clients from using hostnames instead of IP addresses for locating a particular server. Instead, it means that the credentials for that server should be preconfigured, and strongly tied to 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.4. Network Address Translation +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. 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. 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. -10.5. Wildcard Clients +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. 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.6. Session Closing +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 checks. The reason is that the session is expected to be used for transport of RADIUS packets only. Any non-RADIUS traffic on that session means the other party is misbehaving, and is a potential security risk. Similarly, any RADIUS traffic failing authentication vector or Message-Authenticator validation means that two parties do not have a common shared secret, and the session is therefore unauthenticated and insecure. We wish to avoid the situation where a third party can send well- formed RADIUS packets which cause a DTLS session to close. Therefore, in other situations, the session SHOULD remain open in the face of non-conformant packets. -10.7. Client Subsystems +10.8. Client Subsystems Many traditional clients treat RADIUS as subsystem-specific. That is, each subsystem on the client has its own RADIUS implementation and configuration. These independent implementations work for simple systems, but break down for RADIUS when multiple servers, fail-over, and load-balancing are required. They have even worse issues when DTLS is enabled. As noted in Section 6.1, above, clients SHOULD use a local proxy which arbitrates all RADIUS traffic between the client and all @@ -1062,20 +1119,24 @@ [RFC5176] Chiba, M. et al., "Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS)", RFC 5176, January 2008. [RFC6421] Nelson, D. (Ed), "Crypto-Agility Requirements for Remote Authentication Dial-In User Service (RADIUS)", RFC 6421, November 2011. +[RFC6982] + Sheffer, Y. and A. Farrel, "Improving Awareness of Running Code: + The Implementation Status Section", RFC 6982, July 2013. + [MD5Attack] Dobbertin, H., "The Status of MD5 After a Recent Attack", CryptoBytes Vol.2 No.2, Summer 1996. [MD5Break] Wang, Xiaoyun and Yu, Hongbo, "How to Break MD5 and Other Hash Functions", EUROCRYPT. ISBN 3-540-25910-4, 2005. Acknowledgments