summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc7360.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc7360.txt')
-rw-r--r--doc/rfc/rfc7360.txt1515
1 files changed, 1515 insertions, 0 deletions
diff --git a/doc/rfc/rfc7360.txt b/doc/rfc/rfc7360.txt
new file mode 100644
index 0000000..5ed92d2
--- /dev/null
+++ b/doc/rfc/rfc7360.txt
@@ -0,0 +1,1515 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) A. DeKok
+Request for Comments: 7360 FreeRADIUS
+Category: Experimental September 2014
+ISSN: 2070-1721
+
+
+ Datagram Transport Layer Security (DTLS)
+ as a Transport Layer for RADIUS
+
+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
+ also describes how implementations of this proposal can coexist with
+ current RADIUS systems.
+
+Status of This Memo
+
+ This document is not an Internet Standards Track specification; it is
+ published for examination, experimental implementation, and
+ evaluation.
+
+ This document defines an Experimental Protocol for the Internet
+ community. This document is a product of the Internet Engineering
+ Task Force (IETF). It represents the consensus of the IETF
+ community. It has received public review and has been approved for
+ publication by the Internet Engineering Steering Group (IESG). Not
+ all documents approved by the IESG are a candidate for any level of
+ Internet Standard; see Section 2 of RFC 5741.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ http://www.rfc-editor.org/info/rfc7360.
+
+
+
+
+
+
+
+
+
+
+
+
+
+DeKok Experimental [Page 1]
+
+RFC 7360 DTLS as a Transport Layer for RADIUS September 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
+ to this document. Code Components extracted from this document must
+ 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+DeKok Experimental [Page 2]
+
+RFC 7360 DTLS as a Transport Layer for RADIUS September 2014
+
+
+Table of Contents
+
+ 1. Introduction ....................................................4
+ 1.1. Terminology ................................................5
+ 1.2. Requirements Language ......................................5
+ 1.3. Document Status ............................................5
+ 2. Building on Existing Foundations ................................6
+ 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 .............................................12
+ 5.1. Server Session Management .................................12
+ 5.1.1. Session Opening and Closing ........................13
+ 5.2. Client Session Management .................................15
+ 6. Implementation Guidelines ......................................16
+ 6.1. Client Implementations ....................................17
+ 6.2. Server Implementations ....................................18
+ 7. Diameter Considerations ........................................18
+ 8. IANA Considerations ............................................18
+ 9. Implementation Status ..........................................18
+ 9.1. Radsecproxy ...............................................19
+ 9.2. jradius ...................................................19
+ 10. Security Considerations .......................................19
+ 10.1. Crypto-Agility ...........................................20
+ 10.2. Legacy RADIUS Security ...................................21
+ 10.3. Resource Exhaustion ......................................22
+ 10.4. Client-Server Authentication with DTLS ...................22
+ 10.5. Network Address Translation ..............................24
+ 10.6. Wildcard Clients .........................................24
+ 10.7. Session Closing ..........................................25
+ 10.8. Client Subsystems ........................................25
+ 11. References ....................................................26
+ 11.1. Normative References .....................................26
+ 11.2. Informative References ...................................27
+ Acknowledgments ...................................................27
+
+
+
+
+
+
+
+
+
+
+
+
+DeKok Experimental [Page 3]
+
+RFC 7360 DTLS as a Transport Layer for RADIUS September 2014
+
+
+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 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 it 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 UDP-based
+ protocol. The change from RADIUS/UDP is largely to add DTLS support,
+ and make any necessary related changes to RADIUS. This allows
+ implementations to remain UDP based, without changing to a TCP
+ architecture.
+
+ This specification does not, however, solve all of the problems
+ associated with RADIUS/UDP. The DTLS protocol does not add reliable
+ or in-order transport to RADIUS. DTLS also does not support
+ fragmentation of application-layer messages, or of the DTLS messages
+ themselves. This specification therefore shares with traditional
+ RADIUS the issues of order, reliability, and fragmentation. These
+ issues are dealt with in RADIUS/TCP [RFC6613] and RADIUS/TLS
+ [RFC6614].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+DeKok Experimental [Page 4]
+
+RFC 7360 DTLS as a Transport Layer for RADIUS September 2014
+
+
+1.1. Terminology
+
+ This document uses the following terms:
+
+ RADIUS/DTLS
+ This term is a shorthand for "RADIUS over DTLS".
+
+ RADIUS/DTLS client
+ This term refers both to RADIUS clients as defined in [RFC2865]
+ and to Dynamic Authorization clients as defined in [RFC5176] that
+ implement RADIUS/DTLS.
+
+ RADIUS/DTLS server
+ This term refers both to RADIUS servers as defined in [RFC2865]
+ and to Dynamic Authorization servers as defined in [RFC5176] that
+ implement RADIUS/DTLS.
+
+ RADIUS/UDP
+ RADIUS over UDP, as defined in [RFC2865].
+
+ RADIUS/TLS
+ RADIUS over TLS, as defined in [RFC6614].
+
+ silently discard
+ This means that the implementation discards the packet without
+ further processing.
+
+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", "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.
+
+ It contains one of several approaches to address known cryptographic
+ weaknesses of the RADIUS protocol, such as described in [RFC6614].
+ This specification does not fulfill all recommendations for an
+ Authentication, Authorization, and Accounting (AAA) transport profile
+ as per [RFC3539]; however, unlike [RFC6614], it is based on UDP and
+ therefore does not have head-of-line blocking issues.
+
+
+
+
+
+
+DeKok Experimental [Page 5]
+
+RFC 7360 DTLS as a Transport Layer for RADIUS September 2014
+
+
+ If this specification is indeed selected for advancement to Standards
+ Track, certificate verification options ([RFC6614], Section 2.3,
+ point 2) will need 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, by using
+ TLS-PSK ciphersuites. RADIUS/DTLS also allows the use of X.509
+ certificates in a PKIX infrastructure. It remains to be seen if one
+ of these methods will prevail or if both will find their place in
+ real-life deployments. The authors can imagine pre-shared keys
+ (PSKs) 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+DeKok Experimental [Page 6]
+
+RFC 7360 DTLS as a Transport Layer for RADIUS September 2014
+
+
+2.1. Changes to RADIUS
+
+ The RADIUS packet format is unchanged from [RFC2865], [RFC2866], and
+ [RFC5176]. Specifically, all of the following portions of RADIUS
+ MUST be unchanged when using RADIUS/DTLS:
+
+ * Packet format
+ * Permitted codes
+ * Request Authenticator calculation
+ * 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.
+
+ 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.
+
+ We note that the DTLS encapsulation of RADIUS means that RADIUS
+ packets have an additional overhead due to DTLS. Implementations
+ MUST support sending and receiving encapsulated RADIUS packets of
+ 4096 octets in length, with a corresponding increase in the maximum
+ size of the encapsulated DTLS 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+DeKok Experimental [Page 7]
+
+RFC 7360 DTLS as a Transport Layer for RADIUS September 2014
+
+
+ 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. They MUST treat any decrypted DTLS data octets outside
+ the range of the Length field as padding and ignore it on
+ reception.
+
+ (2) The shared secret used to compute the MD5 integrity checks and
+ the attribute encryption MUST be "radius/dtls".
+
+ All other aspects of RADIUS are unchanged.
+
+2.2. Similarities with RADIUS/TLS
+
+ While this specification can be thought of as RADIUS/TLS over UDP
+ instead of the Transmission Control Protocol (TCP), there are some
+ differences between the two methods. The bulk of [RFC6614] applies
+ to this specification, so we do not repeat it here.
+
+ This section explains the differences between RADIUS/TLS and
+ RADIUS/DTLS, as semantic "patches" to [RFC6614]. The changes are as
+ follows:
+
+ * We replace references to "TCP" with "UDP"
+
+ * We replace references to "RADIUS/TLS" with "RADIUS/DTLS"
+
+ * We replace references to "TLS" with "DTLS"
+
+ Those changes are sufficient to cover the majority of the differences
+ 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 how particular sections of [RFC6614] apply to
+ RADIUS/DTLS.
+
+ Section 2.1 applies to RADIUS/DTLS, with the exception that the
+ RADIUS/DTLS port is UDP/2083.
+
+ Section 2.2 applies to RADIUS/DTLS. Servers and clients need to be
+ pre-configured to use RADIUS/DTLS for a given endpoint.
+
+
+
+
+
+DeKok Experimental [Page 8]
+
+RFC 7360 DTLS as a Transport Layer for RADIUS September 2014
+
+
+ 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 it 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 identities SHOULD be
+ determined from DTLS 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 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.
+
+ Section 6 applies to RADIUS/DTLS.
+
+3. Interaction with RADIUS/UDP
+
+ Transitioning to DTLS is a process that 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. 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.
+
+
+
+DeKok Experimental [Page 9]
+
+RFC 7360 DTLS as a Transport Layer for RADIUS September 2014
+
+
+ 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 in [RFC6614], Section 3.4, describes issues surrounding the use
+ of one port for multiple packet types. We recognize that
+ implementations may allow the use of RADIUS/DTLS over non-standard
+ ports. In that case, the references to UDP/2083 in this document
+ should be read as applying to any port used for transport of
+ RADIUS/DTLS traffic.
+
+3.2. Server Behavior
+
+ When a server receives packets on UDP/2083, all packets MUST be
+ treated as being DTLS. RADIUS/UDP packets MUST NOT be accepted on
+ this port.
+
+ Servers MUST NOT accept DTLS packets on the old RADIUS/UDP ports.
+ Early versions of this specification permitted this behavior. It is
+ forbidden here, as it depended on behavior in DTLS that may change
+ without notice.
+
+ Servers MUST authenticate clients. RADIUS is designed to be used by
+ mutually trusted systems. Allowing anonymous clients would ensure
+ privacy for RADIUS/DTLS traffic, but would negate all other security
+ aspects of the protocol.
+
+ As RADIUS has no provisions for capability signaling, there is no way
+ for a server to indicate to a client that it should transition to
+ using DTLS. This action has to be taken by the administrators of the
+ two systems, using a method other than RADIUS. This method will
+ likely be out of band, or manual configuration will need to be used.
+
+ Some servers maintain a list of allowed clients per destination port.
+ Others maintain a global list of clients that 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
+
+
+
+DeKok Experimental [Page 10]
+
+RFC 7360 DTLS as a Transport Layer for RADIUS September 2014
+
+
+ client on non-DTLS ports, for which DTLS is required, the server MUST
+ silently discard these packets, as there is no RADIUS/UDP shared
+ secret available.
+
+ This flag will often be set by an administrator. However, if a
+ server receives DTLS traffic from a client, it SHOULD notify the
+ administrator that DTLS is available for that client. It MAY mark
+ the client as "DTLS Required".
+
+ It is RECOMMENDED that servers support the following Perfect Forward
+ Secrecy (PFS) ciphersuites:
+
+ o TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
+
+ o TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
+
+ Allowing RADIUS/UDP and RADIUS/DTLS from the same client exposes the
+ traffic to downbidding attacks and is NOT RECOMMENDED.
+
+4. Client Behavior
+
+ When a client sends packets to the assigned RADIUS/DTLS port, all
+ packets MUST be DTLS. RADIUS/UDP packets MUST NOT be sent to this
+ port.
+
+ Clients MUST authenticate themselves to servers via credentials that
+ are unique to each client.
+
+ It is RECOMMENDED that clients support the following PFS
+ ciphersuites:
+
+ o TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
+
+ o TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
+
+ RADIUS/DTLS clients SHOULD NOT probe servers to see if they support
+ DTLS transport. Instead, clients SHOULD use DTLS as a transport
+ layer only when administratively configured. If a client is
+ configured to use DTLS and the server appears to be unresponsive, the
+ client MUST NOT fall back to using RADIUS/UDP. Instead, the client
+ should treat the server as being down.
+
+ RADIUS clients often had multiple independent RADIUS implementations
+ and/or processes that originate packets. This practice was simple to
+ implement, but the result is that each independent subsystem must
+ independently discover network issues or server failures. It is
+ therefore RECOMMENDED that clients with multiple internal RADIUS
+ sources use a local proxy as described in Section 6.1, below.
+
+
+
+DeKok Experimental [Page 11]
+
+RFC 7360 DTLS as a Transport Layer for RADIUS September 2014
+
+
+ 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
+ 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.
+
+ We note that [RFC5080], Section 2.2.2, already mandates a duplicate
+ detection cache. The session 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 it is necessary to
+ retransmit a RADIUS response.
+
+5.1. Server Session Management
+
+ A RADIUS/DTLS server MUST track ongoing DTLS sessions for each, based
+ on 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).
+
+
+
+
+
+
+
+
+
+
+
+
+
+DeKok Experimental [Page 12]
+
+RFC 7360 DTLS as a Transport Layer for RADIUS September 2014
+
+
+ Each 4-tuple points to a unique session entry, which usually contains
+ the following information:
+
+ DTLS Session
+ Any information required to maintain and manage the DTLS session.
+
+ Last Traffic
+ A variable containing a timestamp that indicates when this session
+ last received valid traffic. If "Last Traffic" is not used, this
+ variable may not exist.
+
+ DTLS Data
+ An implementation-specific variable that may contain information
+ about the active DTLS session. This variable may be empty or
+ nonexistent.
+
+ 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 DTLS
+ sessions that are partially set up. Servers MUST limit both the
+ number and impact on resources of partial sessions.
+
+ 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, 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 Network Access Server
+ (NAS) that is not implementing RADIUS.
+
+
+
+
+
+DeKok Experimental [Page 13]
+
+RFC 7360 DTLS as a Transport Layer for RADIUS September 2014
+
+
+ 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
+ that do not implement an application-layer watchdog MUST also
+ 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
+ labeled "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 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
+ administrators as a configurable parameter. When this maximum is
+ reached and a new session is started, the server MUST either drop an
+ old session in order to open the new one or not create a new session.
+
+
+
+
+
+DeKok Experimental [Page 14]
+
+RFC 7360 DTLS as a Transport Layer for RADIUS September 2014
+
+
+ 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.
+
+ 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 either it has received secure
+ notification from the client that the session is closed or the server
+ decides to close the session based on idle timeouts. Taking any
+ other action would permit unauthenticated clients to perform a DoS
+ attack, by reusing a 4-tuple and thus causing the server to close an
+ active (and authenticated) DTLS session.
+
+ As a result, servers MUST ignore any attempts to reuse an existing
+ 4-tuple from an active session. This requirement can likely be
+ reached by simply processing the packet through the existing session,
+ as with any other packet received via that 4-tuple. Non-compliant,
+ 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 that it uses and ensure that
+ reuse 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 Session Management
+
+ 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. RADIUS/DTLS clients SHOULD also 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 proactively 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 has 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.
+
+
+
+
+
+DeKok Experimental [Page 15]
+
+RFC 7360 DTLS as a Transport Layer for RADIUS September 2014
+
+
+ When a client fails to implement both DTLS Heartbeats and watchdog
+ packets, it has no way of knowing that a DTLS session has been
+ closed. Therefore, there is 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 all DTLS sessions be
+ 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
+ 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.
+
+6. Implementation Guidelines
+
+ The text above describes the protocol. In this section, we give
+ additional implementation guidelines. These guidelines are not part
+ of the protocol, but they may help implementors create simple,
+ secure, and interoperable implementations.
+
+ Where a TLS-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 allow for the keys
+ to be entered as human-readable strings in hex format.
+
+
+
+
+
+
+
+DeKok Experimental [Page 16]
+
+RFC 7360 DTLS as a Transport Layer for RADIUS September 2014
+
+
+ When creating keys for use with PSK ciphersuites, it is RECOMMENDED
+ that keys be derived from a Cryptographically Secure Pseudorandom
+ Number Generator (CSPRNG) instead of administrators inventing keys on
+ their own. If managing keys is too complicated, a certificate-based
+ TLS method SHOULD be used instead.
+
+6.1. Client Implementations
+
+ RADIUS/DTLS clients should use connected sockets where possible. Use
+ of connected sockets means that the underlying kernel tracks the
+ sessions, so that the client subsystem does not need to manage
+ multiple sessions on one socket.
+
+ RADIUS/DTLS clients should use a single source (IP + port) when
+ sending packets to a particular RADIUS/DTLS server. Doing so
+ minimizes the number of DTLS session setups. It also ensures that
+ information about the home server state is discovered only once.
+
+ In practice, this means that RADIUS/DTLS clients with multiple
+ internal RADIUS sources should use a local proxy that arbitrates all
+ RADIUS traffic between the client and all servers. The proxy should
+ accept traffic only from the authorized subsystems on the client
+ machine and should proxy that traffic to known servers. Each
+ authorized subsystem should include an attribute that uniquely
+ identifies that subsystem to the proxy, so that the proxy can apply
+ origin-specific proxy rules and security policies. We suggest using
+ NAS-Identifier for this purpose.
+
+ The local proxy should be able to interact with multiple servers at
+ the same time. There is no requirement that each server have its own
+ unique proxy on the client, as that would be inefficient.
+
+ The suggestion to use a local proxy means that there is only one
+ process that discovers network and/or connectivity issues with a
+ server. If each client subsystem communicated directly with a
+ server, issues with that server would have to be discovered
+ independently by each subsystem. The side effect would be increased
+ delays in re-routing traffic, error reporting, and network
+ instabilities.
+
+ Each client subsystem can include a subsystem-specific NAS-Identifier
+ in each request. The format of this attribute is implementation-
+ specific. The proxy should verify that the request originated from
+ the local system, ideally via a loopback address. The proxy MUST
+ then rewrite any subsystem-specific NAS-Identifier to a NAS-
+ Identifier that identifies the client as a whole, or, remove the NAS-
+ Identifier entirely and replace it with NAS-IP-Address or NAS-
+ IPv6-Address.
+
+
+
+DeKok Experimental [Page 17]
+
+RFC 7360 DTLS as a Transport Layer for RADIUS September 2014
+
+
+ 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 then 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, 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 exists 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. 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.
+
+8. IANA Considerations
+
+ No new RADIUS attributes or packet codes are defined. IANA has
+ updated the "Service Name and Transport Protocol Port Number
+ Registry". The entries corresponding to port service name "radsec",
+ port number "2083", and transport protocol "UDP" have been updated as
+ follows:
+
+ o Assignee: IESG
+
+ o Contact: IETF Chair
+
+ o Reference: This document
+
+ o Assignment Notes: 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 writing, and is based on a proposal
+ described in [RFC6982].
+
+
+
+
+DeKok Experimental [Page 18]
+
+RFC 7360 DTLS as a Transport Layer for RADIUS September 2014
+
+
+ The description of implementations in this section is intended to
+ assist the IETF in its decision processes in progressing Internet-
+ Drafts to RFCs.
+
+9.1. Radsecproxy
+
+ Organization: Radsecproxy
+
+ URL: https://software.uninett.no/radsecproxy/
+
+ Maturity: Widely used software based on early versions 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 that
+ were implemented are unknown.
+
+ Licensing: Freely distributable with acknowledgment.
+
+ Implementation experience: No comments from implementors.
+
+9.2. jradius
+
+ Organization: Coova
+
+ URL: http://www.coova.org/JRadius/RadSec
+
+ Maturity: Production software based on early versions 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 that
+ 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.
+
+
+
+
+
+DeKok Experimental [Page 19]
+
+RFC 7360 DTLS as a Transport Layer for RADIUS September 2014
+
+
+ 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. Most 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.
+
+ This specification also suggests that implementations use a session
+ 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 that result from tracking additional information.
+
+ The fixed shared secret given above in Section 2.2.1 is acceptable
+ only when DTLS is used with a 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. Therefore, implementations MUST NOT use null encryption
+ methods for RADIUS/DTLS.
+
+ For systems that perform protocol-based firewalling and/or filtering,
+ it is RECOMMENDED that they be configured to permit only DTLS over
+ the RADIUS/DTLS port.
+
+10.1. Crypto-Agility
+
+ Section 4.2 of [RFC6421] makes a number of recommendations about
+ security properties of new RADIUS proposals. All of those
+ recommendations are satisfied by using DTLS as the transport layer.
+
+ Section 4.3 of [RFC6421] makes a number of recommendations about
+ backwards compatibility with RADIUS. Section 3, above, addresses
+ these concerns in detail.
+
+ Section 4.4 of [RFC6421] recommends that change control be ceded to
+ the IETF, and that interoperability is possible. Both requirements
+ are satisfied.
+
+
+
+
+
+
+DeKok Experimental [Page 20]
+
+RFC 7360 DTLS as a Transport Layer for RADIUS September 2014
+
+
+ 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 that 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-PSK method and to leave the user interface
+ otherwise unchanged. This practice MUST NOT be used. The
+ administrator MUST be given the option to use DTLS. Any shared
+ secret used for RADIUS/UDP MUST NOT be used for DTLS. Reusing a
+ shared secret between RADIUS/UDP and RADIUS/DTLS would negate all of
+ the benefits found by using DTLS.
+
+ RADIUS/DTLS client implementors MUST expose a configuration that
+ allows the administrator to choose the ciphersuite. Where
+ certificates are used, RADIUS/DTLS client implementors MUST expose a
+ configuration that 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 Cryptographically
+ Secure Pseudorandom 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 that seem to
+ be attempting brute-force searches of the keyspace.
+
+
+
+
+
+DeKok Experimental [Page 21]
+
+RFC 7360 DTLS as a Transport Layer for RADIUS September 2014
+
+
+ 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.3. Resource Exhaustion
+
+ The use of DTLS allows DoS attacks and resource-exhaustion attacks
+ that were not possible in RADIUS/UDP. These attacks are similar to
+ those described in [RFC6614], Section 6, for TCP.
+
+ Session tracking, as described in Section 5.1, can result in resource
+ exhaustion. Therefore, servers MUST 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 that has been idle for the longest
+ time. Doing so may free up idle resources that 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.4. Client-Server Authentication with DTLS
+
+ We expect that the initial deployment of DTLS will 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.
+
+ Instead of a shared secret, TLS credentials MUST be used by each
+ party to authenticate the other. The issue of identity is more
+ problematic. As with RADIUS/UDP, IP addresses may be used as a key
+ to determine the authentication credentials that a client will
+ present to a server or which credentials a server will accept from a
+ client. This is the fixed IP address model of RADIUS/UDP, with the
+ shared secret replaced by TLS credentials.
+
+
+
+
+
+
+
+
+DeKok Experimental [Page 22]
+
+RFC 7360 DTLS as a Transport Layer for RADIUS September 2014
+
+
+ There are, however, additional considerations with RADIUS/DTLS. When
+ a client is configured with a hostname for a server, the server may
+ present to the client a certificate containing a hostname. The
+ client MUST then verify that the hostnames match. Any mismatch is a
+ security violation, and the connection MUST be closed.
+
+ A RADIUS/DTLS server MAY be configured with a "wildcard" IP address
+ match for clients, instead of a unique fixed IP address for each
+ client. In that case, clients MUST be individually configured with a
+ unique certificate. When the server receives a connection from a
+ client, it MUST determine client identity from the client
+ certificate, and MUST authenticate (or not) the client based on that
+ certificate. 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 limited 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 must also be statically configured.
+ That is, a client connecting to a DTLS server SHOULD be pre-
+ configured with the server's credentials (e.g., PSK or certificate).
+ If the server fails to present the correct credentials, the DTLS
+ session MUST be closed. Each server SHOULD be pre-configured with
+ sufficient information to authenticate connecting clients.
+
+ The requirement for clients to be individually configured with a
+ unique certificate can be met by using a private 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 that has a
+ certificate signed by that CA. While the traffic would be secure
+ from third-party observers, the server would, however, have
+ unrestricted access to all of the RADIUS traffic, including all user
+ credentials and passwords.
+
+ Therefore, clients SHOULD NOT be pre-configured with a list of known
+ public CAs by the vendor or manufacturer. Instead, the clients
+ SHOULD start off with an empty CA list. The addition of a CA SHOULD
+ be done only when manually configured by an administrator.
+
+
+
+
+
+
+
+
+
+
+DeKok Experimental [Page 23]
+
+RFC 7360 DTLS as a Transport Layer for RADIUS September 2014
+
+
+ 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 that 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 pre-
+ configured on the client, and associated with that hostname. This
+ requirement does suggest that in the absence of a specification for
+ dynamic discovery, clients SHOULD use only those servers that have
+ been manually configured by an administrator.
+
+10.5. Network Address Translation
+
+ Network Address Translation (NAT) is fundamentally incompatible with
+ RADIUS/UDP. RADIUS/UDP uses the source IP address to determine the
+ shared secret for the client, and NAT hides many clients behind one
+ source IP address. As a result, RADIUS/UDP clients cannot be located
+ behind a NAT gateway.
+
+ In addition, port reuse 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
+ one source IP/port combination, followed by the reception of a
+ RADIUS/UDP packet from that same source IP/port combination. If this
+ behavior is allowed, then the server would have an inconsistent view
+ of the client's security profile, allowing an attacker to choose the
+ most insecure method.
+
+ If more than one client is located behind a NAT gateway, then every
+ client behind the NAT MUST use a secure transport such as TLS or
+ DTLS. As discussed below, a method for uniquely identifying each
+ client MUST be used.
+
+10.6. Wildcard Clients
+
+ Some RADIUS server implementations allow for "wildcard" clients --
+ that is, clients with an IPv4 netmask of other than 32 or an IPv6
+ netmask of other than 128. That practice is not recommended for
+ RADIUS/UDP, as it means multiple clients will use the same shared
+ secret.
+
+
+
+
+
+
+DeKok Experimental [Page 24]
+
+RFC 7360 DTLS as a Transport Layer for RADIUS September 2014
+
+
+ The use of RADIUS/DTLS can allow for the safe usage of wildcards.
+ When RADIUS/DTLS is used with wildcards, clients MUST be uniquely
+ identified using TLS parameters, and any certificate or PSK used MUST
+ be unique to each client.
+
+10.7. Session Closing
+
+ Section 5.1.1, above, requires that DTLS sessions be closed when the
+ transported RADIUS packets are malformed or fail the authenticator
+ 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 that cause a DTLS session to close. Therefore,
+ in other situations, the session SHOULD remain open in the face of
+ non-conformant packets.
+
+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 that
+ arbitrates all RADIUS traffic between the client and all servers.
+ This proxy will encapsulate all knowledge about servers, including
+ security policies, fail-over, and load-balancing. All client
+ subsystems SHOULD communicate with this local proxy, ideally over a
+ loopback address. The requirements on using strong shared secrets
+ still apply.
+
+ The benefit of this configuration is that there is one place in the
+ client that arbitrates all RADIUS traffic. Subsystems that do not
+ implement DTLS can remain unaware of DTLS. DTLS sessions opened by
+ the proxy can remain open for long periods of time, even when client
+ subsystems are restarted. The proxy can do RADIUS/UDP to some
+ servers and RADIUS/DTLS to others.
+
+
+
+
+
+DeKok Experimental [Page 25]
+
+RFC 7360 DTLS as a Transport Layer for RADIUS September 2014
+
+
+ Delegation of responsibilities and separation of tasks are important
+ security principles. By moving all RADIUS/DTLS knowledge to a DTLS-
+ aware proxy, security analysis becomes simpler, and enforcement of
+ correct security becomes easier.
+
+11. References
+
+11.1. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
+ "Remote Authentication Dial In User Service (RADIUS)",
+ RFC 2865, June 2000.
+
+ [RFC3539] Aboba, B. and J. Wood, "Authentication, Authorization and
+ Accounting (AAA) Transport Profile", RFC 3539, June 2003.
+
+ [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig,
+ "Transport Layer Security (TLS) Session Resumption
+ without Server-Side State", RFC 5077, January 2008.
+
+ [RFC5080] Nelson, D. and A. DeKok, "Common Remote Authentication
+ Dial In User Service (RADIUS) Implementation Issues and
+ Suggested Fixes", RFC 5080, December 2007.
+
+ [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
+ (TLS) Protocol Version 1.2", RFC 5246, August 2008.
+
+ [RFC5997] DeKok, A., "Use of Status-Server Packets in the Remote
+ Authentication Dial In User Service (RADIUS) Protocol",
+ RFC 5997, August 2010.
+
+ [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
+ Security Version 1.2", RFC 6347, January 2012.
+
+ [RFC6520] Seggelmann, R., Tuexen, M., and M. Williams, "Transport
+ Layer Security (TLS) and Datagram Transport Layer
+ Security (DTLS) Heartbeat Extension", RFC 6520, February
+ 2012.
+
+ [RFC6613] DeKok, A., "RADIUS over TCP", RFC 6613, May 2012.
+
+ [RFC6614] Winter, S., McCauley, M., Venaas, S., and K. Wierenga,
+ "Transport Layer Security (TLS) Encryption for RADIUS",
+ RFC 6614, May 2012.
+
+
+
+
+DeKok Experimental [Page 26]
+
+RFC 7360 DTLS as a Transport Layer for RADIUS September 2014
+
+
+11.2. Informative References
+
+ [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
+ April 1992.
+
+ [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., Dommety, G., Eklund, M., Mitton, D., and B.
+ Aboba, "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, X. and H. Yu, "How to Break MD5 and Other Hash
+ Functions", EUROCRYPT '05 Proceedings of the 24th annual
+ international conference on Theory and Applications of
+ Cryptographic Techniques, pp. 19-35, ISBN 3-540-25910-4,
+ 2005.
+
+Acknowledgments
+
+ Parts of the text in Section 3 defining the Request and Response
+ Authenticators were taken with minor edits from [RFC2865], Section 3.
+
+Author's Address
+
+ Alan DeKok
+ The FreeRADIUS Server Project
+ URI: http://freeradius.org
+ EMail: aland@freeradius.org
+
+
+
+
+
+
+
+DeKok Experimental [Page 27]
+