--- 1/draft-ietf-radext-dtls-08.txt 2014-02-05 09:14:33.618423463 -0800 +++ 2/draft-ietf-radext-dtls-09.txt 2014-02-05 09:14:33.666424635 -0800 @@ -1,20 +1,20 @@ Network Working Group Alan DeKok INTERNET-DRAFT FreeRADIUS Category: Experimental - -Expires: September 24, 2014 -24 January 2014 + +Expires: October 5, 2014 +5 February 2014 DTLS as a Transport Layer for RADIUS - draft-ietf-radext-dtls-08 + draft-ietf-radext-dtls-09 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 September 24, 2014 + This Internet-Draft will expire on October 5, 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 @@ -57,66 +57,66 @@ include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction ............................................. 4 1.1. Terminology ......................................... 4 1.2. Requirements Language ............................... 5 1.3. Document Status ..................................... 5 -2. Building on Existing Foundations ......................... 6 - 2.1. Changes to RADIUS ................................... 6 - 2.2. Similarities with RADIUS/TLS ........................ 7 - 2.2.1. Changes from RADIUS/TLS to RADIUS/DTLS ......... 7 -3. Interaction with RADIUS/UDP .............................. 8 - 3.1. DTLS Port and Packet Types .......................... 9 - 3.2. Server Behavior ..................................... 9 -4. Client Behavior .......................................... 10 -5. Session Management ....................................... 10 - 5.1. Server Session Management ........................... 11 - 5.1.1. Session Opening and Closing .................... 11 - 5.2. Client Session Management ........................... 13 -6. Implementation Guidelines ................................ 14 - 6.1. Client Implementations .............................. 15 - 6.2. Server Implementations .............................. 16 -7. Implementation Experience ................................ 16 -8. Diameter Considerations .................................. 16 -9. IANA Considerations ...................................... 17 -10. Security Considerations ................................. 17 - 10.1. Legacy RADIUS Security ............................. 18 - 10.2. Resource Exhaustion ................................ 18 - 10.3. Client-Server Authentication with DTLS ............. 19 - 10.4. Network Address Translation ........................ 20 - 10.5. Wildcard Clients ................................... 21 - 10.6. Session Closing .................................... 21 - 10.7. Client Subsystems .................................. 21 -11. References .............................................. 22 - 11.1. Normative references ............................... 22 - 11.2. Informative references ............................. 23 +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.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 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. While RADIUS over IPSec has been widely deployed, there are difficulties with this approach. The simplest point against IPSec is - that there is no straightforward way for a RADIUS application to - control or monitor the network security policies. That is, the - requirement that the RADIUS traffic be encrypted and/or authenticated - is implicit in the network configuration, and is not enforced by the - RADIUS application. + that there is no straightforward way for an application to control or + monitor the network security policies. That is, the requirement that + the RADIUS traffic be encrypted and/or authenticated is implicit in + the network configuration, and cannot be enforced by the RADIUS + 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 @@ -161,23 +161,55 @@ 1.2. 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]. 1.3. Document Status - This document is an Experimental RFC. Please see [RFC6614] Section - 1.3 for a discussion of the issues surrounding the use of TLS with - RADIUS. + This document is an Experimental RFC. + + It is one out of several approaches to address known cryptographic + weaknesses of the RADIUS protocol, such as [RFC6614]. This + specification does not fulfill all recommendations on a AAA transport + profile as per [RFC3539]; however unlike [RFC6614], it is based on + 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]. + + 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 changes to systems implementing standard RADIUS. This section outlines those changes, and defines new behaviors necessary to implement DTLS. 2.1. Changes to RADIUS @@ -306,21 +338,22 @@ potentially subject to security downgrade attacks. It is not sufficient to just disable RADIUS/UDP and enable RADIUS/DTLS. RADIUS has no provisions for protocol negotiation, so simply disabling RADIUS/UDP would result in timeouts, lost traffic, and network instabilities. The end result of this specification is that nearly all RADIUS/UDP implementations should transition to using a secure alternative. In some cases, RADIUS/UDP may remain where IPSec is used as a transport, or where implementation and/or business reasons preclude a change. - However, long-term use of RADIUS/UDP is not recommended. + However, we do not recommend long-term use of RADIUS/UDP outside of + isolated and secure networks. 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 @@ -377,22 +410,22 @@ 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 independently discover network issues or server failures. It is - therefore RECOMMENDED that clients use a local proxy as described in - Section 6.1, below. + therefore RECOMMENDED that clients with multiple internal RADIUS + sources use a local proxy as described in Section 6.1, below. Clients may implement "pools" of servers for fail-over or load- balancing. These pools SHOULD NOT mix RADIUS/UDP and RADIUS/DTLS servers. 5. Session Management Where [RFC6614] can rely on the TCP state machine to perform session tracking, this specification cannot. As a result, implementations of this specification may need to perform session management of the DTLS @@ -460,44 +493,54 @@ 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 Request 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 session as described above. There are few reasons to communicate with a NAS which is not implementing RADIUS. - The above paragraph can be rephrased more generically. A session - MUST be deleted when non-RADIUS traffic is received over it. This - specification is for RADIUS, and there is no reason to allow non- - RADIUS traffic over a RADIUS/DTLS session. A session MUST be deleted - when RADIUS traffic fails to pass security checks. There is no - reason to permit insecure networks. A session SHOULD NOT be deleted - when a well-formed, but "unexpected" RADIUS packet is received over - it. Future specifications may extend RADIUS/DTLS, and we do not want - to forbid those specifications. + A session MUST be deleted when non-RADIUS traffic is received over + it. This specification is for RADIUS, and there is no reason to + allow non-RADIUS traffic over a RADIUS/DTLS session. A session MUST + be deleted when RADIUS traffic fails to pass security checks. There + is no reason to permit insecure networks. A session SHOULD NOT be + deleted when a well-formed, but "unexpected" RADIUS packet is + received over it. Future specifications may extend RADIUS/DTLS, and + we do not want to forbid those specifications. + + The goal of the above requirements is to ensure security, while + maintaining flexibility. Any security related issue causes the + connection to be closed. After the security restrictions have been + applied, any unexpected traffic may be safely ignored, as it cannot + cause a security issue. There is no need to close the session for + unexpected but valid traffic, and the session can safely remain open. Once a DTLS session is established, a RADIUS/DTLS server SHOULD use DTLS Heartbeats [RFC6520] to determine connectivity between the two servers. A server SHOULD also use watchdog packets from the client to determine that the session is still active. As UDP does not guarantee delivery of messages, RADIUS/DTLS servers which do not implement an application-layer watchdog MUST also - maintain a "Last Traffic" timestamp per DTLS session. The timestamp - SHOULD be updated on reception of a valid RADIUS/DTLS packet, or a - DTLS heartbeat. The timestamp MUST NOT be updated in other - situations. When a session has not received a packet for a period of - time, it is labelled "idle". The server SHOULD delete idle DTLS - sessions after an "idle timeout". The server MAY cache the TLS - session parameters, in order to provide for fast session resumption. + maintain a "Last Traffic" timestamp per DTLS session. The + granularity of this timestamp is not critical, and could be limited + to one second intervals. The timestamp SHOULD be updated on + reception of a valid RADIUS/DTLS packet, or a DTLS Heartbeat, but no + more than once per interval. The timestamp MUST NOT be updated in + other situations. + + When a session has not received a packet for a period of time, it is + labelled "idle". The server SHOULD delete idle DTLS sessions after + an "idle timeout". The server MAY cache the TLS session parameters, + in order to provide for fast session resumption. This session "idle timeout" SHOULD be exposed to the administrator as a configurable setting. It SHOULD NOT be set to less than 60 seconds, and SHOULD NOT be set to more than 600 seconds (10 minutes). The minimum value useful value for this timer is determined by the application-layer watchdog mechanism defined in the following section. RADIUS/DTLS servers SHOULD also monitor the total number of open sessions. They SHOULD have a "maximum sessions" setting exposed to @@ -742,29 +785,31 @@ 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. + 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 - We reiterate here the poor security of the legacy RADIUS protocol. - It is RECOMMENDED that all RADIUS clients and servers implement 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. + 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,21 +865,21 @@ 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 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.5 for a discussion + 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. Since the client-server relationship is static, the authentication credentials for that relationship should also be statically configured. That is, a client connecting to a DTLS server SHOULD be @@ -1003,20 +1048,24 @@ Rivest, R. and S. Dusse, "The MD5 Message-Digest Algorithm", RFC 1321, April 1992. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March, 1997. [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. +[RFC4107] + Bellovin, S. and R. Housley, "Guidelines for Cryptographic Key + Management", BCP 107, RFC 4107, June 2005. + [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.