draft-ietf-radext-dtls-04.txt   draft-ietf-radext-dtls-05.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-04.txt> <draft-ietf-radext-dtls-05.txt>
Expires: October 2, 2013 Expires: October 17, 2013
2 April 2013 17 April 2013
DTLS as a Transport Layer for RADIUS DTLS as a Transport Layer for RADIUS
draft-ietf-radext-dtls-04 draft-ietf-radext-dtls-05
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 3, line 16 skipping to change at page 3, line 16
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. Transition Path .......................................... 8
3.1. Server Transition to DTLS ........................... 8 3.1. DTLS Port and Packet Types .......................... 9
4. Client Transition ........................................ 9 3.2. Server Transition to DTLS ........................... 9
5. Connection Management .................................... 10 4. Client Transition ........................................ 10
5.1. Server Connection Management ........................ 11 5. Connection Management .................................... 12
5.1.1. Session Management ............................. 11 5.1. Server Connection Management ........................ 12
5.1.2. Protocol Disambiguation ........................ 13 5.1.1. Session Management ............................. 13
5.1.3. Processing Algorithm ........................... 14 5.1.2. Protocol Disambiguation ........................ 14
5.2. Client Connection Management ........................ 15 5.1.3. Processing Algorithm ........................... 15
6. Implementation Guidelines ................................ 16 5.2. Client Connection Management ........................ 17
6.1. Client Implementations .............................. 17 6. Implementation Guidelines ................................ 18
6.2. Server Implementations .............................. 17 6.1. Client Implementations .............................. 18
7. Implementation Experience ................................ 18 6.2. Server Implementations .............................. 19
8. Diameter Considerations .................................. 18 7. Implementation Experience ................................ 19
9. IANA Considerations ...................................... 18 8. Diameter Considerations .................................. 20
10. Security Considerations ................................. 18 9. IANA Considerations ...................................... 20
10.1. Legacy RADIUS Security ............................. 19 10. Security Considerations ................................. 20
10.2. Resource Exhaustion ................................ 20 10.1. Legacy RADIUS Security ............................. 21
10.3. Network Address Translation ........................ 20 10.2. Resource Exhaustion ................................ 22
10.4. Wildcard Clients ................................... 21 10.3. Network Address Translation ........................ 22
10.5. Session Closing .................................... 21 10.4. Wildcard Clients ................................... 23
10.6. Clients Subsystems ................................. 22 10.5. Session Closing .................................... 23
11. References .............................................. 22 10.6. Clients Subsystems ................................. 23
11.1. Normative references ............................... 22 11. References .............................................. 24
11.2. Informative references ............................. 23 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 45 skipping to change at page 6, line 45
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 DTLS packets totalling 4096 octets in length, with a MUST support encapsulated RADIUS packets of 4096 in length, with a
corrsponding decrease in the maximum size of the encapsulated corresponding increase in the maximum size of the encapsulated DTLS
packets. Implementations SHOULD support encapsulated RADIUS packets packets.
of 4096 in length, with a corresponding increase in the maximum size
of the encapsulated DTLS packets.
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.
(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".
skipping to change at page 7, line 41 skipping to change at page 7, line 39
Those changes are sufficient to cover the majority of the differences Those changes are sufficient to cover the majority of the differences
between the two specifications. The next section reviews some more between the two specifications. The next section reviews some more
detailed changes from [RFC6614], giving additional commentary only detailed changes from [RFC6614], giving additional commentary only
where necessary. where necessary.
2.2.1. Changes from RADIUS/TLS to RADIUS/DTLS 2.2.1. Changes from RADIUS/TLS to RADIUS/DTLS
This section describes where this specification is similar to This section describes where this specification is similar to
[RFC6614], and where it differs. [RFC6614], and where it differs.
Section 2.1 does not apply to RADIUS/DTLS. The relationship between Section 2.1 applies to RADIUS/DTLS, with the exception that the
RADIUS packet codes and UDP ports in RADIUS/DTLS is unchanged from RADIUS/DTLS port is UDP/TBD.
RADIUS/UDP.
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)
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 does not apply to RADIUS/DTLS. Section 2.4 applies to RADIUS/DTLS. Client identies can be
determined from TLS parameters, instead of relying solely on the
source IP address of the packet.
Section 2.5 does not apply to RADIUS/DTLS. The relationship between Section 2.5 does not apply to RADIUS/DTLS. The relationship between
RADIUS packet codes and UDP ports in RADIUS/DTLS is unchanged from RADIUS packet codes and UDP ports in RADIUS/DTLS is unchanged from
RADIUS/UDP. RADIUS/UDP.
Sections 3.1, 3.2, and 3.3 apply to RADIUS/DTLS. Sections 3.1, 3.2, and 3.3 apply to RADIUS/DTLS.
Section 3.4 item (1) does not apply to RADIUS/DTLS. Each RADIUS Section 3.4 item (1) does not apply to RADIUS/DTLS. Each RADIUS
packet is encapsulated in one DTLS packet, and there is no "stream" packet is encapsulated in one DTLS packet, and there is no "stream"
of RADIUS packets inside of a TLS session. Implementors MUST enforce of RADIUS packets inside of a TLS session. Implementors MUST enforce
the requirements of [RFC2865] Section 3 for the RADIUS Length field, the requirements of [RFC2865] Section 3 for the RADIUS Length 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 item (3) does not apply to RADIUS/DTLS. The relationship Section 3.4 item (3) applies to RADIUS/DTLS when the new port is
between RADIUS packet codes and UDP ports in RADIUS/DTLS is unchanged used. When DTLS is used over the existing RADIUS/UDP ports, the
from RADIUS. relationship between RADIUS packet codes and UDP ports in RADIUS/DTLS
is unchanged from RADIUS.
Section 3.4 item (4) does not apply to RADIUS/DTLS. As RADIUS/DTLS Section 3.4 item (4) applies to RADIUS/DTLS when the new port is
still uses UDP for a transport, the use of negative ICMP responses is used. When DTLS is used over the existing RADIUS/UDP ports, the use
unchanged from RADIUS. of negative ICMP responses is unchanged from RADIUS.
Section 3.4 item (5) applies to RADIUS/DTLS when the new port is
used. When DTLS is used over the existing RADIUS/UDP ports, the use
of negative ICMP responses is unchanged from RADIUS.
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
in their entirety to RADIUS/DTLS. to RADIUS/DTLS.
3. Transition Path 3. Transition Path
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. This section potentially subject to security downgrade attacks. It is not
describes how clients and servers should transition to DTLS. sufficient to just disable RADIUS/UDP and enable RADIUS/DTLS. That
approach would result in timeouts, lost traffic, and network
instabilities.
3.1. Server Transition to DTLS The end result of this specification is that nearly all RADIUS/UDP
implementations should transition to using a secure alternative. In
some cases, RADIUS/UDP may remain where IPSec is used as a transport,
or where implementation and/or business reasons preclude a change.
However, long-term use of RADIUS/UDP is NOT RECOMMENDED.
As this specification permits server implementations to accept both This section describes how clients and servers should transition to
RADIUS/UDP and RADIUS/DTLS packets on the same port, we require a DTLS. There is a fair amount of discussion around this transition,
method to disambiguate packets between the two protocols. This as it is critical to get it correct. We expect that once
method is applicable only to RADIUS/DTLS servers. implementations have transitioned to RADIUS/DTLS, the text in this
section will no longer be relevant.
RADIUS/DTLS servers MUST maintain a boolean "DTLS Required" flag for 3.1. DTLS Port and Packet Types
each client that indicates if it requires a client to use
RADIUS/DTLS. The interpretation of this flag is as follows. If the The default destination port number for RADIUS/DTLS is UDP/TBD There
flag is "true" then the client supports RADIUS/DTLS, and all packets are no separate ports for authentication, accounting, and dynamic
from that client MUST be processed as RADIUS/DTLS. If the flag is authorization changes. The source port is arbitrary. The text above
"false", then the client supports RADIUS/UDP, but may still support in Section 2.2.1 describes issues surrounding the use of one port for
RADIUS/DTLS. Packets from the client need to be examined to see if multiple packet types, by referencing [RFC6614] Section 3.4.
they are RADIUS/UDP or RADIUS/DTLS.
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
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
Required" flag is "false". This setting means that the client is
known to support RADIUS/UDP, but may also support RADIUS/DTLS.
Packets from the client need to be examined to see if they are
RADIUS/UDP or RADIUS/DTLS. The protocol disambiguation method
outlined below in Section 5.1.2 MUST be used to determine how
received packets are treated.
The "DTLS Required" flag MUST be exposed to administrators of the The "DTLS Required" flag MUST be exposed to administrators of the
server. As clients are upgraded, administrators can then manually server. As clients are upgraded, administrators can then manually
mark them as using RADIUS/DTLS. The default value for the flag mark them as using RADIUS/DTLS. The default value for the flag
SHOULD be "false". DTLS configuration parameters (e.g. certificates, SHOULD be "false". DTLS configuration parameters (e.g. certificates,
pre-shared keys, etc.) SHOULD be exposed to the administrator, even pre-shared keys, etc.) SHOULD be exposed to the administrator, even
if the "DTLS Required" flag is set to "false". Adding these if the "DTLS Required" flag is set to "false". Adding these
parameters means that the client may use DTLS, though it is not parameters means that the client may use DTLS, though it is not
required. required.
It is RECOMMENDED that the default value for the "DTLS Required" flag It is RECOMMENDED that the default value for the "DTLS Required" flag
be set to "true" when this specification has acheived wide-spread be set to "true" when this specification has acheived wide-spread
adoption. adoption.
Once a RADIUS/DTLS server has established a DTLS session with a Once a RADIUS/DTLS server has established a DTLS session with a
client that previously had the flag set to "false", the server MUST client that previously had the flag set to "false", the server SHOULD
set the "DTLS Required" flag to "true". This change requires all set the "DTLS Required" flag to "true". This change suggests that
subsequent traffic from that client to use DTLS, and prevents subsequent traffic from that client to use DTLS, and prevents
bidding-down attacks. The server SHOULD also notify the bidding-down attacks. The server SHOULD also notify the
administrator that it has successfully established the first DTLS administrator that it has successfully established the first DTLS
session with that client. session with that client.
The above requirement means that RADIUS/DTLS servers are subject to
downbidding attacks. A client can use DTLS for a period of time, and
then subsequently revert to using UDP. This attack is permitted in
order to allow an transition period from UDP to DTLS transport. It
is RECOMMENDED that administators set the "DTLS Required" flag
manually for each client after is has been seen to be using DTLS.
The above requirement is largely incompatible with the use of
multiple RADIUS/UDP clients behind a Network Address Translation
(NAT) gateway, as noted below in Section 10.3.
Note that this last requirement on servers can impose significant Note that this last requirement on servers can impose significant
changes for clients. These changes are discussed in the next changes for clients. These changes are discussed in the next
section. section.
4. Client Transition 4. Client Transition
As this specification permits client implementations to to send both When a client sends packets to the assigned RADIUS/DTLS port, all
RADIUS/UDP and RADIUS/DTLS packets from the same address, we require packets MUST be DTLS. RADIUS/UDP packets MUST NOT be sent to this
guidelines for when to use one or the other. This method is port. The transition path described in this section MUST NOT be used
applicable only to RADIUS/DTLS clients. 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 RADIUS/DTLS clients MUST maintain a boolean "DTLS Required" flag for
each server that indicates if that server requires it to use each server that indicates if that server requires it to use
RADIUS/DTLS. The interpretation of this flag is as follows. If the RADIUS/DTLS. If the flag is "true" then the server supports
flag is "true" then the server supports RADIUS/DTLS, and all packets RADIUS/DTLS, and all packets sent to that server MUST be RADIUS/DTLS.
sent to that server MUST be RADIUS/DTLS. If the flag is "false", If the flag is "false", then the server supports RADIUS/UDP, but may
then the server supports RADIUS/UDP, but may still support still support RADIUS/DTLS. Packets sent to that server MUST be
RADIUS/DTLS. Packets sent to that server MUST be RADIUS/UDP. RADIUS/UDP.
The "DTLS Required" flag MUST be exposed to administrators of the The "DTLS Required" flag MUST be exposed to administrators of the
client. As servers are upgraded, administrators can then manually client. As servers are upgraded, administrators can then manually
mark them as using RADIUS/DTLS. The default value for the flag mark them as using RADIUS/DTLS. The default value for the flag
SHOULD be "false". DTLS configuration parameters (e.g. certificates, SHOULD be "false". DTLS configuration parameters (e.g. certificates,
pre-shared keys, etc.) SHOULD be exposed to the administrator, even pre-shared keys, etc.) SHOULD be exposed to the administrator, even
if the "DTLS Required" flag is set to "false". Adding these if the "DTLS Required" flag is set to "false".
parameters means that the client MUST start using DTLS to the server
for all new requests. The client MUST, however, accept RADIUS/UDP Adding DTLS configuration parameters means that the client MUST start
responses to any outstanding requests. 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 It is RECOMMENDED that the default value for the "DTLS Required" flag
be set to "true" when this specification has acheived wide-spread be set to "true" when this specification has acheived wide-spread
adoption. 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 would cause servers to immediately require
that all new packets from the client use DTLS. This requirement may that all new packets from the client use DTLS. This requirement may
be difficult for a client to satisfy. Instead, clients SHOULD use be difficult for a client to satisfy. Instead, clients SHOULD use
DTLS as a transport layer only when administratively configured. DTLS as a transport layer only when administratively configured.
skipping to change at page 11, line 5 skipping to change at page 12, line 20
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.
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
result in the retransmission of a previously cached RADIUS/UDP
response. Due to DTLS sequence window requirements, a server MUST
NOT retransmit a previously sent DTLS packet. Instead, it should
cache the RADIUS response packet, and re-process it through DTLS to
create a new RADIUS/DTLS packet, every time a retransmitted response
is sent.
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 client connections based on a
key composed of the following 4-tuple: 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
skipping to change at page 11, line 29 skipping to change at page 13, line 5
Protocol Type Protocol Type
A flag which is either "RADIUS/UDP" for old-style RADIUS traffic, A flag which is either "RADIUS/UDP" for old-style RADIUS traffic,
or "RADIUS/DTLS" for RADIUS/DTLS connections. 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. For non-DTLS connections, this
variable MUST be empty. variable MUST be empty.
Last Packet Last Taffic
A variable containing a timestamp which indicates when the last A variable containing a timestamp which indicates when this
valid packet was received for this connection. Packets which are connection last received valid traffic.
"silently discarded" MUST NOT update this variable.
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
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. The requirement to accept RADIUS/UDP and RADIUS/DTLS on the value. The requirement to accept RADIUS/UDP and RADIUS/DTLS on the
same port makes this recommendation difficult to implement in same port makes this recommendation difficult to implement in
practice. Server implementation SHOULD therefore have a way of practice. Server implementation SHOULD therefore have a way of
tracking partially setup DTLS connections. Servers SHOULD limit both tracking partially setup DTLS connections. Servers SHOULD limit both
the number and impact on resources of partial connections. the number and impact on resources of partial connections.
Sessions (both key and entry) MUST deleted when a TLS Closure Alert Sessions (both key and entry) MUST deleted when a TLS Closure Alert
([RFC5246] Section 7.2.1) or a TLS Error Alert ([RFC5246] Section ([RFC5246] Section 7.2.1) or a fatal TLS Error Alert ([RFC5246]
7.2.2) is received. When a session is deleted due to failed Section 7.2.2) is received. When a session is deleted due to failed
security, the DTLS session MUST be closed, and any TLS session security, the DTLS session MUST be closed, and any TLS session
resumption parameters for that session MUST be discarded, and all resumption parameters for that session MUST be discarded, and all
tracking information MUST be deleted. 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.
skipping to change at page 12, line 29 skipping to change at page 14, line 4
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 connection. A session MUST be
deleted when RADIUS traffic fails to pass security checks. There is deleted when RADIUS traffic fails to pass security checks. There is
no reason to permit insecure networks. A session SHOULD NOT be no reason to permit insecure networks. A session SHOULD NOT be
deleted when a well-formed, but "unexpected" RADIUS packet is deleted when a well-formed, but "unexpected" RADIUS packet is
received over it. Future specifications may extend RADIUS/DTLS, and received over it. Future specifications may extend RADIUS/DTLS, and
we do not want to forbid those specifications. we do not want to forbid those specifications.
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 may also use watchdog packets from the client to servers. A server SHOULD also use watchdog packets from the client
determine that the connection is still active. to determine that the connection 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
MUST also maintain a "Last Packet" timestamp per DTLS session. The which do not implement an application-layer watchdog MUST also
timestamp SHOULD be updated on reception of a valid RADIUS/DTLS maintain a "Last Traffic" timestamp per DTLS session. The timestamp
packet. The timestamp MUST NOT be updated in other situations. When SHOULD be updated on reception of a valid RADIUS/DTLS packet, or a
a session has not received a packet for a period of time, it is DTLS heartbeat. The timestamp MUST NOT be updated in other
labelled "idle". The server SHOULD delete idle DTLS sessions after situations. When a session has not received a packet for a period of
an "idle timeout". The server MAY cache the TLS session parameters, time, it is labelled "idle". The server SHOULD delete idle DTLS
in order to provide for fast session resumption. sessions after an "idle timeout". The server MAY cache the TLS
session parameters, in order to provide for fast session resumption.
This session "idle timeout" SHOULD be exposed to the administrator as 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 sessions
they are tracking. They SHOULD stop the creating of new sessions they are tracking. They SHOULD stop the creating of new sessions
skipping to change at page 14, line 47 skipping to change at page 16, line 21
If the "DTLS Required" flag is set to "false" and no matching 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 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. it has value 22, then the packet MUST be processed as RADIUS/DTLS.
Otherwise, the packet MUST be processed as RADIUS/UDP. Otherwise, the packet MUST be processed as RADIUS/UDP.
In all cases, the packet MUST be checked for correctness. For In all cases, the packet MUST be checked for correctness. For
RADIUS/UDP, any packets which are silently discarded MUST NOT affect RADIUS/UDP, any packets which are silently discarded MUST NOT affect
the state of any variable in session tracking entry. For the state of any variable in session tracking entry. For
RADIUS/DTLS, any packets which are discarded by the DTLS layer MUST RADIUS/DTLS, any packets which are discarded by the DTLS layer MUST
NOT affect the state of any variable in the session tracking entry. NOT affect the state of any variable in the session tracking entry.
For RADIUS/DTLS, any RADIUS packets which are subsequently silently
discarded MUST result in the removal of the associated entry and key.
When the packet matches an existing key, and is accepted for When the packet matches an existing key, and is accepted for
processing by the server, the "Last Packet" timestamp is updated in 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 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 created for that key. The "Protocol Type" flag for that
entry is set to "RADIUS/DTLS", or "RADIUS/UDP", as determined by entry is set to "RADIUS/DTLS", or "RADIUS/UDP", as determined by
examining the first octet of the packet. examining the first octet of the packet.
When a server has the clients "DTLS Required" flag set to "false", it 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 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 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 has been fully established. Doing so would mean that attackers could
perform a DoS attack by sending forged DTLS ClientHello packets to a perform a DoS attack by sending forged DTLS ClientHello packets to a
skipping to change at page 15, line 42 skipping to change at page 17, line 15
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 Connection Management
Clients SHOULD use Path MTU (PMTU) discovery [RFC6520] to determine Clients SHOULD use Path MTU (PMTU) discovery [RFC6520] to determine
the PMTU between the client and server, prior to sending any RADIUS the PMTU between the client and server, prior to sending any RADIUS
traffic. Once a DTLS session is established, a RADIUS/DTLS client traffic. Once a DTLS session is established, a RADIUS/DTLS client
SHOULD use DTLS Heartbeats [RFC6520] to determine connectivity SHOULD use DTLS Heartbeats [RFC6520] to determine connectivity
between the two servers. Alternatively, RADIUS/DTLS clients may use between the two systems. Alternatively, RADIUS/DTLS clients may use
the application-layer watchdog algorithm defined in [RFC3539] to the application-layer watchdog algorithm defined in [RFC3539] to
determine server responsiveness. The Status-Server packet defined in determine server responsiveness. The Status-Server packet defined in
[RFC5997] SHOULD be used as the "watchdog packet" in any application- [RFC5997] SHOULD be used as the "watchdog packet" in any application-
layer watchdog algorithm. layer watchdog 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
entirely. However, DTLS provides no signal that a session has been
closed. There is therefore the possibility that the server closes
the session without the client knowing. When that happens, the
client may later transmit packets in a session, and those packets
will be ignored by the server. The client is then forced to time out
those packets and then the session, leading to delays and network
instabilities.
For these reasons, it is RECOMMENDED that RADIUS/DTLS clients
implement DTLS heartbeats and/or watchdog packets for all DTLS
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 RADIUS/DTLS clients MUST NOT send both RADIUS/UDP and RADIUS/DTLS
packets over the same key of (source IP, source port, destination IP, packets over the same key of (source IP, source port, destination IP,
destination port) as defined in Section 4.1, above . Doing so would destination port) as defined in Section 4.1, above . Doing so would
skipping to change at page 17, line 17 skipping to change at page 18, line 49
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. It is a
good idea to leverage existing functionality. good idea to leverage existing functionality.
RADIUS/DTLS clients SHOULD use one source when sending packets to a RADIUS/DTLS clients SHOULD use one source when sending packets to a
particular RADIUS/DTLS server. Doing so minimizes the number of DTLS particular RADIUS/DTLS server. Doing so minimizes the number of DTLS
session setups. It also ensures that information about the home session setups. It also ensures that information about the home
server state is discovered only once. server state is discovered only once.
In practive, this means that RADIUS/DTLS clients SHOULD use a local In practice, this means that RADIUS/DTLS clients SHOULD use a local
proxy which arbitrates all RADIUS traffic between the client and all proxy which arbitrates all RADIUS traffic between the client and all
servers. The proxy SHOULD accept traffic only from the authorized servers. The proxy SHOULD accept traffic only from the authorized
subsystems on the client machine, and SHOULD proxy that traffic to subsystems on the client machine, and SHOULD proxy that traffic to
known servers. Each authorized subsystem SHOULD include an attribute known servers. Each authorized subsystem SHOULD include an attribute
which uniquely identifies that subsystem to the proxy, so that the which uniquely identifies that subsystem to the proxy, so that the
proxy can apply origin-specific proxy rules and security policies. proxy can apply origin-specific proxy rules and security policies.
We suggest using NAS-Identifier for this purpose. 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
skipping to change at page 18, line 44 skipping to change at page 20, line 30
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 does not create any new registries, nor does it This specification allocates a new UDP port, called "RADIUS-DTLS".
require assignment of any protocol parameters. The references to "UDP/TBD" in this document need to be updated to
use the allocated port number.
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 20, line 39 skipping to change at page 22, line 24
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
exhaustion. Servers MUST therefore limit the absolute number of exhaustion. Servers MUST therefore limit the absolute number of
sessions that they track. Servers MUST limit the number of partially sessions that they track. When the total number of sessions tracked
open DTLS sessions. These limits SHOULD be exposed to the is going to exceed the configured limit, servers MAY free up
administrator as configurable settings. resources by closing the session which has been idle for the longest
time. Doing so may free up idle resources which then allow the
server to accept a new session.
Servers MUST limit the number of partially open DTLS sessions. These
limits SHOULD be exposed to the administrator as configurable
settings.
10.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 The migration flag described above in Section 3 is also tracked per
source IP address. Using a NAT in front of many RADIUS clients source IP address. Using a NAT in front of many RADIUS clients
 End of changes. 30 change blocks. 
99 lines changed or deleted 188 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/