draft-ietf-radext-dtls-05.txt   draft-ietf-radext-dtls-06.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-05.txt> <draft-ietf-radext-dtls-06.txt>
Expires: October 17, 2013 Expires: January 12, 2014
17 April 2013 12 July 2013
DTLS as a Transport Layer for RADIUS DTLS as a Transport Layer for RADIUS
draft-ietf-radext-dtls-05 draft-ietf-radext-dtls-06
Abstract Abstract
The RADIUS protocol [RFC2865] has limited support for authentication The RADIUS protocol [RFC2865] has limited support for authentication
and encryption of RADIUS packets. The protocol transports data "in and encryption of RADIUS packets. The protocol transports data "in
the clear", although some parts of the packets can have "obfuscated" the clear", although some parts of the packets can have "obfuscated"
content. Packets may be replayed verbatim by an attacker, and content. Packets may be replayed verbatim by an attacker, and
client-server authentication is based on fixed shared secrets. This client-server authentication is based on fixed shared secrets. This
document specifies how the Datagram Transport Layer Security (DTLS) document specifies how the Datagram Transport Layer Security (DTLS)
protocol may be used as a fix for these problems. It also describes protocol may be used as a fix for these problems. It also describes
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 July 28, 2013 This Internet-Draft will expire on January 12, 2014
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 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
skipping to change at page 3, line 15 skipping to change at page 3, line 15
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
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 2.2.2. Reinforcement of RADIUS/TLS .................... 8
3. Transition Path .......................................... 8 3. Interaction with RADIUS/UDP .............................. 8
3.1. DTLS Port and Packet Types .......................... 9 3.1. DTLS Port and Packet Types .......................... 9
3.2. Server Transition to DTLS ........................... 9 3.2. Server Behavior ..................................... 9
4. Client Transition ........................................ 10 4. Client Behavior .......................................... 10
5. Connection Management .................................... 12 5. Connection Management .................................... 10
5.1. Server Connection Management ........................ 12 5.1. Server Connection Management ........................ 11
5.1.1. Session Management ............................. 13 5.1.1. Session Management ............................. 11
5.1.2. Protocol Disambiguation ........................ 14 5.2. Client Connection Management ........................ 13
5.1.3. Processing Algorithm ........................... 15 6. Implementation Guidelines ................................ 14
5.2. Client Connection Management ........................ 17 6.1. Client Implementations .............................. 15
6. Implementation Guidelines ................................ 18 6.2. Server Implementations .............................. 15
6.1. Client Implementations .............................. 18 7. Implementation Experience ................................ 16
6.2. Server Implementations .............................. 19 8. Diameter Considerations .................................. 16
7. Implementation Experience ................................ 19 9. IANA Considerations ...................................... 16
8. Diameter Considerations .................................. 20 10. Security Considerations ................................. 17
9. IANA Considerations ...................................... 20 10.1. Legacy RADIUS Security ............................. 17
10. Security Considerations ................................. 20 10.2. Resource Exhaustion ................................ 18
10.1. Legacy RADIUS Security ............................. 21 10.3. Network Address Translation ........................ 19
10.2. Resource Exhaustion ................................ 22 10.4. Wildcard Clients ................................... 19
10.3. Network Address Translation ........................ 22 10.5. Session Closing .................................... 19
10.4. Wildcard Clients ................................... 23 10.6. Clients Subsystems ................................. 20
10.5. Session Closing .................................... 23 11. References .............................................. 20
10.6. Clients Subsystems ................................. 23 11.1. Normative references ............................... 20
11. References .............................................. 24 11.2. Informative references ............................. 21
11.1. Normative references ............................... 24
11.2. Informative references ............................. 25
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 6, line 31 skipping to change at page 6, line 31
* 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 Message-Authenticator. or Message-Authenticator.
* Calculation of "obfuscated" attributes such as User-Password * Calculation of "obfuscated" attributes such as User-Password
and Tunnel-Password. and Tunnel-Password.
* UDP port numbering and relationship between code and port
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.
skipping to change at page 7, line 40 skipping to change at page 7, line 39
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 where this specification is similar to
[RFC6614], and where it differs. [RFC6614], and where it differs.
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/TBD. 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. preconfigured 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 does not apply to RADIUS/DTLS. Item (3)
skipping to change at page 8, line 46 skipping to change at page 8, line 45
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 2.2.2. Reinforcement of RADIUS/TLS
We re-iterate that much of [RFC6614] applies to this document. We re-iterate that much of [RFC6614] applies to this document.
Specifically, Section 4 and Section 6 of that document are applicable Specifically, Section 4 and Section 6 of that document are applicable
to RADIUS/DTLS. to RADIUS/DTLS.
3. Transition Path 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. That
approach would result in timeouts, lost traffic, and network approach 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 transition to This section describes how clients and servers should use
DTLS. There is a fair amount of discussion around this transition, RADIUS/DTLS, and how it interacts with RADIUS/UDP.
as it is critical to get it correct. We expect that once
implementations have transitioned to RADIUS/DTLS, the text in this
section will no longer be relevant.
3.1. DTLS Port and Packet Types 3.1. DTLS Port and Packet Types
The default destination port number for RADIUS/DTLS is UDP/TBD There The default destination port number for RADIUS/DTLS is UDP/2083.
are no separate ports for authentication, accounting, and dynamic There are no separate ports for authentication, accounting, and
authorization changes. The source port is arbitrary. The text above dynamic authorization changes. The source port is arbitrary. The
in Section 2.2.1 describes issues surrounding the use of one port for text above in Section 2.2.1 describes issues surrounding the use of
multiple packet types, by referencing [RFC6614] Section 3.4. one port for multiple packet types, by referencing [RFC6614] Section
3.4.
3.2. Server Transition to DTLS
When a server receives packets on the assigned RADIUS/DTLS port, all
packets MUST be treated as being DTLS. RADIUS/UDP packets MUST NOT
be accepted on this port. The transition path described in this
section MUST NOT be used for that port.
Servers MAY accept DTLS packets on the old RADIUS/UDP ports. In that
case, we require a method to disambiguate packets between the two
protocols. This method is applicable only to RADIUS/DTLS servers.
The disambiguation method leverages the RADIUS/UDP requirement that
clients be known by source IP address. RADIUS/DTLS servers MUST
treat packets from unknown IP addresses as being DTLS. This
requirement does not mean that the server is required to accept these
packets. It means that if the server chooses to accept them, they
are to be treated as being DTLS.
For packets from known IP addresses RADIUS/DTLS servers MUST maintain 3.2. Server Behavior
a boolean "DTLS Required" flag for each client that indicates if it
requires a client to use RADIUS/DTLS. If the flag is "true" then all
packets from that client MUST be processed as RADIUS/DTLS.
The transition to RADIUS/DTLS is performed only when the "DTLS When a server receives packets on UDP/2083, all packets MUST be
Required" flag is "false". This setting means that the client is treated as being DTLS. RADIUS/UDP packets MUST NOT be accepted on
known to support RADIUS/UDP, but may also support RADIUS/DTLS. this port.
Packets from the client need to be examined to see if they are
RADIUS/UDP or RADIUS/DTLS. The protocol disambiguation method
outlined below in Section 5.1.2 MUST be used to determine how
received packets are treated.
The "DTLS Required" flag MUST be exposed to administrators of the Servers MUST NOT accept DTLS packets on the old RADIUS/UDP ports.
server. As clients are upgraded, administrators can then manually Early drafts of this specification permitted this behavior. It is
mark them as using RADIUS/DTLS. The default value for the flag forbidden here, as it depended on behavior in DTLS which may change
SHOULD be "false". DTLS configuration parameters (e.g. certificates, without notice.
pre-shared keys, etc.) SHOULD be exposed to the administrator, even
if the "DTLS Required" flag is set to "false". Adding these
parameters means that the client may use DTLS, though it is not
required.
It is RECOMMENDED that the default value for the "DTLS Required" flag As RADIUS has no provisions for capability signalling, there is no
be set to "true" when this specification has acheived wide-spread way for a RADIUS server to indicate to a client that it should
adoption. transition to using DTLS. This action has to be taken by the
administrators of the two systems, using a method other than RADIUS.
Once a RADIUS/DTLS server has established a DTLS session with a Some servers maintain a list of allowed clients per destination port.
client that previously had the flag set to "false", the server SHOULD Others maintain a global list of clients, which are permitted to send
set the "DTLS Required" flag to "true". This change suggests that packets to any port. Where a client can send packets to multiple
subsequent traffic from that client to use DTLS, and prevents ports, the server MUST maintain a "DTLS Required" flag per client.
bidding-down attacks. The server SHOULD also notify the
administrator that it has successfully established the first DTLS
session with that client.
The above requirement means that RADIUS/DTLS servers are subject to This flag indicates whether or not the client is required to use
downbidding attacks. A client can use DTLS for a period of time, and DTLS. When set, the flag indicates that the only traffic accepted
then subsequently revert to using UDP. This attack is permitted in from the client is over UDP/2083. When packets are received from a
order to allow an transition period from UDP to DTLS transport. It client on non-DTLS ports, for which DTLS is required, the server MUST
is RECOMMENDED that administators set the "DTLS Required" flag silently discard these packets, as there is no RADIUS/UDP shared
manually for each client after is has been seen to be using DTLS. secret available.
The above requirement is largely incompatible with the use of This flag will often be set by an administrator. However, if a
multiple RADIUS/UDP clients behind a Network Address Translation server receives DTLS traffic from a client, it SHOULD notify the
(NAT) gateway, as noted below in Section 10.3. administrator that DTLS is available for that client. It MAY mark
the client as "DTLS Required".
Note that this last requirement on servers can impose significant Allowing RADIUS/UDP and RADIUS/DTLS from the same client exposes the
changes for clients. These changes are discussed in the next traffic to downbidding attacks, and is NOT RECOMMENDED.
section.
4. Client Transition 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. The transition path described in this section MUST NOT be used port.
for packets sent to that port.
Servers MAY accept DTLS packets to the old RADIUS/UDP ports. In that
case, we require guidelines for when to use one or the other. This
method is applicable only to RADIUS/DTLS clients.
RADIUS/DTLS clients MUST maintain a boolean "DTLS Required" flag for
each server that indicates if that server requires it to use
RADIUS/DTLS. If the flag is "true" then the server supports
RADIUS/DTLS, and all packets sent to that server MUST be RADIUS/DTLS.
If the flag is "false", then the server supports RADIUS/UDP, but may
still support RADIUS/DTLS. Packets sent to that server MUST be
RADIUS/UDP.
The "DTLS Required" flag MUST be exposed to administrators of the
client. As servers are upgraded, administrators can then manually
mark them as using RADIUS/DTLS. The default value for the flag
SHOULD be "false". DTLS configuration parameters (e.g. certificates,
pre-shared keys, etc.) SHOULD be exposed to the administrator, even
if the "DTLS Required" flag is set to "false".
Adding DTLS configuration parameters means that the client MUST start
using DTLS to the server for all new requests. The client MUST,
however, accept RADIUS/UDP responses to any outstanding RADIUS/UDP
requests. It is RECOMMENDED that a client wait for all responses to
RADIUS/UDP requests before sending RADIUS/DTLS traffic to a
particular server. This suggestion means that the server sees a
"clean" transition from one protocol to another. Having the client
send a mix of RADIUS/UDP and RADIUS/DTLS traffic is problematic.
It is RECOMMENDED that the default value for the "DTLS Required" flag
be set to "true" when this specification has acheived wide-spread
adoption.
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. Doing so would cause servers to immediately require DTLS transport. Doing so could cause problems for servers which do
that all new packets from the client use DTLS. This requirement may not implement DTLS. Instead, clients SHOULD use DTLS as a transport
be difficult for a client to satisfy. Instead, clients SHOULD use layer only when administratively configured.
DTLS as a transport layer only when administratively configured.
The requirements of this specification mean that RADIUS/DTLS clients RADIUS clients often had multiple independent RADIUS implementations,
can no longer have multiple independent RADIUS implementations, or or processes that originate packets. This practice was simple to
processes that originate RADIUS/UDP and RADIUS/DTLS packets. implement, but means that each independent subsystem must
Instead, clients MUST use only one transport layer to communicate independently discover network issues or server failures. It is
with a specific server. It is RECOMMENDED that clients use a local therefore RECOMMENDED that clients use a local proxy as described in
proxy as described in Section 6.1, below. Section 6.1, below.
Clients may implement "pools" of servers for fail-over or load-
balancing. These pools SHOULD NOT mix RADIUS/UDP and RADIUS/DTLS
servers.
5. Connection Management 5. Connection Management
Where [RFC6614] can rely on the TCP state machine to perform Where [RFC6614] can rely on the TCP state machine to perform
connection tracking, this specification cannot. As a result, connection tracking, this specification cannot. As a result,
implementations of this specification may need to perform connection implementations of this specification may need to perform connection
management of the DTLS session in the application layer. This management of the DTLS session in the application layer. This
section describes logically how this tracking is done. section describes logically how this tracking is done.
Implementations may choose to use the method described here, or Implementations may choose to use the method described here, or
another, equivalent method. another, equivalent method.
skipping to change at page 12, line 25 skipping to change at page 11, line 4
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 connection tracking described below can be seen
as an extension of that cache, where entries contain DTLS sessions as 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 a retransmitted response create a new RADIUS/DTLS packet, every time it is necessary to
is sent. retransmit a RADIUS response.
5.1. Server Connection Management 5.1. Server Connection Management
A RADIUS/DTLS server MUST track ongoing client connections based on a A RADIUS/DTLS server MUST track ongoing DTLS client connections based
key composed of the following 4-tuple: on a key composed of 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 key is independent of IP address version (IPv4 or Note that this key is independent of IP address version (IPv4 or
IPv6). IPv6).
Each entry associated with a key contains the following information: Each entry associated with a key contains the following information:
Protocol Type
A flag which is either "RADIUS/UDP" for old-style RADIUS traffic,
or "RADIUS/DTLS" for RADIUS/DTLS connections.
DTLS Data DTLS Data
An implementation-specific variable containing information about An implementation-specific variable containing information about
the active DTLS connection. For non-DTLS connections, this the active DTLS connection.
variable MUST be empty.
Last Taffic Last Taffic
A variable containing a timestamp which indicates when this A variable containing a timestamp which indicates when this
connection last received valid traffic. connection 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. connection lifetimes, and other implementation-specific data.
5.1.1. Session Management 5.1.1. Session Management
skipping to change at page 14, line 35 skipping to change at page 13, line 8
they are tracking. They SHOULD stop the creating of new sessions they are tracking. They SHOULD stop the creating of new sessions
when a large number are already being tracked. This "maximum when a large number are already being tracked. This "maximum
sessions" number SHOULD be exposed to administrators as a sessions" number SHOULD be exposed to administrators as a
configurable setting. configurable setting.
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.
5.1.2. Protocol Disambiguation
When the "DTLS Required" flag for a client is set to "false", the
client may, or may not be sending DTLS packets. For existing
connections, protocol disambiguation is simple, the "Protocol Type"
field in the session tracking entry is examined. New connections
must still be disambiguated.
In order to provide a robust upgrade path, the RADIUS/DTLS server
MUST examine the packet to see if it is RADIUS/UDP or RADIUS/DTLS.
This examination method is defined here.
We justify the examination methods by analysing the packet formats
for the two protocols. We assume that the server has a buffer in
which it has received a UDP packet matching no entry based on the
4-tuple key defined above. It must then analyse this buffer to
determine which protocol is used to process the packet.
The DTLS record format ([RFC6347] Section 4.1) is shown below, in
pseudo-code:
struct {
uint8 type;
uint16 version;
uint16 epoch;
uint48 sequence_number;
uint16 length;
uint8 fragment[DTLSPlaintext.length];
} DTLSPlaintext;
The RADIUS record format ([RFC2865] Section 3) is shown below, in
pseudo-code, with AuthVector.length=16.
struct {
uint8 code;
uint8 id;
uint16 length;
uint8 vector[AuthVector.length];
uint8 data[RadiusPacket.length - 20];
} RadiusPacket;
We can see here that a number of fields overlap between the two
protocols. At first glance, it seems difficult for an application to
accept both protocols on the same port. However, this is not the
case.
The initial DTLS packet of a connection requires that the type field
(first octet) has value 22 (handshake). The first octet of a RADIUS
packet is the code field. The code value of 22 has been assigned as
Resource-Free-Response. That code is intended to be a response from
a server to a client, and will therefore never be sent by a client to
a server.
As a result, protocol disambiguation for new connections to a server
is straightforward. Only the first octet of the packet needs to be
examined to disambiguate RADIUS/DTLS from RADIUS/UDP. If that octet
has value 22, then the packet is likely to be RADIUS/DTLS.
Otherwise, the packet is likely to be RADIUS/UDP.
5.1.3. Processing Algorithm
When a RADIUS/DTLS server recieves a packet, it uses the following
algorithm to process that packet. As with RADIUS/UDP, packets from
unknown clients MUST be silently discarded.
The "DTLS Required" flag for that client is examined. If it is set
to "true", then the packet MUST be processed as RADIUS/DTLS.
If the "DTLS Required" flag is set to "false", the session is looked
up using the 4-tuple key defined above. Packets matching an existing
entry MUST be processed as defined by the "Protocol Type" field of
that entry.
If the "DTLS Required" flag is set to "false" and no matching entry
has been found, then the first octet of the packet is examined. If
it has value 22, then the packet MUST be processed as RADIUS/DTLS.
Otherwise, the packet MUST be processed as RADIUS/UDP.
In all cases, the packet MUST be checked for correctness. For
RADIUS/UDP, any packets which are silently discarded MUST NOT affect
the state of any variable in session tracking entry. For
RADIUS/DTLS, any packets which are discarded by the DTLS layer MUST
NOT affect the state of any variable in the session tracking entry.
When the packet matches an existing key, and is accepted for
processing by the server, it is processed via the method indicated in
that entry. Where the packet does not match an existing key, a new
entry is created for that key. The "Protocol Type" flag for that
entry is set to "RADIUS/DTLS", or "RADIUS/UDP", as determined by
examining the first octet of the packet.
When a server has the clients "DTLS Required" flag set to "false", it
MUST set the flag to "true" after establishing a DTLS session with
that client. It MUST NOT set the flag to "true" until a DTLS session
has been fully established. Doing so would mean that attackers could
perform a DoS attack by sending forged DTLS ClientHello packets to a
server.
Since UDP is stateless, the potential exists for the client to 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 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 server has decided for itself that the session is closed. Taking the server has decided for itself that the session is closed. 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 closing active 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
skipping to change at page 17, line 49 skipping to change at page 14, line 21
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 MUST NOT send both RADIUS/UDP and RADIUS/DTLS
packets over the same key of (source IP, source port, destination IP,
destination port) as defined in Section 4.1, above . Doing so would
make it impossible to correctly process either kind of packet.
RADIUS/DTLS clients SHOULD NOT send both RADIUS/UDP and RADIUS/DTLS 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 19, line 28 skipping to change at page 15, line 44
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, so that traditional RADIUS would order to communicate with a server, as RADIUS/UDP may not be
be ignored 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.
skipping to change at page 20, line 30 skipping to change at page 16, line 44
requirement is satisfied by leveraging DTLS. requirement is satisfied by leveraging DTLS.
8. Diameter Considerations 8. 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.
9. IANA Considerations 9. IANA Considerations
This specification allocates a new UDP port, called "RADIUS-DTLS". No new RADIUS attributes or packet codes are defined. IANA is
The references to "UDP/TBD" in this document need to be updated to requested to update the already-assigned UDP port number 2083 in the
use the allocated port number. following ways:
o Reference: list the RFC number of this document as the reference
o Assignment Notes: add the text "The UDP port 2083 was already
previously assigned by IANA for "RadSec", an early implementation
of RADIUS/TLS, prior to issuance of this RFC."
10. Security Considerations 10. Security Considerations
This entire specification is devoted to discussing security This entire 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
skipping to change at page 22, line 12 skipping to change at page 18, line 34
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 previous RADIUS practice of using shared secrets that are minor The historic RADIUS practice of using shared secrets that are minor
variations of words is NOT RECOMMENDED, as it would negate all of the variations of words is NOT RECOMMENDED, as it would negate all of the
security of DTLS. 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
skipping to change at page 22, line 41 skipping to change at page 19, line 16
limits SHOULD be exposed to the administrator as configurable limits SHOULD be exposed to the administrator as configurable
settings. settings.
10.3. Network Address Translation 10.3. 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. source IP address.
The migration flag described above in Section 3 is also tracked per
source IP address. Using a NAT in front of many RADIUS clients
negates the function of the flag, making it impossible to migrate
multiple clients in a secure fashion.
In addition, port re-use on a NAT gateway means that packets from 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, it would permit a downgrade attack to occur, and
would negate all of the security added by RADIUS/DTLS. would negate all of the security added by RADIUS/DTLS.
As a result, RADIUS clients SHOULD NOT be located behind a NAT As a result, RADIUS 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.4. Wildcard Clients 10.4. 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.
When a client is a "wildcard", then RADIUS/DTLS MUST be used. When a client is a "wildcard", RADIUS/DTLS MUST be used. Clients
Clients MUST be uniquely identified, and any certificate or PSK used MUST be uniquely identified, and any certificate or PSK used MUST be
MUST be unique to each client. unique to each client.
10.5. Session Closing 10.5. 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 various transported RADIUS packets are malformed, or fail various
authenticator checks. This requirement is due to security authenticator checks. This requirement is due to security
considerations. considerations.
When an implementation has a DTLS connection, it is expected that the When an implementation has a DTLS connection, it is expected that the
connection be used to transport RADIUS. Any non-RADIUS traffic on connection be used to transport RADIUS. Any non-RADIUS traffic on
 End of changes. 33 change blocks. 
274 lines changed or deleted 101 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/