draft-ietf-radext-dtls-07.txt   draft-ietf-radext-dtls-08.txt 
Network Working Group Alan DeKok Network Working Group Alan DeKok
INTERNET-DRAFT FreeRADIUS INTERNET-DRAFT FreeRADIUS
Category: Experimental Category: Experimental
<draft-ietf-radext-dtls-07.txt> <draft-ietf-radext-dtls-08.txt>
Expires: October 09, 2014 Expires: September 24, 2014
9 October 2013 24 January 2014
DTLS as a Transport Layer for RADIUS DTLS as a Transport Layer for RADIUS
draft-ietf-radext-dtls-07 draft-ietf-radext-dtls-08
Abstract Abstract
The RADIUS protocol [RFC2865] has limited support for authentication The RADIUS protocol defined in RFC 2865 has limited support for
and encryption of RADIUS packets. The protocol transports data "in authentication and encryption of RADIUS packets. The protocol
the clear", although some parts of the packets can have "obfuscated" transports data in the clear, although some parts of the packets can
content. Packets may be replayed verbatim by an attacker, and have obfuscated content. Packets may be replayed verbatim by an
client-server authentication is based on fixed shared secrets. This attacker, and client-server authentication is based on fixed shared
document specifies how the Datagram Transport Layer Security (DTLS) secrets. This document specifies how the Datagram Transport Layer
protocol may be used as a fix for these problems. It also describes Security (DTLS) protocol may be used as a fix for these problems. It
how implementations of this proposal can co-exist with current RADIUS also describes how implementations of this proposal can co-exist with
systems. current RADIUS systems.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 46 skipping to change at page 1, line 46
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 12, 2014 This Internet-Draft will expire on September 24, 2014
Copyright Notice Copyright Notice
Copyright (c) 2013 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 ......................................... 4
1.2. Requirements Language ............................... 5 1.2. Requirements Language ............................... 5
1.3. Document Status ..................................... 5
2. Building on Existing Foundations ......................... 6 2. Building on Existing Foundations ......................... 6
2.1. Changes to RADIUS ................................... 6 2.1. Changes to RADIUS ................................... 6
2.2. Similarities with RADIUS/TLS ........................ 7 2.2. Similarities with RADIUS/TLS ........................ 7
2.2.1. Changes from RADIUS/TLS to RADIUS/DTLS ......... 7 2.2.1. Changes from RADIUS/TLS to RADIUS/DTLS ......... 7
2.2.2. Reinforcement of RADIUS/TLS .................... 8
3. Interaction with RADIUS/UDP .............................. 8 3. Interaction with RADIUS/UDP .............................. 8
3.1. DTLS Port and Packet Types .......................... 9 3.1. DTLS Port and Packet Types .......................... 9
3.2. Server Behavior ..................................... 9 3.2. Server Behavior ..................................... 9
4. Client Behavior .......................................... 10 4. Client Behavior .......................................... 10
5. Connection Management .................................... 10 5. Session Management ....................................... 10
5.1. Server Connection Management ........................ 10 5.1. Server Session Management ........................... 11
5.1.1. Session Management ............................. 11 5.1.1. Session Opening and Closing .................... 11
5.2. Client Connection Management ........................ 13 5.2. Client Session Management ........................... 13
6. Implementation Guidelines ................................ 14 6. Implementation Guidelines ................................ 14
6.1. Client Implementations .............................. 14 6.1. Client Implementations .............................. 15
6.2. Server Implementations .............................. 15 6.2. Server Implementations .............................. 16
7. Implementation Experience ................................ 15 7. Implementation Experience ................................ 16
8. Diameter Considerations .................................. 16 8. Diameter Considerations .................................. 16
9. IANA Considerations ...................................... 16 9. IANA Considerations ...................................... 17
10. Security Considerations ................................. 16 10. Security Considerations ................................. 17
10.1. Legacy RADIUS Security ............................. 17 10.1. Legacy RADIUS Security ............................. 18
10.2. Resource Exhaustion ................................ 18 10.2. Resource Exhaustion ................................ 18
10.3. Client-Server Authentication with DTLS ............. 18 10.3. Client-Server Authentication with DTLS ............. 19
10.4. Network Address Translation ........................ 20 10.4. Network Address Translation ........................ 20
10.5. Wildcard Clients ................................... 20 10.5. Wildcard Clients ................................... 21
10.6. Session Closing .................................... 20 10.6. Session Closing .................................... 21
10.7. Clients Subsystems ................................. 21 10.7. Client Subsystems .................................. 21
11. References .............................................. 21 11. References .............................................. 22
11.1. Normative references ............................... 21 11.1. Normative references ............................... 22
11.2. Informative references ............................. 22 11.2. Informative references ............................. 23
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.
skipping to change at page 4, line 29 skipping to change at page 4, line 29
is implicit in the network configuration, and is not enforced by the is implicit in the network configuration, and is not enforced by the
RADIUS application. RADIUS 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 User
Datagram Protocol (UDP) based protocol. This continuity ensures that Datagram Protocol (UDP) based protocol. The change from RADIUS/UDP
existing network-layer infrastructure (firewall rules, etc.) does not is largely only to add TLS support. This allows implementations to
need to be changed when RADIUS clients and servers are upgraded to remain UDP based, without changing to a TCP architecture.
support RADIUS over DTLS. It is RECOMMENDED that firewalls
performing packet inspection be configured to permit only DTLS over
the RADIUS/DTLS port. The alternative could be for then to either
block RADIUS/DTLS, or allow another, non-standard protocol.
This specification does not, however, solve all of the problems This specification does not, however, solve all of the problems
associated with RADIUS. The DTLS protocol does not add reliable or associated with RADIUS. The DTLS protocol does not add reliable or
in-order transport to RADIUS. DTLS also does not support 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. RADIUS the issues of order, reliability, and fragmentation. These
issues are dealt with in RADIUS/TCP [RFC6613] and RADIUS/TLS
[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 short-hand 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],
skipping to change at page 6, line 5 skipping to change at page 5, line 28
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", "MAY", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
and "OPTIONAL" in this document are to be interpreted as described in and "OPTIONAL" in this document are to be interpreted as described in
[RFC2119]. [RFC2119].
1.3. Document Status
This document is an Experimental RFC. Please see [RFC6614] Section
1.3 for a discussion of the issues surrounding the use of TLS with
RADIUS.
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
skipping to change at page 6, line 44 skipping to change at page 6, line 44
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 encapsulated RADIUS packets of 4096 in length, with a MUST support sending and receiving encapsulated RADIUS packets of
corresponding increase in the maximum size of the encapsulated DTLS 4096 octets in length, with a corresponding increase in the maximum
packets. This larger packet size may cause the packet to be larger size of the encapsulated DTLS packets. This larger packet size may
than the Path MTU (PMTU), where a RADIUS/UDP packet may be smaller. cause the packet to be larger than the Path MTU (PMTU), where a
See Section 5.2, below, for more discussion. RADIUS/UDP packet may be smaller. See Section 5.2, below, for more
discussion.
The only changes made from RADIUS/UDP to RADIUS/DTLS are the 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. length. They MUST treat any decrypted DTLS data octets outside
the range of the Length field as padding, and ignore it on
reception.
(2) The shared secret secret used to compute the MD5 integrity (2) The shared secret secret used to compute the MD5 integrity
checks and the attribute encryption MUST be "radius/dtls". checks and 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
skipping to change at page 8, line 8 skipping to change at page 8, line 10
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 does not apply to RADIUS/DTLS. Item (3)
applies to RADIUS/DTLS. Item (4) applies, except that the fixed 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 TLS 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"
skipping to change at page 8, line 30 skipping to change at page 8, line 32
the requirements of [RFC2865] Section 3 for the RADIUS Length field, the requirements of [RFC2865] Section 3 for the RADIUS Length field,
using the length of the decrypted DTLS data for the checks. This using the length of the decrypted DTLS data for the checks. This
check replaces the RADIUS method of using the length field from the check replaces the RADIUS method of using the length field from the
UDP packet. 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.
2.2.2. Reinforcement of RADIUS/TLS Section 6 applies to RADIUS/DTLS.
We re-iterate that much of [RFC6614] applies to this document.
Specifically, Section 4 and Section 6 of that document are applicable
to RADIUS/DTLS.
3. 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 which 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. That sufficient to just disable RADIUS/UDP and enable RADIUS/DTLS. RADIUS
approach would result in timeouts, lost traffic, and network has no provisions for protocol negotiation, so simply disabling
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, long-term use of RADIUS/UDP is NOT RECOMMENDED. However, long-term use of RADIUS/UDP is not recommended.
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 Section 2.2.1 describes issues surrounding the use of text above in [RFC6614] Section 3.4 describes issues surrounding the
one port for multiple packet types, by referencing [RFC6614] Section use of one port for multiple packet types. We recognize that
3.4. implementations may allow the the use of RADIUS/DTLS over non-
standard ports. In that case, the references to UDP/2083 in this
document should be read as applying to any port used for transport of
RADIUS/DTLS traffic.
3.2. Server Behavior 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 drafts 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 which may change
skipping to change at page 10, line 13 skipping to change at page 10, line 13
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.
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. layer only when administratively configured. If a client is
configured to use DTLS and the server appears to be unresponsive, the
client MUST NOT fall back to using RADIUS/UDP. Instead, the client
should treat the server as being down.
RADIUS clients often had multiple independent RADIUS implementations, RADIUS clients often had multiple independent RADIUS implementations
or processes that originate packets. This practice was simple to and/or processes that originate packets. This practice was simple to
implement, but means that each independent subsystem must implement, but the result is that each independent subsystem must
independently discover network issues or server failures. It is independently discover network issues or server failures. It is
therefore RECOMMENDED that clients use a local proxy as described in therefore RECOMMENDED that clients use a local proxy as described in
Section 6.1, below. Section 6.1, below.
Clients may implement "pools" of servers for fail-over or load- Clients may implement "pools" of servers for fail-over or load-
balancing. These pools SHOULD NOT mix RADIUS/UDP and RADIUS/DTLS balancing. These pools SHOULD NOT mix RADIUS/UDP and RADIUS/DTLS
servers. servers.
5. Connection Management 5. Session Management
Where [RFC6614] can rely on the TCP state machine to perform Where [RFC6614] can rely on the TCP state machine to perform session
connection tracking, this specification cannot. As a result, tracking, this specification cannot. As a result, implementations of
implementations of this specification may need to perform connection this specification may need to perform session management of the DTLS
management of the DTLS session in the application layer. This session in the application layer. This section describes logically
section describes logically how this tracking is done. how this tracking is done. Implementations may choose to use the
Implementations may choose to use the method described here, or method described here, or another, equivalent method.
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 connection tracking described below can be seen detection cache. The session tracking described below can be seen as
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 Connection Management 5.1. Server Session Management
A RADIUS/DTLS server MUST track ongoing DTLS client connections based A RADIUS/DTLS server MUST track ongoing DTLS client session based the
the following 4-tuple: 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 entry associated with a 4-tuple contains the following Each 4-tuple points to a unique session entry, which contains the
information: following information:
DTLS Data DTLS Data
An implementation-specific variable containing information about An implementation-specific variable containing information about
the active DTLS connection. the active DTLS session.
Last Taffic Last Taffic
A variable containing a timestamp which indicates when this A variable containing a timestamp which indicates when this session
connection last received valid traffic. last received valid traffic.
Each entry may contain other information, such as idle timeouts, Each entry may contain other information, such as idle timeouts,
connection lifetimes, and other implementation-specific data. session lifetimes, and other implementation-specific data.
5.1.1. Session Management 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 a
ClientHello packet has been received with an appropriate Cookie 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 partially
setup DTLS connections. Servers SHOULD limit both the number and setup DTLS sessions. Servers SHOULD limit both the number and impact
impact on resources of partial connections. 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 ([RFC5246]
Section 7.2.2) is received. When a session is deleted due to it Section 7.2.2) is received. When a session is deleted due to it
failing security requirements, the DTLS session MUST be closed, and failing security requirements, the DTLS session MUST be closed, and
any TLS session resumption parameters for that session MUST be any TLS session resumption parameters for that session MUST be
discarded, and all tracking information MUST be deleted. 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 NAS which is not
implementing RADIUS. implementing RADIUS.
The above paragraph can be rephrased more generically. A session The above paragraph can be rephrased more generically. A session
MUST be deleted when non-RADIUS traffic is received over it. This MUST be deleted when non-RADIUS traffic is received over it. This
specification is for RADIUS, and there is no reason to allow non- specification is for RADIUS, and there is no reason to allow non-
RADIUS traffic over a RADIUS/DTLS connection. A session MUST be RADIUS traffic over a RADIUS/DTLS session. A session MUST be deleted
deleted when RADIUS traffic fails to pass security checks. There is when RADIUS traffic fails to pass security checks. There is no
no reason to permit insecure networks. A session SHOULD NOT be reason to permit insecure networks. A session SHOULD NOT be deleted
deleted when a well-formed, but "unexpected" RADIUS packet is when a well-formed, but "unexpected" RADIUS packet is received over
received over it. Future specifications may extend RADIUS/DTLS, and it. Future specifications may extend RADIUS/DTLS, and we do not want
we do not want to forbid those specifications. to forbid those specifications.
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 connection 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 which do not implement an application-layer watchdog MUST also
maintain a "Last Traffic" timestamp per DTLS session. The timestamp maintain a "Last Traffic" timestamp per DTLS session. The timestamp
SHOULD be updated on reception of a valid RADIUS/DTLS packet, or a SHOULD be updated on reception of a valid RADIUS/DTLS packet, or a
DTLS heartbeat. The timestamp MUST NOT be updated in other DTLS heartbeat. The timestamp MUST NOT be updated in other
situations. When a session has not received a packet for a period of situations. When a session has not received a packet for a period of
time, it is labelled "idle". The server SHOULD delete idle DTLS time, it is labelled "idle". The server SHOULD delete idle DTLS
sessions after an "idle timeout". The server MAY cache the TLS sessions after an "idle timeout". The server MAY cache the TLS
session parameters, in order to provide for fast session resumption. session parameters, in 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, and SHOULD NOT be set to more than 600 seconds (10 minutes). seconds, and SHOULD NOT be set to more than 600 seconds (10 minutes).
The minimum value useful value for this timer is determined by the The minimum value useful value for this timer is determined by the
application-layer watchdog mechanism defined in the following application-layer watchdog mechanism defined in the following
section. section.
RADIUS/DTLS servers SHOULD also monitor the total number of sessions RADIUS/DTLS servers SHOULD also monitor the total number of open
they are tracking. They SHOULD stop the creating of new sessions sessions. They SHOULD have a "maximum sessions" setting exposed to
when a large number are already being tracked. This "maximum administrators as a configurable parameter. When this maximum is
sessions" number SHOULD be exposed to administrators as a reached and a new session is started, the server MUST either drop an
configurable setting. old session in order to open the new one, or instead not create a new
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 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 notification from the client that the session is closed, or when the
the server has decided for itself that the session is closed. Taking server decides to close the session based on idle timeouts. Taking
any other action would permit unauthenticated clients to perform a any other action would permit unauthenticated clients to perform a
DoS attack, by closing active DTLS session. DoS attack, by re-using a 4-tuple, and thus causing the server to
close an active (and authenticated) DTLS session.
As a result, servers MUST ignore any attempts to re-use an existing As a result, servers MUST ignore any attempts to re-use 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 which it uses, and ensure that
re-use of 4-tuples is avoided. The exact process by which this re-use 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 Connection 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. Alternatively, RADIUS/DTLS clients may use the application- systems. RADIUS/DTLS clients SHOULD also use the application-layer
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 pro-actively 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 have 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.
A client may choose to avoid DTLS heartbeats and watchdog packets When client fails to implement both DTLS heartbeats and watchdog
entirely. However, DTLS provides no signal that a 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. There is therefore 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 RADIUS/DTLS clients For these reasons, it is RECOMMENDED that RADIUS/DTLS clients
implement DTLS heartbeats and/or watchdog packets for all DTLS implement DTLS heartbeats and/or watchdog packets for all DTLS
sessions. sessions.
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.
skipping to change at page 14, line 39 skipping to change at page 14, line 47
Where a TLS pre-shared key (PSK) method is used, implementations MUST Where a TLS pre-shared key (PSK) method is used, implementations MUST
support keys of at least 16 octets in length. Implementations SHOULD support keys of at least 16 octets in length. Implementations SHOULD
support key lengths of 32 octets, and SHOULD allow for longer keys. support key lengths of 32 octets, and SHOULD allow for longer keys.
The key data MUST be capable of being any value (0 through 255, The key data MUST be capable of being any value (0 through 255,
inclusive). Implementations MUST NOT limit themselves to using inclusive). Implementations MUST NOT limit themselves to using
textual keys. It is RECOMMENDED that the administration interface textual keys. It is RECOMMENDED that the administration interface
allows for the keys to be entered as humanly readable strings in hex allows for the keys to be entered as humanly readable strings in hex
format. format.
It is RECOMMENDED that keys be derived from a cryptographically When creating keys, it is RECOMMENDED that keys be derived from a
secure pseudo-random number generator (CSPRNG). If managing keys is cryptographically secure pseudo-random number generator (CSPRNG)
too complicated, a certificate-based TLS method SHOULD be used instead of allowing administrators to invent "secure" keys on theur
instead. own. If managing keys is too complicated, a certificate-based 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. It is a sessions, so that the client subsystem does not need to multiple
good idea to leverage existing functionality. multiple sessions on one socket.
RADIUS/DTLS clients SHOULD use one source when sending packets to a RADIUS/DTLS clients should use a single source (IP + port) when
particular RADIUS/DTLS server. Doing so minimizes the number of DTLS sending packets to a particular RADIUS/DTLS server. Doing so
session setups. It also ensures that information about the home minimizes the number of DTLS session setups. It also ensures that
server state is discovered only once. information about the home server state is discovered only once.
In practice, this means that RADIUS/DTLS clients SHOULD use a local In practice, this means that RADIUS/DTLS clients with multiple
proxy which arbitrates all RADIUS traffic between the client and all internal RADIUS sources should use a local proxy which arbitrates all
servers. The proxy SHOULD accept traffic only from the authorized RADIUS traffic between the client and all servers. The proxy should
subsystems on the client machine, and SHOULD proxy that traffic to accept traffic only from the authorized subsystems on the client
known servers. Each authorized subsystem SHOULD include an attribute machine, and should proxy that traffic to known servers. Each
which uniquely identifies that subsystem to the proxy, so that the authorized subsystem should include an attribute which uniquely
proxy can apply origin-specific proxy rules and security policies. identifies that subsystem to the proxy, so that the proxy can apply
We suggest using NAS-Identifier for this purpose. origin-specific proxy rules and security policies. We suggest using
NAS-Identifier for this purpose.
The local proxy SHOULD be able to interact with multiple servers at The 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
process which discovers network and/or connectivity issues with a
server. If each client subsystem communicated directly with a
server, issues with that server would have to be discovered
independently by each subsystem. The side effect would be increased
delays in re-routing traffic, error reporting, and network
instabilities.
Each client subsystem can include a subsystem-specific NAS-Identifier 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 re-write any subsystem-specific NAS-Identifier to a NAS-
Identifier which identifies the client as a whole. Or, remove NAS- Identifier which identifies the client as a whole. Or, remove 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 the 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 is because a connected
UDP socket will accept packets only from one source IP address and UDP socket will accept packets only from one source IP address and
port. This limitation would prevent the server from accepting port. This limitation would prevent the server from accepting
packets from multiple clients on the same port. packets from multiple clients on the same port.
7. Implementation Experience 7. Implementation Experience
Two implementations of RADIUS/DTLS exist, Radsecproxy, and jradius Two implementations of RADIUS/DTLS exist, Radsecproxy, and jradius
(http://www.coova.org/JRadius). Some experimental tests have been (http://www.coova.org/JRadius). Some experimental tests have been
performed, but there are at this time no production implementations performed, but there are at this time no production implementations
skipping to change at page 17, line 7 skipping to change at page 17, line 27
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
RADIUS/TLS specifications. As a result, all security considerations RADIUS/TLS specifications. As a result, all security considerations
for DTLS apply to the DTLS portion of RADIUS/DTLS. Similarly, the for DTLS apply to the DTLS portion of RADIUS/DTLS. Similarly, the
TLS and RADIUS security issues discussed in [RFC6614] also apply to TLS and RADIUS security issues discussed in [RFC6614] also apply to
this specification. All of the security considerations for RADIUS this specification. Most of the security considerations for RADIUS
apply to the RADIUS portion of the specification. apply to the RADIUS portion of the specification.
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 This specification also suggests that implementations use a session
connection tracking table. This table is an extension of the tracking table. This table is an extension of the duplicate
duplicate detection cache mandated in [RFC5080] Section 2.2.2. The detection cache mandated in [RFC5080] Section 2.2.2. The changes
changes given here are that DTLS-specific information is tracked for given here are that DTLS-specific information is tracked for each
each table entry. Section 5.1.1, above, describes steps to mitigate table entry. Section 5.1.1, above, describes steps to mitigate any
any DoS issues which result from tracking additional information. DoS issues which 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 acceptible
only when DTLS is used with an non-null encryption method. When a only when DTLS is used with an 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. an observer. Implementations therefore MUST NOT use null encryption
methods for RADIUS/DTLS.
For systems which perform protocol-based firewalling and/or
filtering, it is RECOMMENDED that they be configured to permit only
DTLS over the RADIUS/DTLS port.
10.1. Legacy RADIUS Security 10.1. 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.
It is RECOMMENDED that all RADIUS clients and servers implement this It is RECOMMENDED that all RADIUS clients and servers implement 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. be completely broken in the near future.
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
skipping to change at page 18, line 18 skipping to change at page 18, line 42
configuration which allows an administrator to configure all configuration which 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 CSPRNG, which makes above, recommends deriving TLS-PSK keys from a CSPRNG, which makes
dictionary attacks significantly more difficult. Servers SHOULD dictionary attacks significantly more difficult. Servers SHOULD
track failed client connections by TLS-PSK ID, and block TLS-PSK IDs track failed client connections by TLS-PSK ID, and block TLS-PSK IDs
which seem to be attempting brute-force searchs of the keyspace. which seem to be attempting brute-force searchs of the keyspace.
The historic RADIUS practice of using shared secrets that are minor The historic RADIUS practice of using shared secrets (here, PSKs)
variations of words is NOT RECOMMENDED, as it would negate all of the that are minor variations of words is NOT RECOMMENDED, as it would
security of DTLS. negate all of the security of DTLS.
10.2. Resource Exhaustion 10.2. 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 which were not possible in RADIUS/UDP. These attacks are the similar
to those described in [RFC6614] Section 6, for TCP. to 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. Servers MUST therefore 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
skipping to change at page 19, line 9 skipping to change at page 19, line 35
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.
When DTLS is used, the fixed IP address model can be relaxed. As When DTLS is used, the fixed IP address model can be relaxed. As
discussed earlier in Section 2.2.1, client identies should be discussed earlier in Section 2.2.1, client identies should be
determined from TLS parameters. Any authentication credentials for determined from TLS parameters. Any authentication credentials for
that client are then determined solely from the client identity, and that client are then determined solely from the client identity, and
not from an IP address. not from an IP address. See [RFC6614] Section 2.5 for a discussion
of how to 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 particular IP address range or ranges. They SHOULD silently from a particular 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 should also be statically credentials for that relationship should also be statically
configured. That is, a client connecting to a DTLS server SHOULD be configured. That is, a client connecting to a DTLS server SHOULD be
pre-configured with the servers credentials (e.g. PSK or pre-configured with the servers credentials (e.g. PSK or
certificate). If the server fails to present the correct certificate). If the server fails to present the correct
credentials, the DTLS session MUST be closed. credentials, the DTLS session MUST be closed.
The above requirement is best met by using a private Certificate The above requirement can be met by using a private Certificate
Authority (CA) for certificates used in RADIUS/DTLS environments. If Authority (CA) for certificates used in RADIUS/DTLS environments. If
a client were configured to use a public CA, then it could accept as a client were configured to use a public CA, then it could accept as
valid any server which has a certificate signed by that CA. The valid any server which has a certificate signed by that CA. While
traffic would be secure from third-party observers. The invalid the traffic would be secure from third-party observers, the server
server would, howrver, have unrestricted access to all of the RADIUS would, howrver, have unrestricted access to all of the RADIUS
traffic, including all user credentials and passwords. traffic, including all user 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. Instead, the clients SHOULD start off with an empty CA public CAs by the vendor or manufacturer. Instead, the clients
list. The addition of a CA SHOULD be done only when manually SHOULD start off with an empty CA list. The addition of a CA SHOULD
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 which 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
skipping to change at page 20, line 17 skipping to change at page 20, line 42
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. source IP address.
In addition, port re-use on a NAT gateway means that packets from In addition, port re-use on a NAT gateway means that packets from
different clients may appear to come from the same source port on the 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
a client IP/port combination, followed by the reception of a a client IP/port combination, followed by the reception of a
RADIUS/UDP packet from that same client IP/port combination. If this RADIUS/UDP packet from that same client IP/port combination. If this
behavior is allowed, it would permit a downgrade attack to occur, and behavior is allowed, then the client would have an inconsistent
would negate all of the security added by RADIUS/DTLS. security profile, allowing an attacker to choose the most insecure
method.
As a result, RADIUS clients SHOULD NOT be located behind a NAT As a result, RADIUS/UDP clients SHOULD NOT be located behind a NAT
gateway. If clients are located behind a NAT gateway, then a secure gateway. If clients are located behind a NAT gateway, then a secure
transport such as DTLS MUST be used. As discussed below, a method transport such as DTLS MUST be used. As discussed below, a method
for uniquely identifying each client MUST be used. for uniquely identifying each client MUST be used.
10.5. Wildcard Clients 10.5. 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 use the same shared secret. RADIUS/UDP, as it means multiple clients use the same shared 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.6. Session Closing 10.6. 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 connection 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 connection 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 connection to close. formed RADIUS packets which cause a DTLS session to close.
Therefore, in other situations, the session SHOULD remain open in the Therefore, in other situations, the session SHOULD remain open in the
face of non-conformant packets. face of non-conformant packets.
10.7. Clients Subsystems 10.7. 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
which arbitrates all RADIUS traffic between the client and all which arbitrates all RADIUS traffic between the client and all
servers. This proxy will encapsulate all knowledge about servers, servers. This proxy will encapsulate all knowledge about servers,
including security policies, fail-over, and load-balancing. All including security policies, fail-over, and load-balancing. All
client subsystems SHOULD communicate with this local proxy, ideally client subsystems SHOULD communicate with this local proxy, ideally
over a loopback address. The requirements on using strong shared over a loopback address. The requirements on using strong shared
secrets still apply. secrets 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 which arbitrates all RADIUS traffic. Subsystems which do not
implement DTLS can remain unaware of DTLS. DTLS connections opened implement DTLS can remain unaware of DTLS. DTLS sessions opened by
by the proxy can remain open for long periods of time, even when the proxy can remain open for long periods of time, even when client
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
skipping to change at page 22, line 28 skipping to change at page 23, line 6
[RFC6347] [RFC6347]
Rescorla E., and Modadugu, N., "Datagram Transport Layer Security", Rescorla E., and Modadugu, N., "Datagram Transport Layer Security",
RFC 6347, April 2006. RFC 6347, April 2006.
[RFC6520] [RFC6520]
Seggelmann, R., et al.,"Transport Layer Security (TLS) and Datagram Seggelmann, R., et al.,"Transport Layer Security (TLS) and Datagram
Transport Layer Security (DTLS) Heartbeat Extension", RFC 6520, Transport Layer Security (DTLS) Heartbeat Extension", RFC 6520,
February 2012. February 2012.
[RFC6613]
DeKok, A., "RADIUS over TCP", RFFC 6613, May 2012
[RFC6614] [RFC6614]
Winter. S, et. al., "TLS encryption for RADIUS over TCP", RFFC Winter. S, et. al., "TLS encryption for RADIUS over TCP", RFFC
6614, May 2012 6614, May 2012
11.2. Informative references 11.2. Informative references
[RFC1321] [RFC1321]
Rivest, R. and S. Dusse, "The MD5 Message-Digest Algorithm", RFC Rivest, R. and S. Dusse, "The MD5 Message-Digest Algorithm", RFC
1321, April 1992. 1321, April 1992.
 End of changes. 70 change blocks. 
159 lines changed or deleted 190 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/