draft-ietf-radext-dtls-13.txt   rfc7360.txt 
Network Working Group Alan DeKok Internet Engineering Task Force (IETF) A. DeKok
INTERNET-DRAFT FreeRADIUS Request for Comments: 7360 FreeRADIUS
Category: Experimental Category: Experimental September 2014
<draft-ietf-radext-dtls-13.txt> ISSN: 2070-1721
Expires: January 4, 2015
3 July 2014
DTLS as a Transport Layer for RADIUS Datagram Transport Layer Security (DTLS)
draft-ietf-radext-dtls-13 as a Transport Layer for RADIUS
Abstract Abstract
The RADIUS protocol defined in RFC 2865 has limited support for The RADIUS protocol defined in RFC 2865 has limited support for
authentication and encryption of RADIUS packets. The protocol authentication and encryption of RADIUS packets. The protocol
transports data in the clear, although some parts of the packets can transports data in the clear, although some parts of the packets can
have obfuscated content. Packets may be replayed verbatim by an have obfuscated content. Packets may be replayed verbatim by an
attacker, and client-server authentication is based on fixed shared attacker, and client-server authentication is based on fixed shared
secrets. This document specifies how the Datagram Transport Layer secrets. This document specifies how the Datagram Transport Layer
Security (DTLS) protocol may be used as a fix for these problems. It Security (DTLS) protocol may be used as a fix for these problems. It
also describes how implementations of this proposal can co-exist with also describes how implementations of this proposal can coexist with
current RADIUS systems. current RADIUS systems.
Status of this Memo Status of This Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
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 This document is not an Internet Standards Track specification; it is
http://www.ietf.org/ietf/1id-abstracts.txt. published for examination, experimental implementation, and
evaluation.
The list of Internet-Draft Shadow Directories can be accessed at This document defines an Experimental Protocol for the Internet
http://www.ietf.org/shadow.html. 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.
This Internet-Draft will expire on November 8, 2014 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.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info/) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction ............................................. 4 1. Introduction ....................................................4
1.1. Terminology ......................................... 4 1.1. Terminology ................................................5
1.2. Requirements Language ............................... 5 1.2. Requirements Language ......................................5
1.3. Document Status ..................................... 5 1.3. Document Status ............................................5
2. Building on Existing Foundations ......................... 7 2. Building on Existing Foundations ................................6
2.1. Changes to RADIUS ................................... 7 2.1. Changes to RADIUS ..........................................7
2.2. Similarities with RADIUS/TLS ........................ 8 2.2. Similarities with RADIUS/TLS ...............................8
2.2.1. Changes from RADIUS/TLS to RADIUS/DTLS ......... 8 2.2.1. Changes from RADIUS/TLS to RADIUS/DTLS ..............8
3. Interaction with RADIUS/UDP .............................. 9 3. Interaction with RADIUS/UDP .....................................9
3.1. DTLS Port and Packet Types .......................... 10 3.1. DTLS Port and Packet Types ................................10
3.2. Server Behavior ..................................... 10 3.2. Server Behavior ...........................................10
4. Client Behavior .......................................... 11 4. Client Behavior ................................................11
5. Session Management ....................................... 12 5. Session Management .............................................12
5.1. Server Session Management ........................... 12 5.1. Server Session Management .................................12
5.1.1. Session Opening and Closing .................... 13 5.1.1. Session Opening and Closing ........................13
5.2. Client Session Management ........................... 15 5.2. Client Session Management .................................15
6. Implementation Guidelines ................................ 16 6. Implementation Guidelines ......................................16
6.1. Client Implementations .............................. 16 6.1. Client Implementations ....................................17
6.2. Server Implementations .............................. 17 6.2. Server Implementations ....................................18
7. Diameter Considerations .................................. 18 7. Diameter Considerations ........................................18
8. IANA Considerations ...................................... 18 8. IANA Considerations ............................................18
9. Implementation Status .................................... 18 9. Implementation Status ..........................................18
9.1. Radsecproxy ......................................... 18 9.1. Radsecproxy ...............................................19
9.2. jradius ............................................. 19 9.2. jradius ...................................................19
10. Security Considerations ................................. 19 10. Security Considerations .......................................19
10.1. Crypto-Agility ..................................... 20 10.1. Crypto-Agility ...........................................20
10.2. Legacy RADIUS Security ............................. 20 10.2. Legacy RADIUS Security ...................................21
10.3. Resource Exhaustion ................................ 21 10.3. Resource Exhaustion ......................................22
10.4. Client-Server Authentication with DTLS ............. 22 10.4. Client-Server Authentication with DTLS ...................22
10.5. Network Address Translation ........................ 23 10.5. Network Address Translation ..............................24
10.6. Wildcard Clients ................................... 24 10.6. Wildcard Clients .........................................24
10.7. Session Closing .................................... 24 10.7. Session Closing ..........................................25
10.8. Client Subsystems .................................. 24 10.8. Client Subsystems ........................................25
11. References .............................................. 25 11. References ....................................................26
11.1. Normative references ............................... 25 11.1. Normative References .....................................26
11.2. Informative references ............................. 26 11.2. Informative References ...................................27
Acknowledgments ...................................................27
1. Introduction 1. Introduction
The RADIUS protocol as described in [RFC2865], [RFC2866], [RFC5176], The RADIUS protocol as described in [RFC2865], [RFC2866], [RFC5176],
and others has traditionally used methods based on MD5 [RFC1321] for and others has traditionally used methods based on MD5 [RFC1321] for
per-packet authentication and integrity checks. However, the MD5 per-packet authentication and integrity checks. However, the MD5
algorithm has known weaknesses such as [MD5Attack] and [MD5Break]. algorithm has known weaknesses such as [MD5Attack] and [MD5Break].
As a result, some specifications such as [RFC5176] have recommended As a result, some specifications, such as [RFC5176], have recommended
using IPSec to secure RADIUS traffic. using IPsec to secure RADIUS traffic.
While RADIUS over IPSec has been widely deployed, there are While RADIUS over IPsec has been widely deployed, there are
difficulties with this approach. The simplest point against IPSec is difficulties with this approach. The simplest point against IPsec is
that there is no straightforward way for an application to control or that there is no straightforward way for an application to control or
monitor the network security policies. That is, the requirement that monitor the network security policies. That is, the requirement that
the RADIUS traffic be encrypted and/or authenticated is implicit in the RADIUS traffic be encrypted and/or authenticated is implicit in
the network configuration, and cannot be enforced by the RADIUS the network configuration, and it cannot be enforced by the RADIUS
application. application.
This specification takes a different approach. We define a method This specification takes a different approach. We define a method
for using DTLS [RFC6347] as a RADIUS transport protocol. This for using DTLS [RFC6347] as a RADIUS transport protocol. This
approach has the benefit that the RADIUS application can directly approach has the benefit that the RADIUS application can directly
monitor and control the security policies associated with the traffic monitor and control the security policies associated with the traffic
that it processes. that it processes.
Another benefit is that RADIUS over DTLS continues to be a User Another benefit is that RADIUS over DTLS continues to be a UDP-based
Datagram Protocol (UDP) based protocol. The change from RADIUS/UDP protocol. The change from RADIUS/UDP is largely to add DTLS support,
is largely to add DTLS support, and make any necessary related and make any necessary related changes to RADIUS. This allows
changes to RADIUS. This allows implementations to remain UDP based, implementations to remain UDP based, without changing to a TCP
without changing to a TCP architecture. architecture.
This specification does not, however, solve all of the problems This specification does not, however, solve all of the problems
associated with RADIUS/UDP. The DTLS protocol does not add reliable associated with RADIUS/UDP. The DTLS protocol does not add reliable
or in-order transport to RADIUS. DTLS also does not support or in-order transport to RADIUS. DTLS also does not support
fragmentation of application-layer messages, or of the DTLS messages fragmentation of application-layer messages, or of the DTLS messages
themselves. This specification therefore shares with traditional themselves. This specification therefore shares with traditional
RADIUS the issues of order, reliability, and fragmentation. These RADIUS the issues of order, reliability, and fragmentation. These
issues are dealt with in RADIUS/TCP [RFC6613] and RADIUS/TLS issues are dealt with in RADIUS/TCP [RFC6613] and RADIUS/TLS
[RFC6614]. [RFC6614].
1.1. Terminology 1.1. Terminology
This document uses the following terms: This document uses the following terms:
RADIUS/DTLS RADIUS/DTLS
This term is a short-hand for "RADIUS over DTLS". This term is a shorthand for "RADIUS over DTLS".
RADIUS/DTLS client RADIUS/DTLS client
This term refers both to RADIUS clients as defined in [RFC2865], This term refers both to RADIUS clients as defined in [RFC2865]
and to Dynamic Authorization clients as defined in [RFC5176], that and to Dynamic Authorization clients as defined in [RFC5176] that
implement RADIUS/DTLS. implement RADIUS/DTLS.
RADIUS/DTLS server RADIUS/DTLS server
This term refers both to RADIUS servers as defined in [RFC2865], This term refers both to RADIUS servers as defined in [RFC2865]
and to Dynamic Authorization servers as defined in [RFC5176], that and to Dynamic Authorization servers as defined in [RFC5176] that
implement RADIUS/DTLS. implement RADIUS/DTLS.
RADIUS/UDP RADIUS/UDP
RADIUS over UDP, as defined in [RFC2865]. RADIUS over UDP, as defined in [RFC2865].
RADIUS/TLS RADIUS/TLS
RADIUS over TLS, as defined in [RFC6614]. RADIUS over TLS, as defined in [RFC6614].
silently discard silently discard
This means that the implementation discards the packet without This means that the implementation discards the packet without
further processing. further processing.
1.2. Requirements Language 1.2. Requirements Language
In this document, several words are used to signify the requirements In this document, several words are used to signify the requirements
of the specification. The key words "MUST", "MUST NOT", "REQUIRED", of the specification. The key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT
RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be
interpreted as described in [RFC2119]. interpreted as described in [RFC2119].
1.3. Document Status 1.3. Document Status
This document is an Experimental RFC. This document is an Experimental RFC.
It is one out of several approaches to address known cryptographic It contains one of several approaches to address known cryptographic
weaknesses of the RADIUS protocol, such as [RFC6614]. This weaknesses of the RADIUS protocol, such as described in [RFC6614].
specification does not fulfill all recommendations on a AAA transport This specification does not fulfill all recommendations for an
profile as per [RFC3539]; however unlike [RFC6614], it is based on Authentication, Authorization, and Accounting (AAA) transport profile
UDP, does not have head-of-line blocking issues. as per [RFC3539]; however, unlike [RFC6614], it is based on UDP and
therefore does not have head-of-line blocking issues.
If this specification is indeed selected for advancement to Standards If this specification is indeed selected for advancement to Standards
Track, certificate verification options ([RFC6614] Section 2.3, point Track, certificate verification options ([RFC6614], Section 2.3,
2) needs to be refined. point 2) will need to be refined.
Another experimental characteristic of this specification is the Another experimental characteristic of this specification is the
question of key management between RADIUS/DTLS peers. RADIUS/UDP question of key management between RADIUS/DTLS peers. RADIUS/UDP
only allowed for manual key management, i.e., distribution of a only allowed for manual key management, i.e., distribution of a
shared secret between a client and a server. RADIUS/DTLS allows shared secret between a client and a server. RADIUS/DTLS allows
manual distribution of long-term proofs of peer identity, by using manual distribution of long-term proofs of peer identity, by using
TLS-PSK ciphersuites. RADIUS/DTLS also allows the use of X.509 TLS-PSK ciphersuites. RADIUS/DTLS also allows the use of X.509
certificates in a PKIX infrastructure. It remains to be seen if one 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 of these methods will prevail or if both will find their place in
real-life deployments. The authors can imagine pre-shared keys (PSK) real-life deployments. The authors can imagine pre-shared keys
to be popular in small-scale deployments (Small Office, Home Office (PSKs) to be popular in small-scale deployments (Small Office, Home
(SOHO) or isolated enterprise deployments) where scalability is not Office (SOHO) or isolated enterprise deployments) where scalability
an issue and the deployment of a Certification Authority (CA) is is not an issue and the deployment of a Certification Authority (CA)
considered too much of a hassle; however, the authors can also is considered too much of a hassle; however, the authors can also
imagine large roaming consortia to make use of PKIX. Readers of this imagine large roaming consortia to make use of PKIX. Readers of this
specification are encouraged to read the discussion of key management specification are encouraged to read the discussion of key management
issues within [RFC6421] as well as [RFC4107]. issues within [RFC6421] as well as [RFC4107].
It has yet to be decided whether this approach is to be chosen for 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 Standards Track. One key aspect to judge whether the approach is
usable on a large scale is by observing the uptake, usability, and usable on a large scale is by observing the uptake, usability, and
operational behavior of the protocol in large-scale, real-life operational behavior of the protocol in large-scale, real-life
deployments. deployments.
2. Building on Existing Foundations 2. Building on Existing Foundations
Adding DTLS as a RADIUS transport protocol requires a number of Adding DTLS as a RADIUS transport protocol requires a number of
changes to systems implementing standard RADIUS. This section changes to systems implementing standard RADIUS. This section
outlines those changes, and defines new behaviors necessary to outlines those changes, and defines new behaviors necessary to
implement DTLS. implement DTLS.
2.1. Changes to RADIUS 2.1. Changes to RADIUS
The RADIUS packet format is unchanged from [RFC2865], [RFC2866], and The RADIUS packet format is unchanged from [RFC2865], [RFC2866], and
[RFC5176]. Specifically, all of the following portions of RADIUS [RFC5176]. Specifically, all of the following portions of RADIUS
MUST be unchanged when using RADIUS/DTLS: MUST be unchanged when using RADIUS/DTLS:
* Packet format * Packet format
* Permitted codes * Permitted codes
* Request Authenticator calculation * Request Authenticator calculation
* Response Authenticator calculation * Response Authenticator calculation
* Minimum packet length * Minimum packet length
* Maximum packet length * Maximum packet length
* Attribute format * Attribute format
* Vendor-Specific Attribute (VSA) format * Vendor-Specific Attribute (VSA) format
* Permitted data types * Permitted data types
* Calculations of dynamic attributes such as CHAP-Challenge, * Calculations of dynamic attributes such as CHAP-Challenge, or
or Message-Authenticator. Message-Authenticator.
* Calculation of "obfuscated" attributes such as User-Password * Calculation of "obfuscated" attributes such as User-Password and
and Tunnel-Password. Tunnel-Password.
In short, the application creates a RADIUS packet via the usual In short, the application creates a RADIUS packet via the usual
methods, and then instead of sending it over a UDP socket, sends the 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 packet to a DTLS layer for encapsulation. DTLS then acts as a
transport layer for RADIUS, hence the names "RADIUS/UDP" and transport layer for RADIUS: hence, the names "RADIUS/UDP" and
"RADIUS/DTLS". "RADIUS/DTLS".
The requirement that RADIUS remain largely unchanged ensures the The requirement that RADIUS remain largely unchanged ensures the
simplest possible implementation and widest interoperability of this simplest possible implementation and widest interoperability of this
specification. specification.
We note that the DTLS encapsulation of RADIUS means that RADIUS We note that the DTLS encapsulation of RADIUS means that RADIUS
packets have an additional overhead due to DTLS. Implementations packets have an additional overhead due to DTLS. Implementations
MUST support sending and receiving encapsulated RADIUS packets of MUST support sending and receiving encapsulated RADIUS packets of
4096 octets in length, with a corresponding increase in the maximum 4096 octets in length, with a corresponding increase in the maximum
size of the encapsulated DTLS packets. This larger packet size may size of the encapsulated DTLS packets. This larger packet size may
cause the packet to be larger than the Path MTU (PMTU), where a 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 RADIUS/UDP packet may be smaller. See Section 5.2, below, for more
discussion. discussion.
The only changes made from RADIUS/UDP to RADIUS/DTLS are the The only changes made from RADIUS/UDP to RADIUS/DTLS are the
following two items: following two items:
(1) The Length checks defined in [RFC2865] Section 3 MUST use the (1) The Length checks defined in [RFC2865], Section 3, MUST use the
length of the decrypted DTLS data instead of the UDP packet length of the decrypted DTLS data instead of the UDP packet
length. They MUST treat any decrypted DTLS data octets outside length. They MUST treat any decrypted DTLS data octets outside
the range of the Length field as padding, and ignore it on the range of the Length field as padding and ignore it on
reception. reception.
(2) The shared secret secret used to compute the MD5 integrity (2) The shared secret used to compute the MD5 integrity checks and
checks and the attribute encryption MUST be "radius/dtls". the attribute encryption MUST be "radius/dtls".
All other aspects of RADIUS are unchanged. All other aspects of RADIUS are unchanged.
2.2. Similarities with RADIUS/TLS 2.2. Similarities with RADIUS/TLS
While this specification can be thought of as RADIUS/TLS over UDP While this specification can be thought of as RADIUS/TLS over UDP
instead of the Transmission Control Protocol (TCP), there are some instead of the Transmission Control Protocol (TCP), there are some
differences between the two methods. The bulk of [RFC6614] applies differences between the two methods. The bulk of [RFC6614] applies
to this specification, so we do not repeat it here. to this specification, so we do not repeat it here.
skipping to change at page 8, line 40 skipping to change at page 8, line 43
* We replace references to "TLS" with "DTLS" * We replace references to "TLS" with "DTLS"
Those changes are sufficient to cover the majority of the differences Those changes are sufficient to cover the majority of the differences
between the two specifications. The next section reviews some more between the two specifications. The next section reviews some more
detailed changes from [RFC6614], giving additional commentary only detailed changes from [RFC6614], giving additional commentary only
where necessary. where necessary.
2.2.1. Changes from RADIUS/TLS to RADIUS/DTLS 2.2.1. Changes from RADIUS/TLS to RADIUS/DTLS
This section describes where this specification is similar to This section describes how particular sections of [RFC6614] apply to
[RFC6614], and where it differs. RADIUS/DTLS.
Section 2.1 applies to RADIUS/DTLS, with the exception that the Section 2.1 applies to RADIUS/DTLS, with the exception that the
RADIUS/DTLS port is UDP/2083. RADIUS/DTLS port is UDP/2083.
Section 2.2 applies to RADIUS/DTLS. Servers and clients need to be Section 2.2 applies to RADIUS/DTLS. Servers and clients need to be
preconfigured to use RADIUS/DTLS for a given endpoint. pre-configured to use RADIUS/DTLS for a given endpoint.
Most of Section 2.3 applies also to RADIUS/DTLS. Item (1) should be Most of Section 2.3 applies also to RADIUS/DTLS. Item (1) should be
interpreted as applying to DTLS session initiation, instead of TCP interpreted as applying to DTLS session initiation, instead of TCP
connection establishment. Item (2) applies, except for the connection establishment. Item (2) applies, except for the
recommendation that implementations "SHOULD" support recommendation that implementations "SHOULD" support
TLS_RSA_WITH_RC4_128_SHA. This recommendation is a historical TLS_RSA_WITH_RC4_128_SHA. This recommendation is a historical
artifact of RADIUS/TLS, and does not apply to RADIUS/DTLS. Item (3) artifact of RADIUS/TLS, and it does not apply to RADIUS/DTLS. Item
applies to RADIUS/DTLS. Item (4) applies, except that the fixed (3) applies to RADIUS/DTLS. Item (4) applies, except that the fixed
shared secret is "radius/dtls", as described above. shared secret is "radius/dtls", as described above.
Section 2.4 applies to RADIUS/DTLS. Client identities SHOULD be Section 2.4 applies to RADIUS/DTLS. Client identities SHOULD be
determined from DTLS parameters, instead of relying solely on the determined from DTLS parameters, instead of relying solely on the
source IP address of the packet. source IP address of the packet.
Section 2.5 does not apply to RADIUS/DTLS. The relationship between 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 packet codes and UDP ports in RADIUS/DTLS is unchanged from
RADIUS/UDP. RADIUS/UDP.
Sections 3.1, 3.2, and 3.3 apply to RADIUS/DTLS. 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 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" packet is encapsulated in one DTLS packet, and there is no "stream"
of RADIUS packets inside of a TLS session. Implementors MUST enforce of RADIUS packets inside of a TLS session. Implementors MUST enforce
the requirements of [RFC2865] Section 3 for the RADIUS Length field, the requirements of [RFC2865], Section 3, for the RADIUS Length
using the length of the decrypted DTLS data for the checks. This field, using the length of the decrypted DTLS data for the checks.
check replaces the RADIUS method of using the length field from the This check replaces the RADIUS method of using the Length field from
UDP packet. the UDP packet.
Section 3.4 items (2), (3), (4), and (5) apply to RADIUS/DTLS. Section 3.4 items (2), (3), (4), and (5) apply to RADIUS/DTLS.
Section 4 does not apply to RADIUS/DTLS. Protocol compatibility Section 4 does not apply to RADIUS/DTLS. Protocol compatibility
considerations are defined in this document. considerations are defined in this document.
Section 6 applies to RADIUS/DTLS. Section 6 applies to RADIUS/DTLS.
3. Interaction with RADIUS/UDP 3. Interaction with RADIUS/UDP
Transitioning to DTLS is a process which needs to be done carefully. Transitioning to DTLS is a process that needs to be done carefully.
A poorly handled transition is complex for administrators, and A poorly handled transition is complex for administrators and
potentially subject to security downgrade attacks. It is not potentially subject to security downgrade attacks. It is not
sufficient to just disable RADIUS/UDP and enable RADIUS/DTLS. RADIUS sufficient to just disable RADIUS/UDP and enable RADIUS/DTLS. RADIUS
has no provisions for protocol negotiation, so simply disabling has no provisions for protocol negotiation, so simply disabling
RADIUS/UDP would result in timeouts, lost traffic, and network RADIUS/UDP would result in timeouts, lost traffic, and network
instabilities. instabilities.
The end result of this specification is that nearly all RADIUS/UDP The end result of this specification is that nearly all RADIUS/UDP
implementations should transition to using a secure alternative. In implementations should transition to using a secure alternative. In
some cases, RADIUS/UDP may remain where IPSec is used as a transport, some cases, RADIUS/UDP may remain where IPsec is used as a transport,
or where implementation and/or business reasons preclude a change. or where implementation and/or business reasons preclude a change.
However, we do not recommend long-term use of RADIUS/UDP outside of However, we do not recommend long-term use of RADIUS/UDP outside of
isolated and secure networks. isolated and secure networks.
This section describes how clients and servers should use This section describes how clients and servers should use
RADIUS/DTLS, and how it interacts with RADIUS/UDP. RADIUS/DTLS, and how it interacts with RADIUS/UDP.
3.1. DTLS Port and Packet Types 3.1. DTLS Port and Packet Types
The default destination port number for RADIUS/DTLS is UDP/2083. The default destination port number for RADIUS/DTLS is UDP/2083.
There are no separate ports for authentication, accounting, and There are no separate ports for authentication, accounting, and
skipping to change at page 10, line 11 skipping to change at page 10, line 16
isolated and secure networks. isolated and secure networks.
This section describes how clients and servers should use This section describes how clients and servers should use
RADIUS/DTLS, and how it interacts with RADIUS/UDP. RADIUS/DTLS, and how it interacts with RADIUS/UDP.
3.1. DTLS Port and Packet Types 3.1. DTLS Port and Packet Types
The default destination port number for RADIUS/DTLS is UDP/2083. The default destination port number for RADIUS/DTLS is UDP/2083.
There are no separate ports for authentication, accounting, and There are no separate ports for authentication, accounting, and
dynamic authorization changes. The source port is arbitrary. The dynamic authorization changes. The source port is arbitrary. The
text above in [RFC6614] Section 3.4 describes issues surrounding the text in [RFC6614], Section 3.4, describes issues surrounding the use
use of one port for multiple packet types. We recognize that of one port for multiple packet types. We recognize that
implementations may allow the use of RADIUS/DTLS over non-standard implementations may allow the use of RADIUS/DTLS over non-standard
ports. In that case, the references to UDP/2083 in this document ports. In that case, the references to UDP/2083 in this document
should be read as applying to any port used for transport of should be read as applying to any port used for transport of
RADIUS/DTLS traffic. RADIUS/DTLS traffic.
3.2. Server Behavior 3.2. Server Behavior
When a server receives packets on UDP/2083, all packets MUST be When a server receives packets on UDP/2083, all packets MUST be
treated as being DTLS. RADIUS/UDP packets MUST NOT be accepted on treated as being DTLS. RADIUS/UDP packets MUST NOT be accepted on
this port. this port.
Servers MUST NOT accept DTLS packets on the old RADIUS/UDP ports. Servers MUST NOT accept DTLS packets on the old RADIUS/UDP ports.
Early drafts of this specification permitted this behavior. It is Early versions of this specification permitted this behavior. It is
forbidden here, as it depended on behavior in DTLS which may change forbidden here, as it depended on behavior in DTLS that may change
without notice. without notice.
Servers MUST authenticate clients. RADIUS is designed to be used by Servers MUST authenticate clients. RADIUS is designed to be used by
mutually trusted systems. Allowing anonymous clients would ensure mutually trusted systems. Allowing anonymous clients would ensure
privacy for RADIUS/DTLS traffic, but would negate all other security privacy for RADIUS/DTLS traffic, but would negate all other security
aspects of the protocol. aspects of the protocol.
As RADIUS has no provisions for capability signalling, there is no As RADIUS has no provisions for capability signaling, there is no way
way for a server to indicate to a client that it should transition to 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 using DTLS. This action has to be taken by the administrators of the
two systems, using a method other than RADIUS. This method will two systems, using a method other than RADIUS. This method will
likely be out of band, or manual configuration. likely be out of band, or manual configuration will need to be used.
Some servers maintain a list of allowed clients per destination port. Some servers maintain a list of allowed clients per destination port.
Others maintain a global list of clients, which are permitted to send Others maintain a global list of clients that are permitted to send
packets to any port. Where a client can send packets to multiple packets to any port. Where a client can send packets to multiple
ports, the server MUST maintain a "DTLS Required" flag per client. ports, the server MUST maintain a "DTLS Required" flag per client.
This flag indicates whether or not the client is required to use This flag indicates whether or not the client is required to use
DTLS. When set, the flag indicates that the only traffic accepted DTLS. When set, the flag indicates that the only traffic accepted
from the client is over UDP/2083. When packets are received from a 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 client on non-DTLS ports, for which DTLS is required, the server MUST
silently discard these packets, as there is no RADIUS/UDP shared silently discard these packets, as there is no RADIUS/UDP shared
secret available. secret available.
This flag will often be set by an administrator. However, if a This flag will often be set by an administrator. However, if a
server receives DTLS traffic from a client, it SHOULD notify the server receives DTLS traffic from a client, it SHOULD notify the
administrator that DTLS is available for that client. It MAY mark administrator that DTLS is available for that client. It MAY mark
the client as "DTLS Required". the client as "DTLS Required".
It is RECOMMENDED that servers support the following perfect forward It is RECOMMENDED that servers support the following Perfect Forward
secrecy (PFS) cipher suites: Secrecy (PFS) ciphersuites:
o TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 o TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
o TLS_ECDHE_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 Allowing RADIUS/UDP and RADIUS/DTLS from the same client exposes the
traffic to downbidding attacks, and is NOT RECOMMENDED. traffic to downbidding attacks and is NOT RECOMMENDED.
4. Client Behavior 4. Client Behavior
When a client sends packets to the assigned RADIUS/DTLS port, all 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 packets MUST be DTLS. RADIUS/UDP packets MUST NOT be sent to this
port. port.
Clients MUST authenticate themselves to servers, via credentials Clients MUST authenticate themselves to servers via credentials that
which are unique to each client. are unique to each client.
It is RECOMMENDED that clients support the following PFS cipher It is RECOMMENDED that clients support the following PFS
suites: ciphersuites:
o TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 o TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
o TLS_ECDHE_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 RADIUS/DTLS clients SHOULD NOT probe servers to see if they support
DTLS transport. Instead, clients SHOULD use DTLS as a transport DTLS transport. Instead, clients SHOULD use DTLS as a transport
layer only when administratively configured. If a client is layer only when administratively configured. If a client is
configured to use DTLS and the server appears to be unresponsive, the configured to use DTLS and the server appears to be unresponsive, the
client MUST NOT fall back to using RADIUS/UDP. Instead, the client client MUST NOT fall back to using RADIUS/UDP. Instead, the client
should treat the server as being down. should treat the server as being down.
RADIUS clients often had multiple independent RADIUS implementations RADIUS clients often had multiple independent RADIUS implementations
skipping to change at page 12, line 14 skipping to change at page 12, line 18
5. Session Management 5. Session Management
Where [RFC6614] can rely on the TCP state machine to perform session Where [RFC6614] can rely on the TCP state machine to perform session
tracking, this specification cannot. As a result, implementations of tracking, this specification cannot. As a result, implementations of
this specification may need to perform session management of the DTLS this specification may need to perform session management of the DTLS
session in the application layer. This section describes logically session in the application layer. This section describes logically
how this tracking is done. Implementations may choose to use the how this tracking is done. Implementations may choose to use the
method described here, or another, equivalent method. method described here, or another, equivalent method.
We note that [RFC5080] Section 2.2.2 already mandates a duplicate We note that [RFC5080], Section 2.2.2, already mandates a duplicate
detection cache. The session tracking described below can be seen as detection cache. The session tracking described below can be seen as
an extension of that cache, where entries contain DTLS sessions an extension of that cache, where entries contain DTLS sessions
instead of RADIUS/UDP packets. instead of RADIUS/UDP packets.
[RFC5080] section 2.2.2 describes how duplicate RADIUS/UDP requests [RFC5080], Section 2.2.2, describes how duplicate RADIUS/UDP requests
result in the retransmission of a previously cached RADIUS/UDP result in the retransmission of a previously cached RADIUS/UDP
response. Due to DTLS sequence window requirements, a server MUST response. Due to DTLS sequence window requirements, a server MUST
NOT retransmit a previously sent DTLS packet. Instead, it should NOT retransmit a previously sent DTLS packet. Instead, it should
cache the RADIUS response packet, and re-process it through DTLS to cache the RADIUS response packet, and re-process it through DTLS to
create a new RADIUS/DTLS packet, every time it is necessary to create a new RADIUS/DTLS packet, every time it is necessary to
retransmit a RADIUS response. retransmit a RADIUS response.
5.1. Server Session Management 5.1. Server Session Management
A RADIUS/DTLS server MUST track ongoing DTLS sessions for each based A RADIUS/DTLS server MUST track ongoing DTLS sessions for each, based
the following 4-tuple: on the following 4-tuple:
* source IP address * source IP address
* source port * source port
* destination IP address * destination IP address
* destination port * destination port
Note that this 4-tuple is independent of IP address version (IPv4 or Note that this 4-tuple is independent of IP address version (IPv4 or
IPv6). IPv6).
Each 4-tuple points to a unique session entry, which usually contain Each 4-tuple points to a unique session entry, which usually contains
the following information: the following information:
DTLS Session DTLS Session
Any information required to maintain and manage the DTLS session. Any information required to maintain and manage the DTLS session.
Last Taffic Last Traffic
A variable containing a timestamp which indicates when this session A variable containing a timestamp that indicates when this session
last received valid traffic. If "Last Traffic" is not used, this last received valid traffic. If "Last Traffic" is not used, this
variable may not exist. variable may not exist.
DTLS Data DTLS Data
An implementation-specific variable which may contain information An implementation-specific variable that may contain information
about the active DTLS session. This variable may be empty or non about the active DTLS session. This variable may be empty or
existent. nonexistent.
This data will typically contain information such as idle timeouts, This data will typically contain information such as idle
session lifetimes, and other implementation-specific data. timeouts, session lifetimes, and other implementation-specific
data.
5.1.1. Session Opening and Closing 5.1.1. Session Opening and Closing
Session tracking is subject to Denial of Service (DoS) attacks due to Session tracking is subject to Denial-of-Service (DoS) attacks due to
the ability of an attacker to forge UDP traffic. RADIUS/DTLS servers the ability of an attacker to forge UDP traffic. RADIUS/DTLS servers
SHOULD use the stateless cookie tracking technique described in SHOULD use the stateless cookie tracking technique described in
[RFC6347] Section 4.2.1. DTLS sessions SHOULD NOT be tracked until a [RFC6347], Section 4.2.1. DTLS sessions SHOULD NOT be tracked until
ClientHello packet has been received with an appropriate Cookie a ClientHello packet has been received with an appropriate Cookie
value. Server implementation SHOULD have a way of tracking partially value. Server implementation SHOULD have a way of tracking DTLS
setup DTLS sessions. Servers MUST limit both the number and impact sessions that are partially set up. Servers MUST limit both the
on resources of partial sessions. number and impact on resources of partial sessions.
Sessions (both 4-tuple and entry) MUST be deleted when a TLS Closure 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] Alert ([RFC5246], Section 7.2.1) or a fatal TLS Error Alert
Section 7.2.2) is received. When a session is deleted due to it ([RFC5246], Section 7.2.2) is received. When a session is deleted
failing security requirements, the DTLS session MUST be closed, and due to it failing security requirements, the DTLS session MUST be
any TLS session resumption parameters for that session MUST be closed, any TLS session resumption parameters for that session MUST
discarded, and all tracking information MUST be deleted. be discarded, and all tracking information MUST be deleted.
Sessions MUST also be deleted when a RADIUS packet fails validation Sessions MUST also be deleted when a RADIUS packet fails validation
due to a packet being malformed, or when it has an invalid Message- due to a packet being malformed, or when it has an invalid Message-
Authenticator, or invalid Request Authenticator. There are other Authenticator or invalid Request Authenticator. There are other
cases when the specifications require that a packet received via a cases when the specifications require that a packet received via a
DTLS session be "silently discarded". In those cases, DTLS session be "silently discarded". In those cases,
implementations MAY delete the underlying session as described above. implementations MAY delete the underlying session as described above.
There are few reasons to communicate with a NAS which is not There are few reasons to communicate with a Network Access Server
implementing RADIUS. (NAS) that is not implementing RADIUS.
A session MUST be deleted when non-RADIUS traffic is received over A session MUST be deleted when non-RADIUS traffic is received over
it. This specification is for RADIUS, and there is no reason to it. This specification is for RADIUS, and there is no reason to
allow non-RADIUS traffic over a RADIUS/DTLS session. A session MUST allow non-RADIUS traffic over a RADIUS/DTLS session. A session MUST
be deleted when RADIUS traffic fails to pass security checks. There be deleted when RADIUS traffic fails to pass security checks. There
is no reason to permit insecure networks. A session SHOULD NOT be is no reason to permit insecure networks. A session SHOULD NOT be
deleted when a well-formed, but "unexpected" RADIUS packet is deleted when a well-formed, but "unexpected", RADIUS packet is
received over it. Future specifications may extend RADIUS/DTLS, and received over it. Future specifications may extend RADIUS/DTLS, and
we do not want to forbid those specifications. we do not want to forbid those specifications.
The goal of the above requirements is to ensure security, while The goal of the above requirements is to ensure security, while
maintaining flexibility. Any security related issue causes the maintaining flexibility. Any security-related issue causes the
connection to be closed. After the security restrictions have been connection to be closed. After the security restrictions have been
applied, any unexpected traffic may be safely ignored, as it cannot applied, any unexpected traffic may be safely ignored, as it cannot
cause a security issue. There is no need to close the session for cause a security issue. There is no need to close the session for
unexpected but valid traffic, and the session can safely remain open. unexpected but valid traffic, and the session can safely remain open.
Once a DTLS session is established, a RADIUS/DTLS server SHOULD use Once a DTLS session is established, a RADIUS/DTLS server SHOULD use
DTLS Heartbeats [RFC6520] to determine connectivity between the two DTLS Heartbeats [RFC6520] to determine connectivity between the two
servers. A server SHOULD also use watchdog packets from the client servers. A server SHOULD also use watchdog packets from the client
to determine that the session is still active. to determine that the session is still active.
As UDP does not guarantee delivery of messages, RADIUS/DTLS servers As UDP does not guarantee delivery of messages, RADIUS/DTLS servers
which do not implement an application-layer watchdog MUST also that do not implement an application-layer watchdog MUST also
maintain a "Last Traffic" timestamp per DTLS session. The maintain a "Last Traffic" timestamp per DTLS session. The
granularity of this timestamp is not critical, and could be limited granularity of this timestamp is not critical and could be limited to
to one second intervals. The timestamp SHOULD be updated on one-second intervals. The timestamp SHOULD be updated on reception
reception of a valid RADIUS/DTLS packet, or a DTLS Heartbeat, but no of a valid RADIUS/DTLS packet, or a DTLS Heartbeat, but no more than
more than once per interval. The timestamp MUST NOT be updated in once per interval. The timestamp MUST NOT be updated in other
other situations. situations.
When a session has not received a packet for a period of time, it is When a session has not received a packet for a period of time, it is
labelled "idle". The server SHOULD delete idle DTLS sessions after labeled "idle". The server SHOULD delete idle DTLS sessions after an
an "idle timeout". The server MAY cache the TLS session parameters, "idle timeout". The server MAY cache the TLS session parameters, in
in order to provide for fast session resumption. order to provide for fast session resumption.
This session "idle timeout" SHOULD be exposed to the administrator as This session "idle timeout" SHOULD be exposed to the administrator as
a configurable setting. It SHOULD NOT be set to less than 60 a configurable setting. It SHOULD NOT be set to less than 60 seconds
seconds, and SHOULD NOT be set to more than 600 seconds (10 minutes). and SHOULD NOT be set to more than 600 seconds (10 minutes). The
The minimum value useful value for this timer is determined by the minimum useful value for this timer is determined by the application-
application-layer watchdog mechanism defined in the following layer watchdog mechanism defined in the following section.
section.
RADIUS/DTLS servers SHOULD also monitor the total number of open RADIUS/DTLS servers SHOULD also monitor the total number of open
sessions. They SHOULD have a "maximum sessions" setting exposed to sessions. They SHOULD have a "maximum sessions" setting exposed to
administrators as a configurable parameter. When this maximum is administrators as a configurable parameter. When this maximum is
reached and a new session is started, the server MUST either drop an reached and a new session is started, the server MUST either drop an
old session in order to open the new one, or instead not create a new old session in order to open the new one or not create a new session.
session.
RADIUS/DTLS servers SHOULD implement session resumption, preferably RADIUS/DTLS servers SHOULD implement session resumption, preferably
stateless session resumption as given in [RFC5077]. This practice stateless session resumption as given in [RFC5077]. This practice
lowers the time and effort required to start a DTLS session with a lowers the time and effort required to start a DTLS session with a
client, and increases network responsiveness. client and increases network responsiveness.
Since UDP is stateless, the potential exists for the client to Since UDP is stateless, the potential exists for the client to
initiate a new DTLS session using a particular 4-tuple, before the initiate a new DTLS session using a particular 4-tuple, before the
server has closed the old session. For security reasons, the server server has closed the old session. For security reasons, the server
MUST keep the old session active until either it has received secure MUST keep the old session active until either it has received secure
notification from the client that the session is closed, or when the notification from the client that the session is closed or the server
server decides to close the session based on idle timeouts. Taking decides to close the session based on idle timeouts. Taking any
any other action would permit unauthenticated clients to perform a other action would permit unauthenticated clients to perform a DoS
DoS attack, by re-using a 4-tuple, and thus causing the server to attack, by reusing a 4-tuple and thus causing the server to close an
close an active (and authenticated) DTLS session. active (and authenticated) DTLS session.
As a result, servers MUST ignore any attempts to re-use an existing As a result, servers MUST ignore any attempts to reuse an existing
4-tuple from an active session. This requirement can likely be 4-tuple from an active session. This requirement can likely be
reached by simply processing the packet through the existing session, reached by simply processing the packet through the existing session,
as with any other packet received via that 4-tuple. Non-compliant, as with any other packet received via that 4-tuple. Non-compliant,
or unexpected packets will be ignored by the DTLS layer. or unexpected packets will be ignored by the DTLS layer.
The above requirement is mitigated by the suggestion in Section 6.1, The above requirement is mitigated by the suggestion in Section 6.1,
below, that the client use a local proxy for all RADIUS traffic. 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 That proxy can then track the ports that it uses and ensure that
re-use of 4-tuples is avoided. The exact process by which this reuse of 4-tuples is avoided. The exact process by which this
tracking is done is outside of the scope of this document. tracking is done is outside of the scope of this document.
5.2. Client Session Management 5.2. Client Session Management
Clients SHOULD use PMTU discovery [RFC6520] to determine the PMTU Clients SHOULD use PMTU discovery [RFC6520] to determine the PMTU
between the client and server, prior to sending any RADIUS traffic. between the client and server, prior to sending any RADIUS traffic.
Once a DTLS session is established, a RADIUS/DTLS client SHOULD use Once a DTLS session is established, a RADIUS/DTLS client SHOULD use
DTLS Heartbeats [RFC6520] to determine connectivity between the two DTLS Heartbeats [RFC6520] to determine connectivity between the two
systems. RADIUS/DTLS clients SHOULD also use the application-layer systems. RADIUS/DTLS clients SHOULD also use the application-layer
watchdog algorithm defined in [RFC3539] to determine server watchdog algorithm defined in [RFC3539] to determine server
responsiveness. The Status-Server packet defined in [RFC5997] SHOULD responsiveness. The Status-Server packet defined in [RFC5997] SHOULD
be used as the "watchdog packet" in any application-layer watchdog be used as the "watchdog packet" in any application-layer watchdog
algorithm. algorithm.
RADIUS/DTLS clients SHOULD pro-actively close sessions when they have RADIUS/DTLS clients SHOULD proactively close sessions when they have
been idle for a period of time. Clients SHOULD close a session when been idle for a period of time. Clients SHOULD close a session when
the DTLS Heartbeat algorithm indicates that the session is no longer the DTLS Heartbeat algorithm indicates that the session is no longer
active. Clients SHOULD close a session when no traffic other than active. Clients SHOULD close a session when no traffic other than
watchdog packets and (possibly) watchdog responses have been sent for watchdog packets and (possibly) watchdog responses has been sent for
three watchdog timeouts. This behavior ensures that clients do not three watchdog timeouts. This behavior ensures that clients do not
waste resources on the server by causing it to track idle sessions. waste resources on the server by causing it to track idle sessions.
When client fails to implement both DTLS heartbeats and watchdog When a client fails to implement both DTLS Heartbeats and watchdog
packets, it has no way of knowing that a DTLS session has been packets, it has no way of knowing that a DTLS session has been
closed. There is therefore the possibility that the server closes closed. Therefore, there is the possibility that the server closes
the session without the client knowing. When that happens, the the session without the client knowing. When that happens, the
client may later transmit packets in a session, and those packets 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 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 those packets and then the session, leading to delays and network
instabilities. instabilities.
For these reasons, it is RECOMMENDED that all DTLS sessions are For these reasons, it is RECOMMENDED that all DTLS sessions be
configured to use DTLS heartbeats and/or watchdog packets. configured to use DTLS Heartbeats and/or watchdog packets.
DTLS sessions MUST also be deleted when a RADIUS packet fails DTLS sessions MUST also be deleted when a RADIUS packet fails
validation due to a packet being malformed, or when it has an invalid validation due to a packet being malformed, or when it has an invalid
Message-Authenticator, or invalid Response Authenticator. There are Message-Authenticator or invalid Response Authenticator. There are
other cases when the specifications require that a packet received other cases when the specifications require that a packet received
via a DTLS session be "silently discarded". In those cases, via a DTLS session be "silently discarded". In those cases,
implementations MAY delete the underlying DTLS session. implementations MAY delete the underlying DTLS session.
RADIUS/DTLS clients should not send both RADIUS/UDP and RADIUS/DTLS RADIUS/DTLS clients should not send both RADIUS/UDP and RADIUS/DTLS
packets to different servers from the same source socket. This packets to different servers from the same source socket. This
practice causes increased complexity in the client application, and practice causes increased complexity in the client application and
increases the potential for security breaches due to implementation increases the potential for security breaches due to implementation
issues. issues.
RADIUS/DTLS clients SHOULD implement session resumption, preferably RADIUS/DTLS clients SHOULD implement session resumption, preferably
stateless session resumption as given in [RFC5077]. This practice stateless session resumption as given in [RFC5077]. This practice
lowers the time and effort required to start a DTLS session with a lowers the time and effort required to start a DTLS session with a
server, and increases network responsiveness. server and increases network responsiveness.
6. Implementation Guidelines 6. Implementation Guidelines
The text above describes the protocol. In this section, we give The text above describes the protocol. In this section, we give
additional implementation guidelines. These guidelines are not part additional implementation guidelines. These guidelines are not part
of the protocol, but may help implementors create simple, secure, and of the protocol, but they may help implementors create simple,
inter-operable implementations. secure, and interoperable implementations.
Where a TLS pre-shared key (PSK) method is used, implementations MUST Where a TLS-PSK method is used, implementations MUST support keys of
support keys of at least 16 octets in length. Implementations SHOULD at least 16 octets in length. Implementations SHOULD support key
support key lengths of 32 octets, and SHOULD allow for longer keys. lengths of 32 octets and SHOULD allow for longer keys. The key data
The key data MUST be capable of being any value (0 through 255, MUST be capable of being any value (0 through 255, inclusive).
inclusive). Implementations MUST NOT limit themselves to using Implementations MUST NOT limit themselves to using textual keys. It
textual keys. It is RECOMMENDED that the administration interface is RECOMMENDED that the administration interface allow for the keys
allows for the keys to be entered as humanly readable strings in hex to be entered as human-readable strings in hex format.
format.
When creating keys for use with PSK cipher suites, it is RECOMMENDED When creating keys for use with PSK ciphersuites, it is RECOMMENDED
that keys be derived from a cryptographically secure pseudo-random that keys be derived from a Cryptographically Secure Pseudorandom
number generator (CSPRNG) instead of administrators inventing keys on Number Generator (CSPRNG) instead of administrators inventing keys on
their own. If managing keys is too complicated, a certificate-based their own. If managing keys is too complicated, a certificate-based
TLS method SHOULD be used instead. TLS method SHOULD be used instead.
6.1. Client Implementations 6.1. Client Implementations
RADIUS/DTLS clients should use connected sockets where possible. Use RADIUS/DTLS clients should use connected sockets where possible. Use
of connected sockets means that the underlying kernel tracks the of connected sockets means that the underlying kernel tracks the
sessions, so that the client subsystem does not need to manage sessions, so that the client subsystem does not need to manage
multiple sessions on one socket. multiple sessions on one socket.
RADIUS/DTLS clients should use a single source (IP + port) when RADIUS/DTLS clients should use a single source (IP + port) when
sending packets to a particular RADIUS/DTLS server. Doing so sending packets to a particular RADIUS/DTLS server. Doing so
minimizes the number of DTLS session setups. It also ensures that minimizes the number of DTLS session setups. It also ensures that
information about the home server state is discovered only once. information about the home server state is discovered only once.
In practice, this means that RADIUS/DTLS clients with multiple In practice, this means that RADIUS/DTLS clients with multiple
internal RADIUS sources should use a local proxy which arbitrates all internal RADIUS sources should use a local proxy that arbitrates all
RADIUS traffic between the client and all servers. The proxy should RADIUS traffic between the client and all servers. The proxy should
accept traffic only from the authorized subsystems on the client accept traffic only from the authorized subsystems on the client
machine, and should proxy that traffic to known servers. Each machine and should proxy that traffic to known servers. Each
authorized subsystem should include an attribute which uniquely authorized subsystem should include an attribute that uniquely
identifies that subsystem to the proxy, so that the proxy can apply identifies that subsystem to the proxy, so that the proxy can apply
origin-specific proxy rules and security policies. We suggest using origin-specific proxy rules and security policies. We suggest using
NAS-Identifier for this purpose. NAS-Identifier for this purpose.
The local proxy should be able to interact with multiple servers at 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 the same time. There is no requirement that each server have its own
unique proxy on the client, as that would be inefficient. unique proxy on the client, as that would be inefficient.
The suggestion to use a local proxy means that there is only one The suggestion to use a local proxy means that there is only one
process which discovers network and/or connectivity issues with a process that discovers network and/or connectivity issues with a
server. If each client subsystem communicated directly with a server. If each client subsystem communicated directly with a
server, issues with that server would have to be discovered server, issues with that server would have to be discovered
independently by each subsystem. The side effect would be increased independently by each subsystem. The side effect would be increased
delays in re-routing traffic, error reporting, and network delays in re-routing traffic, error reporting, and network
instabilities. instabilities.
Each client subsystem can include a subsystem-specific NAS-Identifier Each client subsystem can include a subsystem-specific NAS-Identifier
in each request. The format of this attribute is implementation- in each request. The format of this attribute is implementation-
specific. The proxy should verify that the request originated from specific. The proxy should verify that the request originated from
the local system, ideally via a loopback address. The proxy MUST the local system, ideally via a loopback address. The proxy MUST
then re-write any subsystem-specific NAS-Identifier to a NAS- then rewrite any subsystem-specific NAS-Identifier to a NAS-
Identifier which identifies the client as a whole. Or, remove NAS- Identifier that identifies the client as a whole, or, remove the NAS-
Identifier entirely and replace it with NAS-IP-Address or NAS- Identifier entirely and replace it with NAS-IP-Address or NAS-
IPv6-Address. IPv6-Address.
In traditional RADIUS, the cost to set up a new "session" between a In traditional RADIUS, the cost to set up a new "session" between a
client and server was minimal. The client subsystem could simply client and server was minimal. The client subsystem could simply
open a port, send a packet, wait for the response, and the close the open a port, send a packet, wait for the response, and then close the
port. With RADIUS/DTLS, the connection setup is significantly more port. With RADIUS/DTLS, the connection setup is significantly more
expensive. In addition, there may be a requirement to use DTLS in expensive. In addition, there may be a requirement to use DTLS in
order to communicate with a server, as RADIUS/UDP may not be order to communicate with a server, as RADIUS/UDP may not be
supported by that server. The knowledge of what protocol to use is supported by that server. The knowledge of what protocol to use is
best managed by a dedicated RADIUS subsystem, rather than by each best managed by a dedicated RADIUS subsystem, rather than by each
individual subsystem on the client. individual subsystem on the client.
6.2. Server Implementations 6.2. Server Implementations
RADIUS/DTLS servers should not use connected sockets to read DTLS RADIUS/DTLS servers should not use connected sockets to read DTLS
packets from a client. This recommendation is because a connected packets from a client. This recommendation exists because a
UDP socket will accept packets only from one source IP address and connected UDP socket will accept packets only from one source IP
port. This limitation would prevent the server from accepting address and port. This limitation would prevent the server from
packets from multiple clients on the same port. accepting packets from multiple clients on the same port.
7. Diameter Considerations 7. Diameter Considerations
This specification defines a transport layer for RADIUS. It makes no This specification defines a transport layer for RADIUS. It makes no
other changes to the RADIUS protocol. As a result, there are no other changes to the RADIUS protocol. As a result, there are no
Diameter considerations. Diameter considerations.
8. IANA Considerations 8. IANA Considerations
No new RADIUS attributes or packet codes are defined. IANA is No new RADIUS attributes or packet codes are defined. IANA has
requested to update the "Service Name and Transport Protocol Port updated the "Service Name and Transport Protocol Port Number
Number Registry". The entry corresponding to port service name Registry". The entries corresponding to port service name "radsec",
"radsec", port number "2083", and transport protocol "UDP" should be port number "2083", and transport protocol "UDP" have been updated as
updated as follows: follows:
o Assignee: change "Mike McCauley" to "IESG". o Assignee: IESG
o Contact: change "Mike McCauley" to "IETF Chair" o Contact: IETF Chair
o Reference: Add this document as a reference o Reference: This document
o Assignment Notes: add the text "The UDP port 2083 was already o Assignment Notes: The UDP port 2083 was already previously
previously assigned by IANA for "RadSec", an early implementation assigned by IANA for "RadSec", an early implementation of
of RADIUS/TLS, prior to issuance of this RFC." RADIUS/TLS, prior to issuance of this RFC.
9. Implementation Status 9. Implementation Status
This section records the status of known implementations of This section records the status of known implementations of
RADIUS/DTLS at the time of posting of this Internet- Draft, and is RADIUS/DTLS at the time of writing, and is based on a proposal
based on a proposal described in [RFC6982]. described in [RFC6982].
The description of implementations in this section is intended to The description of implementations in this section is intended to
assist the IETF in its decision processes in progressing drafts to assist the IETF in its decision processes in progressing Internet-
RFCs. Drafts to RFCs.
9.1. Radsecproxy 9.1. Radsecproxy
Organization: Radsecproxy Organization: Radsecproxy
URL: https://software.uninett.no/radsecproxy/ URL: https://software.uninett.no/radsecproxy/
Maturity: Widely-used software based on early drafts of this Maturity: Widely used software based on early versions of this
document. document.
The use of the DTLS functionality is not clear. The use of the DTLS functionality is not clear.
Coverage: The bulk of this specification is implemented, based on Coverage: The bulk of this specification is implemented, based on
earlier versions of this document. Exact revisions earlier versions of this document. Exact revisions that
which were implemented are unknown. were implemented are unknown.
Licensing: Freely distributable with acknowledgement Licensing: Freely distributable with acknowledgment.
Implementation experience: No comments from implementors. Implementation experience: No comments from implementors.
9.2. jradius 9.2. jradius
Organization: Coova Organization: Coova
URL: http://www.coova.org/JRadius/RadSec URL: http://www.coova.org/JRadius/RadSec
Maturity: Production software based on early drafts of this Maturity: Production software based on early versions of this
document. document.
The use of the DTLS functionality is not clear. The use of the DTLS functionality is not clear.
Coverage: The bulk of this specification is implemented, based on Coverage: The bulk of this specification is implemented, based on
earlier versions of this document. Exact revisions earlier versions of this document. Exact revisions that
which were implemented are unknown. were implemented are unknown.
Licensing: Freely distributable with requirement to Licensing: Freely distributable with requirement to redistribute
redistribute source. source.
Implementation experience: No comments from implementors. Implementation experience: No comments from implementors.
10. Security Considerations 10. Security Considerations
The bulk of this 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 considerations related to RADIUS. However, we discuss a few
additional issues here. additional issues here.
This specification relies on the existing DTLS, RADIUS/UDP, and This specification relies on the existing DTLS, RADIUS/UDP, and
skipping to change at page 19, line 50 skipping to change at page 20, line 21
However, many security considerations raised in the RADIUS documents However, many security considerations raised in the RADIUS documents
are related to RADIUS encryption and authorization. Those issues are are related to RADIUS encryption and authorization. Those issues are
largely mitigated when DTLS is used as a transport method. The largely mitigated when DTLS is used as a transport method. The
issues that are not mitigated by this specification are related to issues that are not mitigated by this specification are related to
the RADIUS packet format and handling, which is unchanged in this the RADIUS packet format and handling, which is unchanged in this
specification. specification.
This specification also suggests that implementations use a session This specification also suggests that implementations use a session
tracking table. This table is an extension of the duplicate tracking table. This table is an extension of the duplicate
detection cache mandated in [RFC5080] Section 2.2.2. The changes detection cache mandated in [RFC5080], Section 2.2.2. The changes
given here are that DTLS-specific information is tracked for each given here are that DTLS-specific information is tracked for each
table entry. Section 5.1.1, above, describes steps to mitigate any table entry. Section 5.1.1, above, describes steps to mitigate any
DoS issues which result from tracking additional information. DoS issues that result from tracking additional information.
The fixed shared secret given above in Section 2.2.1 is acceptible The fixed shared secret given above in Section 2.2.1 is acceptable
only when DTLS is used with an non-null encryption method. When a only when DTLS is used with a non-null encryption method. When a
DTLS session uses a null encryption method due to misconfiguration or DTLS session uses a null encryption method due to misconfiguration or
implementation error, all of the RADIUS traffic will be readable by implementation error, all of the RADIUS traffic will be readable by
an observer. Implementations therefore MUST NOT use null encryption an observer. Therefore, implementations MUST NOT use null encryption
methods for RADIUS/DTLS. methods for RADIUS/DTLS.
For systems which perform protocol-based firewalling and/or For systems that perform protocol-based firewalling and/or filtering,
filtering, it is RECOMMENDED that they be configured to permit only it is RECOMMENDED that they be configured to permit only DTLS over
DTLS over the RADIUS/DTLS port. the RADIUS/DTLS port.
10.1. Crypto-Agility 10.1. Crypto-Agility
Section 4.2 of [RFC6421] makes a number of recommendations about Section 4.2 of [RFC6421] makes a number of recommendations about
security properties of new RADIUS proposals. All of those security properties of new RADIUS proposals. All of those
recommendations are satisfied by using DTLS as the transport layer. recommendations are satisfied by using DTLS as the transport layer.
Section 4.3 of [RFC6421] makes a number of recommendations about Section 4.3 of [RFC6421] makes a number of recommendations about
backwards compatibility with RADIUS. Section 3, above, addresses backwards compatibility with RADIUS. Section 3, above, addresses
these concerns in detail. these concerns in detail.
skipping to change at page 20, line 44 skipping to change at page 21, line 18
addresses concerns about documenting the transition from legacy addresses concerns about documenting the transition from legacy
RADIUS to crypto-agile RADIUS. RADIUS to crypto-agile RADIUS.
Section 4.6 of [RFC6421] requires automated key management. This Section 4.6 of [RFC6421] requires automated key management. This
requirement is satisfied by using DTLS key management. requirement is satisfied by using DTLS key management.
10.2. Legacy RADIUS Security 10.2. Legacy RADIUS Security
We reiterate here the poor security of the legacy RADIUS protocol. We reiterate here the poor security of the legacy RADIUS protocol.
We suggest that RADIUS clients and servers implement either this We suggest that RADIUS clients and servers implement either this
specification, or [RFC6614]. New attacks on MD5 have appeared over specification or [RFC6614]. New attacks on MD5 have appeared over
the past few years, and there is a distinct possibility that MD5 may 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 be completely broken in the near future. Such a break would mean
that RADIUS/UDP was completely insecure. that RADIUS/UDP was completely insecure.
The existence of fast and cheap attacks on MD5 could result in a loss The existence of fast and cheap attacks on MD5 could result in a loss
of all network security which depends on RADIUS. Attackers could of all network security that depends on RADIUS. Attackers could
obtain user passwords, and possibly gain complete network access. We obtain user passwords and possibly gain complete network access. We
cannot overstate the disastrous consequences of a successful attack cannot overstate the disastrous consequences of a successful attack
on RADIUS. on RADIUS.
We also caution implementors (especially client implementors) about We also caution implementors (especially client implementors) about
using RADIUS/DTLS. It may be tempting to use the shared secret as 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 the basis for a TLS-PSK method and to leave the user interface
user interface otherwise unchanged. This practice MUST NOT be used. otherwise unchanged. This practice MUST NOT be used. The
The administrator MUST be given the option to use DTLS. Any shared administrator MUST be given the option to use DTLS. Any shared
secret used for RADIUS/UDP MUST NOT be used for DTLS. Re-using a 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 shared secret between RADIUS/UDP and RADIUS/DTLS would negate all of
the benefits found by using DTLS. the benefits found by using DTLS.
RADIUS/DTLS client implementors MUST expose a configuration that RADIUS/DTLS client implementors MUST expose a configuration that
allows the administrator to choose the cipher suite. Where allows the administrator to choose the ciphersuite. Where
certificates are used, RADIUS/DTLS client implementors MUST expose a certificates are used, RADIUS/DTLS client implementors MUST expose a
configuration which allows an administrator to configure all configuration that allows an administrator to configure all
certificates necessary for certificate-based authentication. These certificates necessary for certificate-based authentication. These
certificates include client, server, and root certificates. certificates include client, server, and root certificates.
TLS-PSK methods are susceptible to dictionary attacks. Section 6, TLS-PSK methods are susceptible to dictionary attacks. Section 6,
above, recommends deriving TLS-PSK keys from a Cryptographically above, recommends deriving TLS-PSK keys from a Cryptographically
Secure Pseudo-Random Number Generator (CSPRNG), which makes Secure Pseudorandom Number Generator (CSPRNG), which makes dictionary
dictionary attacks significantly more difficult. Servers SHOULD attacks significantly more difficult. Servers SHOULD track failed
track failed client connections by TLS-PSK ID, and block TLS-PSK IDs client connections by TLS-PSK ID and block TLS-PSK IDs that seem to
which seem to be attempting brute-force searchs of the keyspace. be attempting brute-force searches of the keyspace.
The historic RADIUS practice of using shared secrets (here, PSKs) The historic RADIUS practice of using shared secrets (here, PSKs)
that are minor variations of words is NOT RECOMMENDED, as it would that are minor variations of words is NOT RECOMMENDED, as it would
negate all of the security of DTLS. negate all of the security of DTLS.
10.3. Resource Exhaustion 10.3. Resource Exhaustion
The use of DTLS allows DoS attacks, and resource exhaustion attacks The use of DTLS allows DoS attacks and resource-exhaustion attacks
which were not possible in RADIUS/UDP. These attacks are the similar that were not possible in RADIUS/UDP. These attacks are similar to
to those described in [RFC6614] Section 6, for TCP. those described in [RFC6614], Section 6, for TCP.
Session tracking as described in Section 5.1 can result in resource Session tracking, as described in Section 5.1, can result in resource
exhaustion. Servers MUST therefore limit the absolute number of exhaustion. Therefore, servers MUST limit the absolute number of
sessions that they track. When the total number of sessions tracked sessions that they track. When the total number of sessions tracked
is going to exceed the configured limit, servers MAY free up is going to exceed the configured limit, servers MAY free up
resources by closing the session which has been idle for the longest resources by closing the session that has been idle for the longest
time. Doing so may free up idle resources which then allow the time. Doing so may free up idle resources that then allow the server
server to accept a new session. to accept a new session.
Servers MUST limit the number of partially open DTLS sessions. These Servers MUST limit the number of partially open DTLS sessions. These
limits SHOULD be exposed to the administrator as configurable limits SHOULD be exposed to the administrator as configurable
settings. settings.
10.4. Client-Server Authentication with DTLS 10.4. Client-Server Authentication with DTLS
We expect that the initial deployment of DTLS will be follow the We expect that the initial deployment of DTLS will follow the
RADIUS/UDP model of statically configured client-server RADIUS/UDP model of statically configured client-server
relationships. The specification for dynamic discovery of RADIUS relationships. The specification for dynamic discovery of RADIUS
servers is under development, so we will not address that here. servers is under development, so we will not address that here.
Static configuration of client-server relationships for RADIUS/UDP Static configuration of client-server relationships for RADIUS/UDP
means that a client has a fixed IP address for a server, and a shared 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 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 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 to authenticate traffic from that address. This model needs to be
extended for RADIUS/DTLS. extended for RADIUS/DTLS.
Instead of a shared secret, TLS credentials MUST be used by each Instead of a shared secret, TLS credentials MUST be used by each
party to authenticate the other. The issue of identity is more party to authenticate the other. The issue of identity is more
problematic. As with RADIUS/UDP, IP addresses may be used as a key problematic. As with RADIUS/UDP, IP addresses may be used as a key
to determine the authentication credentials which a client will to determine the authentication credentials that a client will
present to a server, or which credentials a server will accept from a 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 client. This is the fixed IP address model of RADIUS/UDP, with the
shared secret replaced by TLS credentials. shared secret replaced by TLS credentials.
There are, however, additional considerations with RADIUS/DTLS. When There are, however, additional considerations with RADIUS/DTLS. When
a client is configured with a host name for a server, the server may a client is configured with a hostname for a server, the server may
present to the client a certificate containing a host name. The present to the client a certificate containing a hostname. The
client MUST then verify that the host names match. Any mismatch is a client MUST then verify that the hostnames match. Any mismatch is a
security violation, and the connection MUST be closed. security violation, and the connection MUST be closed.
A RADIUS/DTLS server MAY be configured with a "wildcard" IP address A RADIUS/DTLS server MAY be configured with a "wildcard" IP address
match for clients, instead of a unique fixed IP address for each match for clients, instead of a unique fixed IP address for each
client. In that case, clients MUST be individually configured with a client. In that case, clients MUST be individually configured with a
unique certificate. When the server receives a connection from a unique certificate. When the server receives a connection from a
client, it MUST determine client identity from the client client, it MUST determine client identity from the client
certificate, and MUST authenticate (or not) the client based on that certificate, and MUST authenticate (or not) the client based on that
certificate. See [RFC6614] Section 2.4 for a discussion of how to certificate. See [RFC6614], Section 2.4, for a discussion of how to
match a certificate to a client identity. match a certificate to a client identity.
However, servers SHOULD use IP address filtering to minimize the However, servers SHOULD use IP address filtering to minimize the
possibility of attacks. That is, they SHOULD permit clients only possibility of attacks. That is, they SHOULD permit clients only
from a limited IP address range or ranges. They SHOULD silently from a limited IP address range or ranges. They SHOULD silently
discard all traffic from outside of those ranges. discard all traffic from outside of those ranges.
Since the client-server relationship is static, the authentication Since the client-server relationship is static, the authentication
credentials for that relationship must also be statically configured. credentials for that relationship must also be statically configured.
That is, a client connecting to a DTLS server SHOULD be pre- That is, a client connecting to a DTLS server SHOULD be pre-
configured with the servers credentials (e.g. PSK or certificate). configured with the server's credentials (e.g., PSK or certificate).
If the server fails to present the correct credentials, the DTLS If the server fails to present the correct credentials, the DTLS
session MUST be closed. Each server SHOULD be preconfigured with session MUST be closed. Each server SHOULD be pre-configured with
sufficient information to authenticate connecting clients. sufficient information to authenticate connecting clients.
The requirement for clients to be individually configured with a The requirement for clients to be individually configured with a
unique certificate can be met by using a private Certificate unique certificate can be met by using a private CA for certificates
Authority (CA) for certificates used in RADIUS/DTLS environments. If used in RADIUS/DTLS environments. If a client were configured to use
a client were configured to use a public CA, then it could accept as a public CA, then it could accept as valid any server that has a
valid any server which has a certificate signed by that CA. While certificate signed by that CA. While the traffic would be secure
the traffic would be secure from third-party observers, the server from third-party observers, the server would, however, have
would, howrver, have unrestricted access to all of the RADIUS unrestricted access to all of the RADIUS traffic, including all user
traffic, including all user credentials and passwords. credentials and passwords.
Therefore, clients SHOULD NOT be pre-configured with a list of known Therefore, clients SHOULD NOT be pre-configured with a list of known
public CAs by the vendor or manufacturer. Instead, the clients public CAs by the vendor or manufacturer. Instead, the clients
SHOULD start off with an empty CA list. The addition of a CA SHOULD SHOULD start off with an empty CA list. The addition of a CA SHOULD
be done only when manually configured by an administrator. be done only when manually configured by an administrator.
This scenario is the opposite of web browsers, where they are pre- This scenario is the opposite of web browsers, where they are pre-
configured with many known CAs. The goal there is security from configured with many known CAs. The goal there is security from
third-party observers, but also the ability to communicate with any third-party observers, but also the ability to communicate with any
unknown site which presents a signed certificate. In contrast, the unknown site that presents a signed certificate. In contrast, the
goal of RADIUS/DTLS is both security from third-party observers, and goal of RADIUS/DTLS is both security from third-party observers and
the ability to communicate with only a small set of well-known the ability to communicate with only a small set of well-known
servers. servers.
This requirement does not prevent clients from using hostnames This requirement does not prevent clients from using hostnames
instead of IP addresses for locating a particular server. Instead, instead of IP addresses for locating a particular server. Instead,
it means that the credentials for that server should be preconfigured it means that the credentials for that server should be pre-
on the client, and associated with that hostname. This requirement configured on the client, and associated with that hostname. This
does suggest that in the absence of a specification for dynamic requirement does suggest that in the absence of a specification for
discovery, clients SHOULD use only those servers which have been dynamic discovery, clients SHOULD use only those servers that have
manually configured by an administrator. been manually configured by an administrator.
10.5. Network Address Translation 10.5. Network Address Translation
Network Address Translation (NAT) is fundamentally incompatible with Network Address Translation (NAT) is fundamentally incompatible with
RADIUS/UDP. RADIUS/UDP uses the source IP address to determine the RADIUS/UDP. RADIUS/UDP uses the source IP address to determine the
shared secret for the client, and NAT hides many clients behind one shared secret for the client, and NAT hides many clients behind one
source IP address. As a result, RADIUS/UDP clients can not be source IP address. As a result, RADIUS/UDP clients cannot be located
located behind a NAT gateway. behind a NAT gateway.
In addition, port re-use on a NAT gateway means that packets from 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 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 NAT. That is, a RADIUS server may receive a RADIUS/DTLS packet from
one source IP/port combination, followed by the reception of a one source IP/port combination, followed by the reception of a
RADIUS/UDP packet from that same source IP/port combination. If this RADIUS/UDP packet from that same source IP/port combination. If this
behavior is allowed, then the server would have an inconsistent view behavior is allowed, then the server would have an inconsistent view
of the clients security profile, allowing an attacker to choose the of the client's security profile, allowing an attacker to choose the
most insecure method. most insecure method.
If more than one client is located behind a NAT gateway, then every 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 client behind the NAT MUST use a secure transport such as TLS or
DTLS. As discussed below, a method for uniquely identifying each DTLS. As discussed below, a method for uniquely identifying each
client MUST be used. client MUST be used.
10.6. Wildcard Clients 10.6. Wildcard Clients
Some RADIUS server implementations allow for "wildcard" clients. Some RADIUS server implementations allow for "wildcard" clients --
That is, clients with an IPv4 netmask of other than 32, or an IPv6 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 will use the same shared RADIUS/UDP, as it means multiple clients will use the same shared
secret. secret.
The use of RADIUS/DTLS can allow for the safe usage of wildcards. The use of RADIUS/DTLS can allow for the safe usage of wildcards.
When RADIUS/DTLS is used with wildcards, clients MUST be uniquely When RADIUS/DTLS is used with wildcards, clients MUST be uniquely
identified using TLS parameters, and any certificate or PSK used MUST identified using TLS parameters, and any certificate or PSK used MUST
be unique to each client. be unique to each client.
10.7. Session Closing 10.7. Session Closing
Section 5.1.1, above, requires that DTLS sessions be closed when the Section 5.1.1, above, requires that DTLS sessions be closed when the
transported RADIUS packets are malformed, or fail the authenticator transported RADIUS packets are malformed or fail the authenticator
checks. The reason is that the session is expected to be used for checks. The reason is that the session is expected to be used for
transport of RADIUS packets only. transport of RADIUS packets only.
Any non-RADIUS traffic on that session means the other party is Any non-RADIUS traffic on that session means the other party is
misbehaving, and is a potential security risk. Similarly, any RADIUS misbehaving and is a potential security risk. Similarly, any RADIUS
traffic failing authentication vector or Message-Authenticator traffic failing authentication vector or Message-Authenticator
validation means that two parties do not have a common shared secret, validation means that two parties do not have a common shared secret,
and the session is therefore unauthenticated and insecure. and the session is therefore unauthenticated and insecure.
We wish to avoid the situation where a third party can send well- We wish to avoid the situation where a third party can send well-
formed RADIUS packets which cause a DTLS session to close. formed RADIUS packets that cause a DTLS session to close. Therefore,
Therefore, in other situations, the session SHOULD remain open in the in other situations, the session SHOULD remain open in the face of
face of non-conformant packets. non-conformant packets.
10.8. Client Subsystems 10.8. Client Subsystems
Many traditional clients treat RADIUS as subsystem-specific. That Many traditional clients treat RADIUS as subsystem-specific. That
is, each subsystem on the client has its own RADIUS implementation is, each subsystem on the client has its own RADIUS implementation
and configuration. These independent implementations work for simple and configuration. These independent implementations work for simple
systems, but break down for RADIUS when multiple servers, fail-over, systems, but break down for RADIUS when multiple servers, fail-over,
and load-balancing are required. They have even worse issues when and load-balancing are required. They have even worse issues when
DTLS is enabled. DTLS is enabled.
As noted in Section 6.1, above, clients SHOULD use a local proxy As noted in Section 6.1, above, clients SHOULD use a local proxy that
which arbitrates all RADIUS traffic between the client and all arbitrates all RADIUS traffic between the client and all servers.
servers. This proxy will encapsulate all knowledge about servers, This proxy will encapsulate all knowledge about servers, including
including security policies, fail-over, and load-balancing. All security policies, fail-over, and load-balancing. All client
client subsystems SHOULD communicate with this local proxy, ideally subsystems SHOULD communicate with this local proxy, ideally over a
over a loopback address. The requirements on using strong shared loopback address. The requirements on using strong shared secrets
secrets still apply. still apply.
The benefit of this configuration is that there is one place in the The benefit of this configuration is that there is one place in the
client which arbitrates all RADIUS traffic. Subsystems which do not client that arbitrates all RADIUS traffic. Subsystems that do not
implement DTLS can remain unaware of DTLS. DTLS sessions opened by implement DTLS can remain unaware of DTLS. DTLS sessions opened by
the proxy can remain open for long periods of time, even when client the proxy can remain open for long periods of time, even when client
subsystems are restarted. The proxy can do RADIUS/UDP to some subsystems are restarted. The proxy can do RADIUS/UDP to some
servers, and RADIUS/DTLS to others. servers and RADIUS/DTLS to others.
Delegation of responsibilities and separation of tasks are important Delegation of responsibilities and separation of tasks are important
security principles. By moving all RADIUS/DTLS knowledge to a DTLS- security principles. By moving all RADIUS/DTLS knowledge to a DTLS-
aware proxy, security analysis becomes simpler, and enforcement of aware proxy, security analysis becomes simpler, and enforcement of
correct security becomes easier. correct security becomes easier.
11. References 11. References
11.1. Normative references 11.1. Normative References
[RFC2865] [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote Requirement Levels", BCP 14, RFC 2119, March 1997.
Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000.
[RFC3539] [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
Aboba, B. et al., "Authentication, Authorization and Accounting "Remote Authentication Dial In User Service (RADIUS)",
(AAA) Transport Profile", RFC 3539, June 2003. RFC 2865, June 2000.
[RFC5077] [RFC3539] Aboba, B. and J. Wood, "Authentication, Authorization and
Salowey, J, et al., "Transport Layer Security (TLS) Session Accounting (AAA) Transport Profile", RFC 3539, June 2003.
Resumption without Server-Side State", RFC 5077, January 2008
[RFC5080] [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig,
Nelson, D. and DeKok, A, "Common Remote Authentication Dial In User "Transport Layer Security (TLS) Session Resumption
Service (RADIUS) Implementation Issues and Suggested Fixes", RFC without Server-Side State", RFC 5077, January 2008.
5080, December 2007.
[RFC5246] [RFC5080] Nelson, D. and A. DeKok, "Common Remote Authentication
Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Dial In User Service (RADIUS) Implementation Issues and
Protocol Version 1.2", RFC 5246, August 2008. Suggested Fixes", RFC 5080, December 2007.
[RFC5997] [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
DeKok, A., "Use of Status-Server Packets in the Remote (TLS) Protocol Version 1.2", RFC 5246, August 2008.
Authentication Dial In User Service (RADIUS) Protocol", RFC 5997,
August 2010.
[RFC6347] [RFC5997] DeKok, A., "Use of Status-Server Packets in the Remote
Rescorla E., and Modadugu, N., "Datagram Transport Layer Security", Authentication Dial In User Service (RADIUS) Protocol",
RFC 6347, April 2006. RFC 5997, August 2010.
[RFC6520] [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Seggelmann, R., et al.,"Transport Layer Security (TLS) and Datagram Security Version 1.2", RFC 6347, January 2012.
Transport Layer Security (DTLS) Heartbeat Extension", RFC 6520,
February 2012.
[RFC6613] [RFC6520] Seggelmann, R., Tuexen, M., and M. Williams, "Transport
DeKok, A., "RADIUS over TCP", RFFC 6613, May 2012 Layer Security (TLS) and Datagram Transport Layer
Security (DTLS) Heartbeat Extension", RFC 6520, February
2012.
[RFC6614] [RFC6613] DeKok, A., "RADIUS over TCP", RFC 6613, May 2012.
Winter. S, et. al., "TLS encryption for RADIUS over TCP", RFFC
6614, May 2012
11.2. Informative references [RFC6614] Winter, S., McCauley, M., Venaas, S., and K. Wierenga,
"Transport Layer Security (TLS) Encryption for RADIUS",
RFC 6614, May 2012.
[RFC1321] 11.2. Informative References
Rivest, R. and S. Dusse, "The MD5 Message-Digest Algorithm", RFC
1321, April 1992.
[RFC2119] [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
Bradner, S., "Key words for use in RFCs to Indicate Requirement April 1992.
Levels", RFC 2119, March, 1997.
[RFC2866] [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
[RFC4107] [RFC4107] Bellovin, S. and R. Housley, "Guidelines for
Bellovin, S. and R. Housley, "Guidelines for Cryptographic Key Cryptographic Key Management", BCP 107, RFC 4107, June
Management", BCP 107, RFC 4107, June 2005. 2005.
[RFC5176] [RFC5176] Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B.
Chiba, M. et al., "Dynamic Authorization Extensions to Remote Aboba, "Dynamic Authorization Extensions to Remote
Authentication Dial In User Service (RADIUS)", RFC 5176, January Authentication Dial In User Service (RADIUS)", RFC 5176,
2008. January 2008.
[RFC6421] [RFC6421] Nelson, D., Ed., "Crypto-Agility Requirements for Remote
Nelson, D. (Ed), "Crypto-Agility Requirements for Remote Authentication Dial-In User Service (RADIUS)", RFC 6421,
Authentication Dial-In User Service (RADIUS)", RFC 6421, November November 2011.
2011.
[RFC6982] [RFC6982] Sheffer, Y. and A. Farrel, "Improving Awareness of
Sheffer, Y. and A. Farrel, "Improving Awareness of Running Code: Running Code: The Implementation Status Section", RFC
The Implementation Status Section", RFC 6982, July 2013. 6982, July 2013.
[MD5Attack] [MD5Attack] Dobbertin, H., "The Status of MD5 After a Recent Attack",
Dobbertin, H., "The Status of MD5 After a Recent Attack", CryptoBytes Vol.2 No.2, Summer 1996.
CryptoBytes Vol.2 No.2, Summer 1996.
[MD5Break] [MD5Break] Wang, X. and H. Yu, "How to Break MD5 and Other Hash
Wang, Xiaoyun and Yu, Hongbo, "How to Break MD5 and Other Hash Functions", EUROCRYPT '05 Proceedings of the 24th annual
Functions", EUROCRYPT. ISBN 3-540-25910-4, 2005. international conference on Theory and Applications of
Cryptographic Techniques, pp. 19-35, ISBN 3-540-25910-4,
2005.
Acknowledgments Acknowledgments
Parts of the text in Section 3 defining the Request and Response Parts of the text in Section 3 defining the Request and Response
Authenticators were taken with minor edits from [RFC2865] Section 3. Authenticators were taken with minor edits from [RFC2865], Section 3.
Authors' Addresses Author's Address
Alan DeKok Alan DeKok
The FreeRADIUS Server Project The FreeRADIUS Server Project
http://freeradius.org URI: http://freeradius.org
EMail: aland@freeradius.org
Email: aland@freeradius.org
 End of changes. 161 change blocks. 
405 lines changed or deleted 393 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/