--- 1/draft-ietf-radext-dtls-06.txt 2013-10-09 12:15:08.155086906 -0700 +++ 2/draft-ietf-radext-dtls-07.txt 2013-10-09 12:15:08.199088033 -0700 @@ -1,20 +1,20 @@ Network Working Group Alan DeKok INTERNET-DRAFT FreeRADIUS Category: Experimental - -Expires: January 12, 2014 -12 July 2013 + +Expires: October 09, 2014 +9 October 2013 DTLS as a Transport Layer for RADIUS - draft-ietf-radext-dtls-06 + draft-ietf-radext-dtls-07 Abstract The RADIUS protocol [RFC2865] 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 also describes @@ -66,39 +66,40 @@ 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 2.2.2. Reinforcement of RADIUS/TLS .................... 8 3. Interaction with RADIUS/UDP .............................. 8 3.1. DTLS Port and Packet Types .......................... 9 3.2. Server Behavior ..................................... 9 4. Client Behavior .......................................... 10 5. Connection Management .................................... 10 - 5.1. Server Connection Management ........................ 11 + 5.1. Server Connection Management ........................ 10 5.1.1. Session Management ............................. 11 5.2. Client Connection Management ........................ 13 6. Implementation Guidelines ................................ 14 - 6.1. Client Implementations .............................. 15 + 6.1. Client Implementations .............................. 14 6.2. Server Implementations .............................. 15 -7. Implementation Experience ................................ 16 +7. Implementation Experience ................................ 15 8. Diameter Considerations .................................. 16 9. IANA Considerations ...................................... 16 -10. Security Considerations ................................. 17 +10. Security Considerations ................................. 16 10.1. Legacy RADIUS Security ............................. 17 10.2. Resource Exhaustion ................................ 18 - 10.3. Network Address Translation ........................ 19 - 10.4. Wildcard Clients ................................... 19 - 10.5. Session Closing .................................... 19 - 10.6. Clients Subsystems ................................. 20 -11. References .............................................. 20 - 11.1. Normative references ............................... 20 - 11.2. Informative references ............................. 21 + 10.3. Client-Server Authentication with DTLS ............. 18 + 10.4. Network Address Translation ........................ 20 + 10.5. Wildcard Clients ................................... 20 + 10.6. Session Closing .................................... 20 + 10.7. Clients Subsystems ................................. 21 +11. References .............................................. 21 + 11.1. Normative references ............................... 21 + 11.2. Informative references ............................. 22 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. @@ -113,21 +114,24 @@ 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. This continuity ensures that existing network-layer infrastructure (firewall rules, etc.) does not need to be changed when RADIUS clients and servers are upgraded to - support RADIUS over DTLS. + support RADIUS over DTLS. It is RECOMMENDED that firewalls + performing packet inspection be configured to permit only DTLS over + the RADIUS/DTLS port. The alternative could be for then to either + block RADIUS/DTLS, or allow another, non-standard protocol. 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 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. 1.1. Terminology @@ -198,21 +202,23 @@ "RADIUS/DTLS". The requirement that RADIUS remain largely unchanged ensures the simplest possible implementation and widest interoperability of this specification. We note that the DTLS encapsulation of RADIUS means that RADIUS packets have an additional overhead due to DTLS. Implementations MUST support encapsulated RADIUS packets of 4096 in length, with a corresponding increase in the maximum size of the encapsulated DTLS - packets. + packets. This larger packet size may cause the packet to be larger + than the Path MTU (PMTU), where a RADIUS/UDP packet may be smaller. + See Section 5.2, below, for more discussion. The only changes made from RADIUS/UDP to RADIUS/DTLS are the following two items: (1) The Length checks defined in [RFC2865] Section 3 MUST use the length of the decrypted DTLS data instead of the UDP packet length. (2) The shared secret secret used to compute the MD5 integrity checks and the attribute encryption MUST be "radius/dtls". @@ -254,50 +260,39 @@ Most of Section 2.3 applies also to RADIUS/DTLS. Item (1) should be interpreted as applying to DTLS session initiation, instead of TCP connection establishment. Item (2) applies, except for the recommendation that implementations "SHOULD" support TLS_RSA_WITH_RC4_128_SHA. This recommendation is a historical artifact of RADIUS/TLS, and does not apply to RADIUS/DTLS. Item (3) applies to RADIUS/DTLS. Item (4) applies, except that the fixed shared secret is "radius/dtls", as described above. - Section 2.4 applies to RADIUS/DTLS. Client identies can be + Section 2.4 applies to RADIUS/DTLS. Client identities SHOULD be determined from TLS parameters, instead of relying solely on the source IP address of the packet. Section 2.5 does not apply to RADIUS/DTLS. The relationship between RADIUS packet codes and UDP ports in RADIUS/DTLS is unchanged from RADIUS/UDP. Sections 3.1, 3.2, and 3.3 apply to RADIUS/DTLS. Section 3.4 item (1) does not apply to RADIUS/DTLS. Each RADIUS packet is encapsulated in one DTLS packet, and there is no "stream" of RADIUS packets inside of a TLS session. Implementors MUST enforce the requirements of [RFC2865] Section 3 for the RADIUS Length field, using the length of the decrypted DTLS data for the checks. This check replaces the RADIUS method of using the length field from the UDP packet. - Section 3.4 item (3) applies to RADIUS/DTLS when the new port is - used. When DTLS is used over the existing RADIUS/UDP ports, the - relationship between RADIUS packet codes and UDP ports in RADIUS/DTLS - is unchanged from RADIUS. - - Section 3.4 item (4) applies to RADIUS/DTLS when the new port is - used. When DTLS is used over the existing RADIUS/UDP ports, the use - of negative ICMP responses is unchanged from RADIUS. - - Section 3.4 item (5) applies to RADIUS/DTLS when the new port is - used. When DTLS is used over the existing RADIUS/UDP ports, the use - of negative ICMP responses is unchanged from RADIUS. + Section 3.4 items (2), (3), (4), and (5) apply to RADIUS/DTLS. Section 4 does not apply to RADIUS/DTLS. Protocol compatibility considerations are defined in this document. 2.2.2. Reinforcement of RADIUS/TLS We re-iterate that much of [RFC6614] applies to this document. Specifically, Section 4 and Section 6 of that document are applicable to RADIUS/DTLS. @@ -336,20 +331,21 @@ 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. 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. 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 @@ -364,22 +360,21 @@ 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. RADIUS/DTLS clients SHOULD NOT probe servers to see if they support - DTLS transport. Doing so could cause problems for servers which do - not implement DTLS. Instead, clients SHOULD use DTLS as a transport + DTLS transport. Instead, clients SHOULD use DTLS as a transport layer only when administratively configured. RADIUS clients often had multiple independent RADIUS implementations, or processes that originate packets. This practice was simple to implement, but means 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. Clients may implement "pools" of servers for fail-over or load- @@ -405,62 +400,61 @@ 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 Connection Management A RADIUS/DTLS server MUST track ongoing DTLS client connections based - on a key composed of the following 4-tuple: + the following 4-tuple: * source IP address * source port * destination IP address * destination port - Note that this key is independent of IP address version (IPv4 or + Note that this 4-tuple is independent of IP address version (IPv4 or IPv6). - Each entry associated with a key contains the following information: + Each entry associated with a 4-tuple contains the following + information: DTLS Data An implementation-specific variable containing information about the active DTLS connection. Last Taffic A variable containing a timestamp which indicates when this connection last received valid traffic. Each entry may contain other information, such as idle timeouts, connection lifetimes, and other implementation-specific data. 5.1.1. Session Management 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. The requirement to accept RADIUS/UDP and RADIUS/DTLS on the - same port makes this recommendation difficult to implement in - practice. Server implementation SHOULD therefore have a way of - tracking partially setup DTLS connections. Servers SHOULD limit both - the number and impact on resources of partial connections. + value. Server implementation SHOULD have a way of tracking partially + setup DTLS connections. Servers SHOULD limit both the number and + impact on resources of partial connections. - Sessions (both key and entry) MUST deleted when a TLS Closure Alert - ([RFC5246] Section 7.2.1) or a fatal TLS Error Alert ([RFC5246] - Section 7.2.2) is received. When a session is deleted due to failed - security, the DTLS session MUST be closed, and any TLS session - resumption parameters for that session MUST be discarded, and all - tracking information MUST be deleted. + Sessions (both 4-tuple and entry) MUST be deleted when a TLS Closure + Alert ([RFC5246] Section 7.2.1) or a fatal TLS Error Alert ([RFC5246] + Section 7.2.2) is received. When a session is deleted due to it + failing security requirements, the DTLS session MUST be closed, and + any TLS session resumption parameters for that session MUST be + discarded, and all tracking information MUST be deleted. 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. @@ -523,29 +517,29 @@ or unexpected packets will be ignored by the DTLS layer. The above requirement is mitigated by the suggestion in Section 6.1, below, that the client use a local proxy for all RADIUS traffic. That proxy can then track the ports which it uses, and ensure that re-use of 4-tuples is avoided. The exact process by which this tracking is done is outside of the scope of this document. 5.2. Client Connection Management - Clients SHOULD use Path MTU (PMTU) discovery [RFC6520] to determine - the PMTU between the client and server, prior to sending any RADIUS - traffic. Once a DTLS session is established, a RADIUS/DTLS client - SHOULD use DTLS Heartbeats [RFC6520] to determine connectivity - between the two systems. Alternatively, RADIUS/DTLS clients may use - the application-layer watchdog algorithm defined in [RFC3539] to - determine server responsiveness. The Status-Server packet defined in - [RFC5997] SHOULD be used as the "watchdog packet" in any application- - layer watchdog algorithm. + Clients SHOULD use PMTU discovery [RFC6520] to determine the PMTU + between the client and server, prior to sending any RADIUS traffic. + Once a DTLS session is established, a RADIUS/DTLS client SHOULD use + DTLS Heartbeats [RFC6520] to determine connectivity between the two + systems. Alternatively, RADIUS/DTLS clients may use the application- + layer watchdog algorithm defined in [RFC3539] to determine server + responsiveness. The Status-Server packet defined in [RFC5997] SHOULD + be used as the "watchdog packet" in any application-layer watchdog + algorithm. RADIUS/DTLS clients SHOULD pro-actively close sessions when they have been idle for a period of time. Clients SHOULD close a session when the DTLS Heartbeat algorithm indicates that the session is no longer active. Clients SHOULD close a session when no traffic other than watchdog packets and (possibly) watchdog responses have been sent for three watchdog timeouts. This behavior ensures that clients do not waste resources on the server by causing it to track idle sessions. A client may choose to avoid DTLS heartbeats and watchdog packets @@ -585,21 +579,22 @@ additional implementation guidelines. These guidelines are not part of the protocol, but may help implementors create simple, secure, and inter-operable implementations. 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 hex strings. + allows for the keys to be entered as humanly readable strings in hex + format. It is RECOMMENDED that keys be derived from a cryptographically secure pseudo-random number generator (CSPRNG). 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 @@ -692,65 +687,58 @@ following ways: o Reference: list the RFC number of this document as the 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." 10. Security Considerations - This entire specification is devoted to discussing security + 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 this specification. All of the security considerations for RADIUS apply to the RADIUS portion of the specification. However, many security considerations raised in the RADIUS documents are related to RADIUS encryption and authorization. Those issues are largely mitigated when DTLS is used as a transport method. The issues that are not mitigated by this specification are related to the RADIUS packet format and handling, which is unchanged in this specification. - The main portion of the specification that could have security - implications is a servers ability to accept both RADIUS and DTLS - packets on the same port. The filter that disambiguates the two - protocols is simple, and is just a check for the value of one octet. - We do not expect this check to have any security issues. - - We also note that nothing prevents malicious clients from sending - DTLS packets to existing RADIUS implementations, or RADIUS packets to - existing DTLS implementations. There should therefore be no issue - with clients sending RADIUS/DTLS packets to legacy servers that do - not support the protocol. These packets will be silently discarded, - and will not change the security profile of the server. - This specification also suggests that implementations use a connection tracking table. This table is an extension of the duplicate detection cache mandated in [RFC5080] Section 2.2.2. The changes given here are that DTLS-specific information is tracked for each table entry. Section 5.1.1, above, describes steps to mitigate any DoS issues which result from tracking additional information. + 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. + 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. 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. + 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. 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 @@ -788,71 +776,132 @@ 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. Network Address Translation +10.3. 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 + determined from TLS parameters. Any authentication credentials for + that client are then determined solely from the client identity, and + not from an IP address. + + 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 + 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. + + The above requirement is best 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. The + traffic would be secure from third-party observers. The invalid + 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. Instead, the clients SHOULD start off with an empty CA + list. The addition of a CA SHOULD be done only when manually + configured by an administrator. + + This scenario is the opposite of web browsers, where they are pre- + configured with many known CAs. The goal there is security from + third-party observers, but also the ability to communicate with any + unknown site which presents a signed certificate. In contrast, the + goal of RADIUS/DTLS is both security from third-party observers, and + the ability to communicate with only a small set of well-known + 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 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, it would permit a downgrade attack to occur, and would negate all of the security added by RADIUS/DTLS. As a result, RADIUS 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.4. Wildcard Clients +10.5. 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 + netmask of other than 128. That practice is not recommended for RADIUS/UDP, as it means multiple clients use the same shared secret. - When a client is a "wildcard", RADIUS/DTLS MUST be used. Clients - MUST be uniquely identified, and any certificate or PSK used MUST be - unique to each client. + 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.5. Session Closing +10.6. Session Closing - Section 5.1.1 above requires that DTLS sessions be closed when the - transported RADIUS packets are malformed, or fail various - authenticator checks. This requirement is due to security - considerations. + 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 connection is expected to be used for + transport of RADIUS packets only. - When an implementation has a DTLS connection, it is expected that the - connection be used to transport RADIUS. Any non-RADIUS traffic on - that connection means the other party is misbehaving, and a potential - security risk. Similarly, any RADIUS traffic failing validation - means that two parties do not share the same security parameters, and - the session is therefore a security risk. + Any non-RADIUS traffic on that connection 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 connection to close. - Therefore, in other situations, the session may remain open in the + Therefore, in other situations, the session SHOULD remain open in the face of non-conformant packets. -10.6. Clients Subsystems +10.7. Clients 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