--- 1/draft-ietf-radext-dtls-05.txt 2013-07-12 06:14:26.132725269 -0700 +++ 2/draft-ietf-radext-dtls-06.txt 2013-07-12 06:14:26.176726357 -0700 @@ -1,20 +1,20 @@ Network Working Group Alan DeKok INTERNET-DRAFT FreeRADIUS Category: Experimental - -Expires: October 17, 2013 -17 April 2013 + +Expires: January 12, 2014 +12 July 2013 DTLS as a Transport Layer for RADIUS - draft-ietf-radext-dtls-05 + draft-ietf-radext-dtls-06 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 @@ -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 July 28, 2013 + This Internet-Draft will expire on January 12, 2014 Copyright Notice Copyright (c) 2013 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 @@ -61,46 +61,44 @@ Table of Contents 1. Introduction ............................................. 4 1.1. Terminology ......................................... 4 1.2. Requirements Language ............................... 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 2.2.2. Reinforcement of RADIUS/TLS .................... 8 -3. Transition Path .......................................... 8 +3. Interaction with RADIUS/UDP .............................. 8 3.1. DTLS Port and Packet Types .......................... 9 - 3.2. Server Transition to DTLS ........................... 9 -4. Client Transition ........................................ 10 -5. Connection Management .................................... 12 - 5.1. Server Connection Management ........................ 12 - 5.1.1. Session Management ............................. 13 - 5.1.2. Protocol Disambiguation ........................ 14 - 5.1.3. Processing Algorithm ........................... 15 - 5.2. Client Connection Management ........................ 17 -6. Implementation Guidelines ................................ 18 - 6.1. Client Implementations .............................. 18 - 6.2. Server Implementations .............................. 19 -7. Implementation Experience ................................ 19 -8. Diameter Considerations .................................. 20 -9. IANA Considerations ...................................... 20 -10. Security Considerations ................................. 20 - 10.1. Legacy RADIUS Security ............................. 21 - 10.2. Resource Exhaustion ................................ 22 - 10.3. Network Address Translation ........................ 22 - 10.4. Wildcard Clients ................................... 23 - 10.5. Session Closing .................................... 23 - 10.6. Clients Subsystems ................................. 23 -11. References .............................................. 24 - 11.1. Normative references ............................... 24 - 11.2. Informative references ............................. 25 + 3.2. Server Behavior ..................................... 9 +4. Client Behavior .......................................... 10 +5. Connection Management .................................... 10 + 5.1. Server Connection Management ........................ 11 + 5.1.1. Session Management ............................. 11 + 5.2. Client Connection Management ........................ 13 +6. Implementation Guidelines ................................ 14 + 6.1. Client Implementations .............................. 15 + 6.2. Server Implementations .............................. 15 +7. Implementation Experience ................................ 16 +8. Diameter Considerations .................................. 16 +9. IANA Considerations ...................................... 16 +10. Security Considerations ................................. 17 + 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 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. @@ -185,21 +183,20 @@ * Response Authenticator calculation * Minimum packet length * Maximum packet length * Attribute format * Vendor-Specific Attribute (VSA) format * Permitted data types * Calculations of dynamic attributes such as CHAP-Challenge, or Message-Authenticator. * Calculation of "obfuscated" attributes such as User-Password and Tunnel-Password. - * UDP port numbering and relationship between code and port In short, the application creates a RADIUS packet via the usual methods, and then instead of sending it over a UDP socket, sends the packet to a DTLS layer for encapsulation. DTLS then acts as a transport layer for RADIUS, hence the names "RADIUS/UDP" and "RADIUS/DTLS". The requirement that RADIUS remain largely unchanged ensures the simplest possible implementation and widest interoperability of this specification. @@ -243,21 +240,21 @@ between the two specifications. The next section reviews some more detailed changes from [RFC6614], giving additional commentary only where necessary. 2.2.1. Changes from RADIUS/TLS to RADIUS/DTLS This section describes where this specification is similar to [RFC6614], and where it differs. Section 2.1 applies to RADIUS/DTLS, with the exception that the - RADIUS/DTLS port is UDP/TBD. + RADIUS/DTLS port is UDP/2083. Section 2.2 applies to RADIUS/DTLS. Servers and clients need to be preconfigured to use RADIUS/DTLS for a given endpoint. 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) @@ -297,167 +294,104 @@ 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. -3. Transition Path +3. Interaction with RADIUS/UDP Transitioning to DTLS is a process which needs to be done carefully. A poorly handled transition is complex for administrators, and potentially subject to security downgrade attacks. It is not sufficient to just disable RADIUS/UDP and enable RADIUS/DTLS. That approach 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. - This section describes how clients and servers should transition to - DTLS. There is a fair amount of discussion around this transition, - as it is critical to get it correct. We expect that once - implementations have transitioned to RADIUS/DTLS, the text in this - section will no longer be relevant. + 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/TBD There - are no separate ports for authentication, accounting, and dynamic - authorization changes. The source port is arbitrary. The text above - in Section 2.2.1 describes issues surrounding the use of one port for - multiple packet types, by referencing [RFC6614] Section 3.4. - -3.2. Server Transition to DTLS - - When a server receives packets on the assigned RADIUS/DTLS port, all - packets MUST be treated as being DTLS. RADIUS/UDP packets MUST NOT - be accepted on this port. The transition path described in this - section MUST NOT be used for that port. - - Servers MAY accept DTLS packets on the old RADIUS/UDP ports. In that - case, we require a method to disambiguate packets between the two - protocols. This method is applicable only to RADIUS/DTLS servers. - - The disambiguation method leverages the RADIUS/UDP requirement that - clients be known by source IP address. RADIUS/DTLS servers MUST - treat packets from unknown IP addresses as being DTLS. This - requirement does not mean that the server is required to accept these - packets. It means that if the server chooses to accept them, they - are to be treated as being DTLS. + 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 Section 2.2.1 describes issues surrounding the use of + one port for multiple packet types, by referencing [RFC6614] Section + 3.4. - For packets from known IP addresses RADIUS/DTLS servers MUST maintain - a boolean "DTLS Required" flag for each client that indicates if it - requires a client to use RADIUS/DTLS. If the flag is "true" then all - packets from that client MUST be processed as RADIUS/DTLS. +3.2. Server Behavior - The transition to RADIUS/DTLS is performed only when the "DTLS - Required" flag is "false". This setting means that the client is - known to support RADIUS/UDP, but may also support RADIUS/DTLS. - Packets from the client need to be examined to see if they are - RADIUS/UDP or RADIUS/DTLS. The protocol disambiguation method - outlined below in Section 5.1.2 MUST be used to determine how - received packets are treated. + 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. - The "DTLS Required" flag MUST be exposed to administrators of the - server. As clients are upgraded, administrators can then manually - mark them as using RADIUS/DTLS. The default value for the flag - SHOULD be "false". DTLS configuration parameters (e.g. certificates, - pre-shared keys, etc.) SHOULD be exposed to the administrator, even - if the "DTLS Required" flag is set to "false". Adding these - parameters means that the client may use DTLS, though it is not - required. + 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. - It is RECOMMENDED that the default value for the "DTLS Required" flag - be set to "true" when this specification has acheived wide-spread - adoption. + 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. - Once a RADIUS/DTLS server has established a DTLS session with a - client that previously had the flag set to "false", the server SHOULD - set the "DTLS Required" flag to "true". This change suggests that - subsequent traffic from that client to use DTLS, and prevents - bidding-down attacks. The server SHOULD also notify the - administrator that it has successfully established the first DTLS - session with that client. + 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. - The above requirement means that RADIUS/DTLS servers are subject to - downbidding attacks. A client can use DTLS for a period of time, and - then subsequently revert to using UDP. This attack is permitted in - order to allow an transition period from UDP to DTLS transport. It - is RECOMMENDED that administators set the "DTLS Required" flag - manually for each client after is has been seen to be using DTLS. + 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. - The above requirement is largely incompatible with the use of - multiple RADIUS/UDP clients behind a Network Address Translation - (NAT) gateway, as noted below in Section 10.3. + 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". - Note that this last requirement on servers can impose significant - changes for clients. These changes are discussed in the next - section. + Allowing RADIUS/UDP and RADIUS/DTLS from the same client exposes the + traffic to downbidding attacks, and is NOT RECOMMENDED. -4. Client Transition +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. The transition path described in this section MUST NOT be used - for packets sent to that port. - - Servers MAY accept DTLS packets to the old RADIUS/UDP ports. In that - case, we require guidelines for when to use one or the other. This - method is applicable only to RADIUS/DTLS clients. - - RADIUS/DTLS clients MUST maintain a boolean "DTLS Required" flag for - each server that indicates if that server requires it to use - RADIUS/DTLS. If the flag is "true" then the server supports - RADIUS/DTLS, and all packets sent to that server MUST be RADIUS/DTLS. - If the flag is "false", then the server supports RADIUS/UDP, but may - still support RADIUS/DTLS. Packets sent to that server MUST be - RADIUS/UDP. - - The "DTLS Required" flag MUST be exposed to administrators of the - client. As servers are upgraded, administrators can then manually - mark them as using RADIUS/DTLS. The default value for the flag - SHOULD be "false". DTLS configuration parameters (e.g. certificates, - pre-shared keys, etc.) SHOULD be exposed to the administrator, even - if the "DTLS Required" flag is set to "false". - - Adding DTLS configuration parameters means that the client MUST start - using DTLS to the server for all new requests. The client MUST, - however, accept RADIUS/UDP responses to any outstanding RADIUS/UDP - requests. It is RECOMMENDED that a client wait for all responses to - RADIUS/UDP requests before sending RADIUS/DTLS traffic to a - particular server. This suggestion means that the server sees a - "clean" transition from one protocol to another. Having the client - send a mix of RADIUS/UDP and RADIUS/DTLS traffic is problematic. - - It is RECOMMENDED that the default value for the "DTLS Required" flag - be set to "true" when this specification has acheived wide-spread - adoption. + port. RADIUS/DTLS clients SHOULD NOT probe servers to see if they support - DTLS transport. Doing so would cause servers to immediately require - that all new packets from the client use DTLS. This requirement may - be difficult for a client to satisfy. Instead, clients SHOULD use - DTLS as a transport layer only when administratively configured. + DTLS transport. Doing so could cause problems for servers which do + not implement DTLS. Instead, clients SHOULD use DTLS as a transport + layer only when administratively configured. - The requirements of this specification mean that RADIUS/DTLS clients - can no longer have multiple independent RADIUS implementations, or - processes that originate RADIUS/UDP and RADIUS/DTLS packets. - Instead, clients MUST use only one transport layer to communicate - with a specific server. It is RECOMMENDED that clients use a local - proxy as described in Section 6.1, below. + 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- + balancing. These pools SHOULD NOT mix RADIUS/UDP and RADIUS/DTLS + servers. 5. Connection Management Where [RFC6614] can rely on the TCP state machine to perform connection tracking, this specification cannot. As a result, implementations of this specification may need to perform connection management of the DTLS session in the application layer. This section describes logically how this tracking is done. Implementations may choose to use the method described here, or another, equivalent method. @@ -465,46 +399,41 @@ We note that [RFC5080] Section 2.2.2 already mandates a duplicate detection cache. The connection tracking described below can be seen as an extension of that cache, where entries contain DTLS sessions instead of RADIUS/UDP packets. [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 a retransmitted response - is sent. + 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 client connections based on a - key composed of the following 4-tuple: + A RADIUS/DTLS server MUST track ongoing DTLS client connections based + on a key composed of 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 IPv6). Each entry associated with a key contains the following information: -Protocol Type - A flag which is either "RADIUS/UDP" for old-style RADIUS traffic, - or "RADIUS/DTLS" for RADIUS/DTLS connections. - DTLS Data An implementation-specific variable containing information about - the active DTLS connection. For non-DTLS connections, this - variable MUST be empty. + 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 @@ -571,118 +500,20 @@ they are tracking. They SHOULD stop the creating of new sessions when a large number are already being tracked. This "maximum sessions" number SHOULD be exposed to administrators as a configurable setting. RADIUS/DTLS servers SHOULD implement session resumption, preferably stateless session resumption as given in [RFC5077]. This practice lowers the time and effort required to start a DTLS session with a client, and increases network responsiveness. -5.1.2. Protocol Disambiguation - - When the "DTLS Required" flag for a client is set to "false", the - client may, or may not be sending DTLS packets. For existing - connections, protocol disambiguation is simple, the "Protocol Type" - field in the session tracking entry is examined. New connections - must still be disambiguated. - - In order to provide a robust upgrade path, the RADIUS/DTLS server - MUST examine the packet to see if it is RADIUS/UDP or RADIUS/DTLS. - This examination method is defined here. - - We justify the examination methods by analysing the packet formats - for the two protocols. We assume that the server has a buffer in - which it has received a UDP packet matching no entry based on the - 4-tuple key defined above. It must then analyse this buffer to - determine which protocol is used to process the packet. - - The DTLS record format ([RFC6347] Section 4.1) is shown below, in - pseudo-code: - - struct { - uint8 type; - uint16 version; - uint16 epoch; - uint48 sequence_number; - uint16 length; - uint8 fragment[DTLSPlaintext.length]; - } DTLSPlaintext; - - The RADIUS record format ([RFC2865] Section 3) is shown below, in - pseudo-code, with AuthVector.length=16. - - struct { - uint8 code; - uint8 id; - uint16 length; - uint8 vector[AuthVector.length]; - uint8 data[RadiusPacket.length - 20]; - } RadiusPacket; - - We can see here that a number of fields overlap between the two - protocols. At first glance, it seems difficult for an application to - accept both protocols on the same port. However, this is not the - case. - - The initial DTLS packet of a connection requires that the type field - (first octet) has value 22 (handshake). The first octet of a RADIUS - packet is the code field. The code value of 22 has been assigned as - Resource-Free-Response. That code is intended to be a response from - a server to a client, and will therefore never be sent by a client to - a server. - - As a result, protocol disambiguation for new connections to a server - is straightforward. Only the first octet of the packet needs to be - examined to disambiguate RADIUS/DTLS from RADIUS/UDP. If that octet - has value 22, then the packet is likely to be RADIUS/DTLS. - Otherwise, the packet is likely to be RADIUS/UDP. - -5.1.3. Processing Algorithm - - When a RADIUS/DTLS server recieves a packet, it uses the following - algorithm to process that packet. As with RADIUS/UDP, packets from - unknown clients MUST be silently discarded. - - The "DTLS Required" flag for that client is examined. If it is set - to "true", then the packet MUST be processed as RADIUS/DTLS. - - If the "DTLS Required" flag is set to "false", the session is looked - up using the 4-tuple key defined above. Packets matching an existing - entry MUST be processed as defined by the "Protocol Type" field of - that entry. - - If the "DTLS Required" flag is set to "false" and no matching entry - has been found, then the first octet of the packet is examined. If - it has value 22, then the packet MUST be processed as RADIUS/DTLS. - Otherwise, the packet MUST be processed as RADIUS/UDP. - - In all cases, the packet MUST be checked for correctness. For - RADIUS/UDP, any packets which are silently discarded MUST NOT affect - the state of any variable in session tracking entry. For - RADIUS/DTLS, any packets which are discarded by the DTLS layer MUST - NOT affect the state of any variable in the session tracking entry. - - When the packet matches an existing key, and is accepted for - processing by the server, it is processed via the method indicated in - that entry. Where the packet does not match an existing key, a new - entry is created for that key. The "Protocol Type" flag for that - entry is set to "RADIUS/DTLS", or "RADIUS/UDP", as determined by - examining the first octet of the packet. - - When a server has the clients "DTLS Required" flag set to "false", it - MUST set the flag to "true" after establishing a DTLS session with - that client. It MUST NOT set the flag to "true" until a DTLS session - has been fully established. Doing so would mean that attackers could - perform a DoS attack by sending forged DTLS ClientHello packets to a - server. - Since UDP is stateless, the potential exists for the client to initiate a new DTLS session using a particular 4-tuple, before the server has closed the old session. For security reasons, the server must keep the old session active until it has received secure notification from the client that the session is closed. Or, when the server has decided for itself that the session is closed. Taking any other action would permit unauthenticated clients to perform a DoS attack, by closing active DTLS session. As a result, servers MUST ignore any attempts to re-use an existing @@ -730,25 +561,20 @@ implement DTLS heartbeats and/or watchdog packets for all DTLS sessions. 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 MUST NOT send both RADIUS/UDP and RADIUS/DTLS - packets over the same key of (source IP, source port, destination IP, - destination port) as defined in Section 4.1, above . Doing so would - make it impossible to correctly process either kind of packet. - RADIUS/DTLS clients SHOULD NOT send both RADIUS/UDP and RADIUS/DTLS packets to different servers from the same source socket. This practice causes increased complexity in the client application, and increases the potential for security breaches due to implementation issues. RADIUS/DTLS clients SHOULD implement session resumption, preferably stateless session resumption as given in [RFC5077]. This practice lowers the time and effort required to start a DTLS session with a server, and increases network responsiveness. @@ -805,22 +631,22 @@ then re-write any subsystem-specific NAS-Identifier to a NAS- Identifier which identifies the client as a whole. Or, remove NAS- Identifier entirely and replace it with NAS-IP-Address or NAS- IPv6-Address. In traditional RADIUS, the cost to set up a new "session" between a client and server was minimal. The client subsystem could simply open a port, send a packet, wait for the response, and the close the port. With RADIUS/DTLS, the connection setup is significantly more expensive. In addition, there may be a requirement to use DTLS in - order to communicate with a server, so that traditional RADIUS would - be ignored by that server. The knowledge of what protocol to use is + order to communicate with a server, as RADIUS/UDP may not be + supported by that server. The knowledge of what protocol to use is best managed by a dedicated RADIUS subsystem, rather than by each 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. @@ -854,23 +680,29 @@ requirement is satisfied by leveraging DTLS. 8. 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 - This specification allocates a new UDP port, called "RADIUS-DTLS". - The references to "UDP/TBD" in this document need to be updated to - use the allocated port number. + 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: + + 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 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 @@ -934,21 +766,21 @@ 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 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 previous RADIUS practice of using shared secrets that are minor + The historic RADIUS practice of using shared secrets that are minor variations of words is NOT RECOMMENDED, as it would negate all of the security of DTLS. 10.2. 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 @@ -963,48 +795,43 @@ limits SHOULD be exposed to the administrator as configurable settings. 10.3. 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. - The migration flag described above in Section 3 is also tracked per - source IP address. Using a NAT in front of many RADIUS clients - negates the function of the flag, making it impossible to migrate - multiple clients in a secure fashion. - 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 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. - When a client is a "wildcard", then RADIUS/DTLS MUST be used. - Clients MUST be uniquely identified, and any certificate or PSK used - MUST be unique to each client. + 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. 10.5. 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. When an implementation has a DTLS connection, it is expected that the connection be used to transport RADIUS. Any non-RADIUS traffic on