draft-ietf-radext-dtls-02.txt | draft-ietf-radext-dtls-03.txt | |||
---|---|---|---|---|
Network Working Group Alan DeKok | Network Working Group Alan DeKok | |||
INTERNET-DRAFT FreeRADIUS | INTERNET-DRAFT FreeRADIUS | |||
Category: Informational | Category: Experimental | |||
<draft-ietf-radext-dtls-02.txt> | <draft-ietf-radext-dtls-03.txt> | |||
Expires: May 16, 2013 | Expires: July 28, 2013 | |||
16 July 2012 | 28 January 2013 | |||
DTLS as a Transport Layer for RADIUS | DTLS as a Transport Layer for RADIUS | |||
draft-ietf-radext-dtls-02 | draft-ietf-radext-dtls-03 | |||
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 May 16, 2013 | This Internet-Draft will expire on July 28, 2013 | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2012 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 | |||
to this document. Code Components extracted from this document must | to this document. Code Components extracted from this document must | |||
include Simplified BSD License text as described in Section 4.e of | include Simplified BSD License text as described in Section 4.e of | |||
the Trust Legal Provisions and are provided without warranty as | the Trust Legal Provisions and are provided without warranty as | |||
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. Reception of Packets ..................................... 8 | 3. Transition Path .......................................... 8 | |||
4. Connection Management .................................... 9 | 3.1. Server Transition to DTLS ........................... 8 | |||
4.1. Server Connection Management ........................ 9 | 4. Client Transition ........................................ 9 | |||
4.1.1. Table Management ............................... 10 | 5. Connection Management .................................... 10 | |||
4.1.2. Protocol Disambiguation ........................ 11 | 5.1. Server Connection Management ........................ 10 | |||
4.1.3. Processing Algorithm ........................... 12 | 5.1.1. Session Management ............................. 11 | |||
4.2. Client Connection Management ........................ 13 | 5.1.2. Protocol Disambiguation ........................ 12 | |||
5. Diameter Considerations .................................. 14 | 5.1.3. Processing Algorithm ........................... 13 | |||
6. IANA Considerations ...................................... 14 | 5.2. Client Connection Management ........................ 15 | |||
7. Security Considerations .................................. 14 | 6. Implementation Guidelines ................................ 16 | |||
7.1. Legacy RADIUS Security .............................. 14 | 6.1. Client Implementations .............................. 16 | |||
7.2. Resource Exhaustion ................................. 15 | 6.2. Server Implementations .............................. 17 | |||
7.3. Network Address Translation ......................... 16 | 7. Implementation Experience ................................ 17 | |||
7.4. Wildcard Clients .................................... 16 | 8. Diameter Considerations .................................. 17 | |||
8. References ............................................... 16 | 9. IANA Considerations ...................................... 18 | |||
8.1. Normative references ................................ 16 | 10. Security Considerations ................................. 18 | |||
8.2. Informative references .............................. 17 | 10.1. Legacy RADIUS Security ............................. 18 | |||
10.2. Resource Exhaustion ................................ 19 | ||||
10.3. Network Address Translation ........................ 19 | ||||
10.4. Wildcard Clients ................................... 20 | ||||
10.5. Session Closing .................................... 20 | ||||
10.6. Clients Subsystems ................................. 21 | ||||
11. References .............................................. 21 | ||||
11.1. Normative references ............................... 21 | ||||
11.2. Informative references ............................. 22 | ||||
1. Introduction | 1. Introduction | |||
The RADIUS protocol as described in [RFC2865], [RFC2866], [RFC5176], | The RADIUS protocol as described in [RFC2865], [RFC2866], [RFC5176], | |||
and others has traditionally used methods based on MD5 [RFC1321] for | and others has traditionally used methods based on MD5 [RFC1321] for | |||
per-packet authentication and integrity checks. However, the MD5 | per-packet authentication and integrity checks. However, the MD5 | |||
algorithm has known weaknesses such as [MD5Attack] and [MD5Break]. | algorithm has known weaknesses such as [MD5Attack] and [MD5Break]. | |||
As a result, some specifications such as [RFC5176] have recommended | As a result, some specifications such as [RFC5176] have recommended | |||
using IPSec to secure RADIUS traffic. | using IPSec to secure RADIUS traffic. | |||
skipping to change at page 4, line 28 | skipping to change at page 4, line 28 | |||
requirement that the RADIUS traffic be encrypted and/or authenticated | requirement that the RADIUS traffic be encrypted and/or authenticated | |||
is implicit in the network configuration, and is not enforced by the | is implicit in the network configuration, and is not enforced by the | |||
RADIUS application. | RADIUS application. | |||
This specification takes a different approach. We define a method | This specification takes a different approach. We define a method | |||
for using DTLS [RFC6347] as a RADIUS transport protocol. This | for using DTLS [RFC6347] as a RADIUS transport protocol. This | |||
approach has the benefit that the RADIUS application can directly | approach has the benefit that the RADIUS application can directly | |||
monitor and control the security policies associated with the traffic | monitor and control the security policies associated with the traffic | |||
that it processes. | that it processes. | |||
Another benefit is that RADIUS over DTLS continues to be a UDP-based | Another benefit is that RADIUS over DTLS continues to be a User | |||
protocol. This continuity ensures that existing network-layer | Datagram Protocol (UDP) based protocol. This continuity ensures that | |||
infrastructure (firewall rules, etc.) does not need to be changed | existing network-layer infrastructure (firewall rules, etc.) does not | |||
when RADIUS clients and servers are upgraded to support RADIUS over | need to be changed when RADIUS clients and servers are upgraded to | |||
DTLS. | support RADIUS over DTLS. | |||
This specification does not, however, solve all of the problems | This specification does not, however, solve all of the problems | |||
associated with RADIUS. The DTLS protocol does not add reliable or | associated with RADIUS. The DTLS protocol does not add reliable or | |||
in-order transport to RADIUS. DTLS also does not support | in-order transport to RADIUS. DTLS also does not support | |||
fragmentation of application-layer messages, or of the DTLS messages | fragmentation of application-layer messages, or of the DTLS messages | |||
themselves. This specification therefore shares with traditional | themselves. This specification therefore shares with traditional | |||
RADIUS the issues of order, reliability, and fragmentation. | RADIUS the issues of order, reliability, and fragmentation. | |||
1.1. Terminology | 1.1. Terminology | |||
skipping to change at page 5, line 18 | skipping to change at page 5, line 18 | |||
implement RADIUS/DTLS. | implement RADIUS/DTLS. | |||
RADIUS/UDP | RADIUS/UDP | |||
RADIUS over UDP, as defined in [RFC2865]. | RADIUS over UDP, as defined in [RFC2865]. | |||
RADIUS/TLS | RADIUS/TLS | |||
RADIUS over TLS, as defined in [RFC6614]. | RADIUS over TLS, as defined in [RFC6614]. | |||
silently discard | silently discard | |||
This means that the implementation discards the packet without | This means that the implementation discards the packet without | |||
further processing. See Section X.Y for additional requirements on | further processing. | |||
packets being silently discarded. | ||||
1.2. Requirements Language | 1.2. Requirements Language | |||
In this document, several words are used to signify the requirements | In this document, several words are used to signify the requirements | |||
of the specification. The key words "MUST", "MUST NOT", "REQUIRED", | of the specification. The key words "MUST", "MUST NOT", "REQUIRED", | |||
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", | "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", | |||
and "OPTIONAL" in this document are to be interpreted as described in | and "OPTIONAL" in this document are to be interpreted as described in | |||
[RFC2119]. | [RFC2119]. | |||
2. Building on Existing Foundations | 2. Building on Existing Foundations | |||
skipping to change at page 6, line 33 | skipping to change at page 6, line 33 | |||
* 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 | * UDP port numbering and relationship between code and port | |||
In short, the application creates a RADIUS packet as usual, and then | In short, the application creates a RADIUS packet via the usual | |||
instead of sending it over a UDP socket, sends the packet to a DTLS | methods, and then instead of sending it over a UDP socket, sends the | |||
layer for encapsulation. DTLS then acts as a transport layer for | packet to a DTLS layer for encapsulation. DTLS then acts as a | |||
RADIUS, hence the names "RADIUS/UDP" and "RADIUS/DTLS". | transport layer for RADIUS, hence the names "RADIUS/UDP" and | |||
"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 the minimum | We note that the DTLS encapsulation of RADIUS means that the minimum | |||
and maximum UDP packet sizes increase by the DTLS overhead. | and maximum UDP packet sizes increase by the DTLS overhead. | |||
Implementations should be aware of this, and take it into account | Implementations should be aware of this, and take it into account | |||
when allocating buffers to read and write RADIUS/DTLS packets. | when allocating buffers to read and write RADIUS/DTLS packets. | |||
skipping to change at page 7, line 13 | skipping to change at page 7, line 14 | |||
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". | |||
All other aspects of RADIUS are unchanged. | All other aspects of RADIUS are unchanged. | |||
2.2. Similarities with RADIUS/TLS | 2.2. Similarities with RADIUS/TLS | |||
While this specification can be thought of as RADIUS/TLS over UDP | While this specification can be thought of as RADIUS/TLS over UDP | |||
instead of TCP, there are some differences between the two methods. | instead of the Transmission Control Protocol (TCP), there are some | |||
The bulk of [RFC6614] applies to this specification, so we do not | differences between the two methods. The bulk of [RFC6614] applies | |||
repeat it here. | to this specification, so we do not repeat it here. | |||
This section explains the differences between RADIUS/TLS and | This section explains the differences between RADIUS/TLS and | |||
RADIUS/DTLS, as semantic "patches" to [RFC6614]. The changes are as | RADIUS/DTLS, as semantic "patches" to [RFC6614]. The changes are as | |||
follows: | follows: | |||
* We replace references to "TCP" with "UDP" | * We replace references to "TCP" with "UDP" | |||
* We replace references to "RADIUS/TLS" with "RADIUS/DTLS" | * We replace references to "RADIUS/TLS" with "RADIUS/DTLS" | |||
* We replace references to "TLS" with "DTLS" | * We replace references to "TLS" with "DTLS" | |||
Those changes are sufficient to cover the majority of the differences | Those changes are sufficient to cover the majority of the differences | |||
between the two specifications. The next section reviews some more | between the two specifications. The next section reviews some more | |||
detailed changes from [RFC6614], giving additional commentary only | detailed changes from [RFC6614], giving additional commentary only | |||
where necessary. | where necessary. | |||
2.2.1. Changes from RADIUS/TLS to RADIUS/DTLS | 2.2.1. Changes from RADIUS/TLS to RADIUS/DTLS | |||
This section describes where this specification is similar to | ||||
[RFC6614], and where it differs. | ||||
Section 2.1 does not apply to RADIUS/DTLS. The relationship between | Section 2.1 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. | |||
Section 2.2 applies also to RADIUS/DTLS, except for the | Section 2.2 applies to RADIUS/DTLS. Servers and clients need to be | |||
preconfigured to use RADIUS/DTLS for a given endpoint. | ||||
Most of Section 2.3 applies also to RADIUS/DTLS. Item (1) should be | ||||
interpreted as applying to DTLS session initiation, instead of TCP | ||||
connection establishment. Item (2) applies, except for the | ||||
recommendation that implementations "SHOULD" support | 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. | artifact of RADIUS/TLS, and does not apply to RADIUS/DTLS. Item (3) | |||
applies to RADIUS/DTLS. Item (4) applies, except that the fixed | ||||
shared secret is "radius/dtls", as described above. | ||||
Section 2.3 does not apply to RADIUS/DTLS. | Section 2.4 does not apply to RADIUS/DTLS. | |||
Section 2.4 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. | |||
Section 3.3 item (1) does not apply to RADIUS/DTLS. Each RADIUS | Sections 3.1, 3.2, and 3.3 apply to RADIUS/DTLS. | |||
Section 3.4 item (1) does not apply to RADIUS/DTLS. Each RADIUS | ||||
packet is encapsulated in one DTLS packet, and there is no "stream" | 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.3 item (3) does not apply to RADIUS/TDLS. The relationship | Section 3.4 item (3) does not apply to RADIUS/DTLS. The relationship | |||
between RADIUS packet codes and UDP ports in RADIUS/DTLS is unchanged | between RADIUS packet codes and UDP ports in RADIUS/DTLS is unchanged | |||
from RADIUS. | from RADIUS. | |||
Section 3.3 item (4) does not apply to RADIUS/DTLS. As RADIUS/DTLS | Section 3.4 item (4) does not apply to RADIUS/DTLS. As RADIUS/DTLS | |||
still uses UDP for a transport, the use of negative ICMP responses is | still uses UDP for a transport, the use of negative ICMP responses is | |||
unchanged from RADIUS. | unchanged from RADIUS. | |||
Section 4 does not apply to RADIUS/DTLS. Protocol compatibility | ||||
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. | in their entirety to RADIUS/DTLS. | |||
3. Reception of Packets | 3. Transition Path | |||
As this specification permits implementations to to accept both | Transitioning to DTLS is a process which needs to be done carefully. | |||
A poorly handled transition is complex for administrators, and | ||||
potentially subject to security downgrade attacks. This section | ||||
describes how clients and servers should transition to DTLS. | ||||
3.1. Server Transition to DTLS | ||||
As this specification permits server implementations to accept both | ||||
RADIUS/UDP and RADIUS/DTLS packets on the same port, we require a | RADIUS/UDP and RADIUS/DTLS packets on the same port, we require a | |||
method to disambiguate packets between the two protocols. This | method to disambiguate packets between the two protocols. This | |||
method is applicable only to RADIUS/DTLS servers. RADIUS/DTLS | method is applicable only to RADIUS/DTLS servers. | |||
clients SHOULD use connected sockets, as discussed in Section X.Y, | ||||
below. | ||||
RADIUS/DTLS servers MUST maintain a boolean "DTLS Required" flag for | RADIUS/DTLS servers MUST maintain a boolean "DTLS Required" flag for | |||
each client that indicates if it requires a client to use | each client that indicates if it requires a client to use | |||
RADIUS/DTLS. The interpretation of this flag is as follows. If the | RADIUS/DTLS. The interpretation of this flag is as follows. If the | |||
flag is "true" then the client supports RADIUS/DTLS, and all packets | flag is "true" then the client supports RADIUS/DTLS, and all packets | |||
from that client MUST be processed as RADIUS/DTLS. If the flag is | from that client MUST be processed as RADIUS/DTLS. If the flag is | |||
"false", then the client supports RADIUS/UDP, but may still support | "false", then the client supports RADIUS/UDP, but may still support | |||
RADIUS/DTLS. Packets from the client need to be examined to see if | RADIUS/DTLS. Packets from the client need to be examined to see if | |||
they are RADIUS/UDP or RADIUS/DTLS. | they are RADIUS/UDP or RADIUS/DTLS. | |||
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. | mark them as using RADIUS/DTLS. The default value for the flag | |||
SHOULD be "false". | ||||
It is RECOMMENDED that the default value for the "DTLS Required" flag | ||||
be set to "true" when this specification has acheived wide-spread | ||||
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 MUST | |||
set the "DTLS Required" flag to "true". This change requires all | set the "DTLS Required" flag to "true". This change requires all | |||
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. | |||
Note that this last requirement on servers can impose significant | Note that this last requirement on servers can impose significant | |||
changes for clients. Clients can no longer have multiple independent | changes for clients. These changes are discussed in the next | |||
RADIUS implementations or processes that originate RADIUS/UDP and | section. | |||
RADIUS/DTLS packets. Instead, they need to use only one transport | ||||
layer, either UDP or DTLS. | ||||
It is therefore RECOMMENDED that RADIUS/DTLS clients use a local | 4. Client Transition | |||
proxy which arbitrates all traffic between the client and any | ||||
servers. The proxy SHOULD accept traffic only from the authorized | ||||
subsystems on the client machine, and SHOULD proxy that traffic to | ||||
one or more known servers. | ||||
4. Connection Management | As this specification permits client implementations to to send both | |||
RADIUS/UDP and RADIUS/DTLS packets from the same address, 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. The interpretation of this flag is as follows. 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". | ||||
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 | ||||
DTLS transport. Doing so would cause servers to immediately require | ||||
that all new packets from the client use DTLS. This requirement may | ||||
be difficult for a client to satisfy. Instead, clients SHOULD use | ||||
DTLS as a transport layer only when administratively configured. | ||||
The requirements of this specification mean that RADIUS/DTLS clients | ||||
can no longer have multiple independent RADIUS implementations, or | ||||
processes that originate RADIUS/UDP and RADIUS/DTLS packets. | ||||
Instead, clients MUST use only one transport layer to communicate | ||||
with a specific server. It is RECOMMENDED that clients use a local | ||||
proxy as described in Section 6.1, above. | ||||
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 will need to perform connection | implementations of this specification may need to perform connection | |||
management of the DTLS session in the application layer. | management of the DTLS session in the application layer. This | |||
section describes logically how this tracking is done. | ||||
Implementations may choose to use the method described here, or | ||||
another, equivalent method. | ||||
4.1. Server Connection Management | 5.1. Server Connection Management | |||
A RADIUS/DTLS server MUST maintain a table that tracks ongoing client | A RADIUS/DTLS server MUST track ongoing client connections based on a | |||
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 | |||
Note that this table is independent of IP address version (IPv4 or | Note that this key is independent of IP address version (IPv4 or | |||
IPv6). | IPv6). | |||
Each table entry contains the following information: | Each entry associated with a key contains the following information: | |||
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 Packet | |||
A variable containing a timestamp which indicates when the last | A variable containing a timestamp which indicates when the last | |||
valid packet was received for this connection. Packets which are | valid packet was received for this connection. Packets which are | |||
"silently discarded" MUST NOT update this variable. | "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. | |||
RADIUS/DTLS servers SHOULD NOT use connected sockets to read DTLS | 5.1.1. Session Management | |||
packets from a client. This recommendation is because a connected | ||||
UDP socket will accept packets only from one source IP address and | ||||
port. This limitation would prevent the server from accepting | ||||
packets from multiple clients on the same port. | ||||
4.1.1. Table Management | ||||
This tracking table is subject to Denial of Service (DoS) attacks due | Session tracking is subject to Denial of Service (DoS) attacks due to | |||
to the ability of an attacker to forge UDP traffic. RADIUS/DTLS | the ability of an attacker to forge UDP traffic. RADIUS/DTLS servers | |||
servers SHOULD use the stateless cookie tracking technique described | SHOULD use the stateless cookie tracking technique described in | |||
in [RFC6347] Section 4.2.1. DTLS sessions SHOULD NOT be added to the | [RFC6347] Section 4.2.1. DTLS sessions SHOULD NOT be tracked until a | |||
tracking table until a ClientHello packet has been received with an | ClientHello packet has been received with an appropriate Cookie | |||
appropriate Cookie value. The requirement to accept RADIUS/UDP and | value. The requirement to accept RADIUS/UDP and RADIUS/DTLS on the | |||
RADIUS/DTLS on the same port makes this recommendation difficult to | same port makes this recommendation difficult to implement in | |||
implement in practice. Server implementation SHOULD therefore have a | practice. Server implementation SHOULD therefore have a way of | |||
way of tracking partially setup DTLS connections. Servers SHOULD | tracking partially setup DTLS connections. Servers SHOULD limit both | |||
limit both the number and impact on resources of partial connections. | the number and impact on resources of partial connections. | |||
Entries in the tracking table 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 TLS Error Alert ([RFC5246] Section | |||
7.2.2) is received. Where the specifications require that a packet | 7.2.2) is received. When a session is deleted due to failed | |||
received via a DTLS session be "silently discarded", the entry in the | security, the DTLS session MUST be closed, and any TLS session | |||
tracking table corresponding to that DTLS session MUST also be | resumption parameters for that session MUST be discarded, and all | |||
deleted, the DTLS session MUST be closed, and any TLS session | tracking information MUST be deleted. | |||
resumption parameters for that session MUST be discarded. The | ||||
implementation MAY provide the capability of logging the error, | Sessions MUST also be deleted when a RADIUS packet fails validation | |||
including the contents of the silently discarded packet, and SHOULD | due to a packet being malformed, or when it has an invalid Message- | |||
record the event in a statistics counter. | Authenticator, or invalid Request Authenticator. There are other | |||
cases when the specifications require that a packet received via a | ||||
DTLS session be "silently discarded". In those cases, | ||||
implementations MAY delete the underlying session as described above. | ||||
There are few reasons to communicate with a NAS which is not | ||||
implementing RADIUS. | ||||
Once a DTLS session is established, a RADIUS/DTLS server SHOULD use | ||||
DTLS Heartbeats [RFC6520] to determine connectivity between the two | ||||
servers. A server may also use watchdog packets from the client 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 | MUST also maintain a "Last Packet" timestamp per DTLS session. The | |||
timestamp SHOULD be updated on reception of a valid DTLS packet. The | timestamp SHOULD be updated on reception of a valid RADIUS/DTLS | |||
timestamp MUST NOT be updated in other situations. When a session | packet. The timestamp MUST NOT be updated in other situations. When | |||
has not received a packet for a period of time, it is labelled | a session has not received a packet for a period of time, it is | |||
"idle". The server SHOULD delete idle DTLS session from the tracking | labelled "idle". The server SHOULD delete idle DTLS sessions after | |||
table after an "idle timeout". The server MAY cache the TLS session | an "idle timeout". The server MAY cache the TLS session parameters, | |||
parameters, in order to provide for fast session resumption. | 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 keep track of the total number of | RADIUS/DTLS servers SHOULD also monitor the total number of sessions | |||
sessions in the tracking table. They SHOULD stop the creating of new | they are tracking. They SHOULD stop the creating of new sessions | |||
sessions when a large number are already being tracked. This | when a large number are already being tracked. This "maximum | |||
"maximum sessions" number SHOULD be exposed to administrators as a | sessions" number SHOULD be exposed to administrators as a | |||
configurable setting. | configurable setting. | |||
4.1.2. Protocol Disambiguation | RADIUS/DTLS servers SHOULD implement session resumption, preferably | |||
stateless session resumption as given in [RFC5077]. This practice | ||||
lowers the time and effort required to start a DTLS session with a | ||||
client, and increases network responsiveness. | ||||
5.1.2. Protocol Disambiguation | ||||
When the "DTLS Required" flag for a client is set to "false", the | When the "DTLS Required" flag for a client is set to "false", the | |||
client may, or may not be sending DTLS packets. For existing | client may, or may not be sending DTLS packets. For existing | |||
connections, protocol disambiguation is simple, the "Protocol Type" | connections, protocol disambiguation is simple, the "Protocol Type" | |||
field in the tracking table entry is examined. New connections must | field in the session tracking entry is examined. New connections | |||
still be disambiguated. | must still be disambiguated. | |||
In order to provide a robust upgrade path, the RADIUS/DTLS server | 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. | MUST examine the packet to see if it is RADIUS/UDP or RADIUS/DTLS. | |||
This examination method is defined here. | This examination method is defined here. | |||
We justify the examination methods by analysing the packet formats | We justify the examination methods by analysing the packet formats | |||
for the two protocols. We assume that the server has a buffer in | for the two protocols. We assume that the server has a buffer in | |||
which it has received a UDP packet matching no entry on the | which it has received a UDP packet matching no entry based on the | |||
conneciton tracking table. It must then analyse this buffer to | 4-tuple key defined above. It must then analyse this buffer to | |||
determine which protocol is used to process the packet. | determine which protocol is used to process the packet. | |||
The DTLS record format ([RFC6347] Section 4.1) is shown below, in | The DTLS record format ([RFC6347] Section 4.1) is shown below, in | |||
pseudo-code: | pseudo-code: | |||
struct { | struct { | |||
uint8 type; | uint8 type; | |||
uint16 version; | uint16 version; | |||
uint16 epoch; | uint16 epoch; | |||
uint48 sequence_number; | uint48 sequence_number; | |||
skipping to change at page 12, line 21 | skipping to change at page 13, line 41 | |||
Resource-Free-Response. That code is intended to be a response from | 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 to a client, and will therefore never be sent by a client to | |||
a server. | a server. | |||
As a result, protocol disambiguation for new connections 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 | is straightforward. Only the first octet of the packet needs to be | |||
examined to disambiguate RADIUS/DTLS from RADIUS/UDP. If that octet | examined to disambiguate RADIUS/DTLS from RADIUS/UDP. If that octet | |||
has value 22, then the packet is likely to be RADIUS/DTLS. | has value 22, then the packet is likely to be RADIUS/DTLS. | |||
Otherwise, the packet is likely to be RADIUS/UDP. | Otherwise, the packet is likely to be RADIUS/UDP. | |||
4.1.3. Processing Algorithm | 5.1.3. Processing Algorithm | |||
When a RADIUS/DTLS server recieves a packet, it uses the following | When a RADIUS/DTLS server recieves a packet, it uses the following | |||
algorithm to process that packet. As with RADIUS/UDP, packets from | algorithm to process that packet. As with RADIUS/UDP, packets from | |||
unknown clients MUST be silently discarded. | unknown clients MUST be silently discarded. | |||
The "DTLS Required" flag for that client is examined. If it is set | The "DTLS Required" flag for that client is examined. If it is set | |||
to "true", then the packet MUST be processed as RADIUS/DTLS. | to "true", then the packet MUST be processed as RADIUS/DTLS. | |||
If the "DTLS Required" flag is set to "false", the connection | If the "DTLS Required" flag is set to "false", the session is looked | |||
tracking table is examined. Packets matching an existing entry MUST | up using the 4-tuple key defined above. Packets matching an existing | |||
be processed as defined by the "Protocol Type" field of that entry. | 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 entry exists in | If the "DTLS Required" flag is set to "false" and no matching entry | |||
the connection tracking table, then the first octet of the packet is | has been found, then the first octet of the packet is examined. If | |||
examined. If it has value 22, then the packet MUST be processed as | it has value 22, then the packet MUST be processed as RADIUS/DTLS. | |||
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 the session tracking table. 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 table. | NOT affect the state of any variable in the session tracking entry. | |||
For RADIUS/DTLS, any RADIUS packets which are subsequently silently | For RADIUS/DTLS, any RADIUS packets which are subsequently silently | |||
discarded MUST result in the removal of the associated entry from the | discarded MUST result in the removal of the associated entry and key. | |||
connection tracking table. | ||||
When the packet matches an existing entry in the connection table, | When the packet matches an existing key, and is accepted for | |||
and is accepted for processing by the server, the "Last Packet" | processing by the server, the "Last Packet" timestamp is updated in | |||
timestamp is updated. Where the packet does not match any entry in | that entry. Where the packet does not match an existing key, a new | |||
the connection table, a new connection is created using the 4-tuple | entry is created for that key. The "Protocol Type" flag for that | |||
key defined above. The "Protocol Type" flag for that connection is | entry is set to "RADIUS/DTLS", or "RADIUS/UDP", as determined by | |||
set to "RADIUS/DTLS", or "RADIUS/UDP", as determined by examining the | examining the first octet of the packet. | |||
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 | |||
server. | server. | |||
4.2. Client Connection Management | Since UDP is stateless, the potential exists for the client to | |||
initiate a new DTLS session using a particular 4-tuple, before the | ||||
server has closed the old session. For security reasons, the server | ||||
must keep the old session active until it has received secure | ||||
notification from the client that the session is closed. Or, when | ||||
the server has decided for itself that the session is closed. Taking | ||||
any other action would permit unauthenticated clients to perform a | ||||
DoS attack, by closing active DTLS session. | ||||
Clients SHOULD use "connected" UDP sockets for RADIUS/DTLS traffic. | As a result, servers MUST ignore any attempts to re-use an existing | |||
A connected socket will then rely on the operating system to perform | 4-tuple from an active session. This requirement can likely be | |||
connection tracking. Clients SHOULD NOT use "unconnected" sockets | reached by simply processing the packet through the existing session, | |||
for RADIUS/DTLS traffic. Using unconnected sockets would require the | as with any other packet received via that 4-tuple. Non-compliant, | |||
client to implement a connection tracking table, which is complex and | or unexpected packets will be ignored by the SSL layer. | |||
unnecessary. | ||||
Once a DTLS session is established, a RADIUS/DTLS client SHOULD use | The above requirement is mitigated by the suggestion in Section 6.1, | |||
below, that the client use a local proxy for all RADIUS traffic. | ||||
That proxy can then track the ports which it uses, and ensure that | ||||
re-use of 4-tuples is avoided. The exact process by which this | ||||
tracking is done is outside of the scope of this document. | ||||
5.2. Client Connection Management | ||||
Clients SHOULD use Path MTU (PMTU) discovery [RFC6520] to determine | ||||
the PMTU between the client and server, prior to sending any RADIUS | ||||
traffic. Once a DTLS session is established, a RADIUS/DTLS client | ||||
SHOULD use DTLS Heartbeats [RFC6520] to determine connectivity | ||||
between the two servers. 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] MUST be used as the "watchdog packet" in the watchdog | [RFC5997] SHOULD be used as the "watchdog packet" in any application- | |||
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 | |||
no traffic other than watchdog packets and (possibly) watchdog | the DTLS Heartbeat algorithm indicates that the session is no longer | |||
responses have been sent for three watchdog timeouts. This behavior | active. Clients SHOULD close a session when no traffic other than | |||
ensures that clients do not waste resources on the server by causing | watchdog packets and (possibly) watchdog responses have been sent for | |||
it to track idle sessions. | three watchdog timeouts. This behavior ensures that clients do not | |||
waste resources on the server by causing it to track idle sessions. | ||||
DTLS sessions MUST also be deleted when a RADIUS packet fails | ||||
validation due to a packet being malformed, or when it has an invalid | ||||
Message-Authenticator, or invalid Response Authenticator. There are | ||||
other cases when the specifications require that a packet received | ||||
via a DTLS session be "silently discarded". In those cases, | ||||
implementations MAY delete the underlying DTLS session. | ||||
RADIUS/DTLS clients 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 | |||
make it impossible to correctly process either kind of packet. | 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 use TLS session resumption. This practice | RADIUS/DTLS clients SHOULD implement session resumption, preferably | |||
stateless session resumption as given in [RFC5077]. This practice | ||||
lowers the time and effort required to start a DTLS session with a | lowers the time and effort required to start a DTLS session with a | |||
server, and increases network responsiveness. | server, and increases network responsiveness. | |||
5. Diameter Considerations | 6. Implementation Guidelines | |||
The text above describes the protocol. In this section, we give | ||||
additional implementation guidelines. These guidelines are not part | ||||
of the protocol, but may help implementors create simple, secure, and | ||||
inter-operable implementations. | ||||
Where a TLS pre-shared key (PSK) method is used, implementations MUST | ||||
support keys of at least 16 octets in length. Implementations SHOULD | ||||
support key lengths of 32 octets, and SHOULD allow for longer keys. | ||||
The key data MUST be capable of being any value (0 through 255, | ||||
inclusive). Implementations MUST NOT limit themselves to using | ||||
textual keys. It is RECOMMENDED that the administration interface | ||||
allos for the keys to be entered as hex strings. | ||||
It is RECOMMENDED that keys be derived from a cryptographically | ||||
secure pseudo-random number generator (CSPRNG). If managing keys is | ||||
too complicated, a certificate-based TLS method SHOULD be used | ||||
instead. | ||||
6.1. Client Implementations | ||||
RADIUS/DTLS clients SHOULD use connected sockets where possible. Use | ||||
of connected sockets means that the underlying kernel tracks the | ||||
sessions, so that the client subsystem does not need to. It is a | ||||
good idea to leverage existing functionality. | ||||
RADIUS/DTLS clients SHOULD use a local proxy which arbitrates all | ||||
RADIUS traffic between the client and all servers. The proxy SHOULD | ||||
accept traffic only from the authorized subsystems on the client | ||||
machine, and SHOULD proxy that traffic to known servers. Each | ||||
authorized subsystem SHOULD include an attribute which uniquely | ||||
identifies that subsystem to the proxy, so that the proxy can apply | ||||
origin-specific proxy rules and security policies. We suggest using | ||||
NAS-Identifier for this purpose. | ||||
Each client subsystem can include a subsystem-specific NAS-Identifier | ||||
in each request. The format of this attribute is implementation- | ||||
specific. The proxy SHOULD verify that the request originated from | ||||
the local system, ideally via a loopback address. The proxy MUST | ||||
then re-write any subsystem-specific NAS-Identifier to a NAS- | ||||
Identifier which identifies the client as a whole. Or, remove NAS- | ||||
Identifier entirely and replace it with NAS-IP-Address or NAS- | ||||
IPv6-Address. | ||||
In traditional RADIUS, the cost to set up a new "session" between a | ||||
client and server was minimal. The client subsystem could simply | ||||
open a port, send a packet, wait for the response, and the close the | ||||
port. With RADIUS/DTLS, the connection setup is significantly more | ||||
expensive. In addition, there may be a requirement to use DTLS in | ||||
order to communicate with a server, so that traditional RADIUS would | ||||
be ignored by that server. The knowledge of what protocol to use is | ||||
best managed by a dedicated RADIUS subsystem, rather than by each | ||||
individual subsystem on the client. | ||||
6.2. Server Implementations | ||||
RADIUS/DTLS servers SHOULD NOT use connected sockets to read DTLS | ||||
packets from a client. This recommendation is because a connected | ||||
UDP socket will accept packets only from one source IP address and | ||||
port. This limitation would prevent the server from accepting | ||||
packets from multiple clients on the same port. | ||||
7. Implementation Experience | ||||
Two implementations of RADIUS/DTLS exist, Radsecproxy, and jradius | ||||
(http://www.coova.org/JRadius). Some experimental tests have been | ||||
performed, but there are at this time no production implementations | ||||
using RADIUS/DTLS. | ||||
Section 4.2 of [RFC6421] makes a number of recommendations about | ||||
security properties of new RADIUS proposals. All of those | ||||
recommendations are satisfied by using DTLS as the transport layer. | ||||
Section 4.3 of [RFC6421] makes a number of recommendations about | ||||
backwards compatibility with RADIUS. Section 3, above, addresses | ||||
these concerns in detail. | ||||
Section 4.4 of [RFC6421] recommends that change control be ceded to | ||||
the IETF, and that interoperability is possible. Both requirements | ||||
are satisfied. | ||||
Section 4.5 of [RFC6421] requires that the new security methods apply | ||||
to all packet types. This requirement is satisfied by allowing DTLS | ||||
to be used for all RADIUS traffic. In addition, Section 3, above, | ||||
addresses concerns about documenting the transition from legacy | ||||
RADIUS to crypto-agile RADIUS. | ||||
Section 4.6 of [RFC6421] requires automated key management. This | ||||
requirement is satisfied by leveraging DTLS. | ||||
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. | |||
6. IANA Considerations | 9. IANA Considerations | |||
This specification does not create any new registries, nor does it | This specification does not create any new registries, nor does it | |||
require assignment of any protocol parameters. | require assignment of any protocol parameters. | |||
7. 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 | |||
TLS and RADIUS security issues discussed in [RFC6614] also apply to | TLS and RADIUS security issues discussed in [RFC6614] also apply to | |||
this specification. All of the security considerations for RADIUS | this specification. All of the security considerations for RADIUS | |||
skipping to change at page 14, line 46 | skipping to change at page 18, line 40 | |||
The only new portion of the specification that could have security | The only new portion of the specification that could have security | |||
implications is a servers ability to accept both RADIUS and DTLS | implications is a servers ability to accept both RADIUS and DTLS | |||
packets on the same port. The filter that disambiguates the two | packets on the same port. The filter that disambiguates the two | |||
protocols is simple, and is just a check for the value of one octet. | protocols is simple, and is just a check for the value of one octet. | |||
We do not expect this check to have any security issues. | We do not expect this check to have any security issues. | |||
We also note that nothing prevents malicious clients from sending | We also note that nothing prevents malicious clients from sending | |||
DTLS packets to existing RADIUS implementations, or RADIUS packets to | DTLS packets to existing RADIUS implementations, or RADIUS packets to | |||
existing DTLS implementations. There should therefore be no issue | existing DTLS implementations. There should therefore be no issue | |||
with clients sending RADIUS/DTLS packets to legacy servers that do | with clients sending RADIUS/DTLS packets to legacy servers that do | |||
not support the protocol. These packets will be silently ignored, | not support the protocol. These packets will be silently discarded, | |||
and will not change the security profile of the server. | and will not change the security profile of the server. | |||
7.1. Legacy RADIUS Security | 10.1. Legacy RADIUS Security | |||
We reiterate here the poor security of the legacy RADIUS protocol. | We reiterate here the poor security of the legacy RADIUS protocol. | |||
It is RECOMMENDED that all RADIUS clients and servers implement this | It is RECOMMENDED that all RADIUS clients and servers implement this | |||
specification. New attacks on MD5 have appeared over the past few | specification. New attacks on MD5 have appeared over the past few | |||
years, and there is a distinct possibility that MD5 may be completely | years, and there is a distinct possibility that MD5 may be completely | |||
broken in the near future. | broken in the near future. | |||
The existence of fast and cheap attacks on MD5 could result in a loss | The existence of fast and cheap attacks on MD5 could result in a loss | |||
of all network security which depends on RADIUS. Attackers could | of all network security which depends on RADIUS. Attackers could | |||
obtain user passwords, and possibly gain complete network access. We | obtain user passwords, and possibly gain complete network access. We | |||
skipping to change at page 15, line 30 | skipping to change at page 19, line 24 | |||
shared secret between RADIUS/UDP and RADIUS/DTLS would negate all of | shared secret between RADIUS/UDP and RADIUS/DTLS would negate all of | |||
the benefits found by using DTLS. | the benefits found by using DTLS. | |||
RADIUS/DTLS client implementors MUST expose a configuration that | RADIUS/DTLS client implementors MUST expose a configuration that | |||
allows the administrator to choose the cipher suite. Where | allows the administrator to choose the cipher suite. Where | |||
certificates are used, RADIUS/DTLS client implementors MUST expose a | certificates are used, RADIUS/DTLS client implementors MUST expose a | |||
configuration which allows an administrator to configure all | configuration 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. | |||
When using PSK methods, RADIUS/DTLS servers MUST support keys (i.e. | TLS-PSK methods are susceptible to dictionary attacks. Section 6, | |||
shared secrets) that are at least 32 characters in length. These | above, recommends deriving TLS-PSK keys from a CSPRNG, which makes | |||
keys SHOULD be able to contain arbitrary binary data. RADIUS/DTLS | dictionary attacks significantly more difficult. Servers SHOULD | |||
server administrators MUST use strong shared secrets for those PSK | track failed client connections by TLS-PSK ID, and block TLS-PSK IDs | |||
methods. We RECOMMEND using keys derived from a cryptographically | which seem to be attempting brute-force searchs of the keyspace. | |||
secure pseudo-random number generator (CSPRNG). For example, a | ||||
reasonable key may be 32 characters of a SHA-256 hash of at least 64 | ||||
octetss of data taken from a CSPRNG. If this method seems too | ||||
complicated, a certificate-based TLS method SHOULD be used instead. | ||||
The previous RADIUS practice of using shared secrets that are minor | The previous RADIUS practice of using shared secrets that are minor | |||
variations of words is NOT RECOMMENDED, as it would negate nearly all | variations of words is NOT RECOMMENDED, as it would negate all of the | |||
of the security of DTLS. | security of DTLS. | |||
7.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 same as | which were not possible in RADIUS/UDP. These attacks are the similar | |||
described in [RFC6614] Section X.Y. | to those described in [RFC6614] Section 6, for TCP. | |||
Use of the connection tracking table defined in Section X.Y can | Session tracking as described in Section 5.1 can result in resource | |||
result in resource exhaustion. Servers MUST therefore limit the | exhaustion. Servers MUST therefore limit the absolute number of | |||
absolute number of entries in the table. Servers MUST limit the | sessions that they track. Servers MUST limit the number of partially | |||
number of partially open DTLS sessions. These limits SHOULD be | open DTLS sessions. These limits SHOULD be exposed to the | |||
exposed to the administrator as configurable settings. | administrator as configurable settings. | |||
7.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 | |||
negates the function of the flag, making it impossible to migrate | negates the function of the flag, making it impossible to migrate | |||
multiple clients in a secure fashion. | multiple clients in a secure fashion. | |||
skipping to change at page 16, line 33 | skipping to change at page 20, line 23 | |||
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. | |||
7.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", then RADIUS/DTLS MUST be used. | |||
Clients MUST be uniquely identified, and any certificate or PSK used | Clients MUST be uniquely identified, and any certificate or PSK used | |||
MUST be unique to each client. | MUST be unique to each client. | |||
8. References | 10.5. Session Closing | |||
8.1. Normative references | Section 5.1.1 above requires that DTLS sessions be closed when the | |||
transported RADIUS packets are malformed, or fail various | ||||
authenticator checks. This requirement is due to security | ||||
considerations. | ||||
When an implementation has a DTLS connection, it is expected that the | ||||
connection be used to transport RADIUS. Any non-RADIUS traffic on | ||||
that connection means the other party is misbehaving, and a potential | ||||
security risk. Similarly, any RADIUS traffic failing validation | ||||
means that two parties do not share the same security parameters, and | ||||
the session is therefore a security risk. | ||||
We wish to avoid the situation where a third party can send well- | ||||
formed RADIUS packets which cause a DTLS connection to close. | ||||
Therefore, in other situations, the session may remain open in the | ||||
face of non-conformant packets. | ||||
10.6. Clients Subsystems | ||||
Many traditional clients treat RADIUS as subsystem-specific. That | ||||
is, each subsystem on the client has its own RADIUS implementation | ||||
and configuration. These independent implementations work for simple | ||||
systems, but break down for RADIUS when multiple servers, fail-over, | ||||
and load-balancing are required. They have even worse issues when | ||||
DTLS is enabled. | ||||
As noted in Section 6.1, above, clients SHOULD use a local proxy | ||||
which arbitrates all RADIUS traffic between the client and all | ||||
servers. This proxy will encapsulate all knowledge about servers, | ||||
including security policies, fail-over, and load-balancing. All | ||||
client subsystems SHOULD communicate with this local proxy, ideally | ||||
over a loopback address. The requirements on using strong shared | ||||
secrets still apply. | ||||
The benefit of this configuration is that there is one place in the | ||||
client which arbitrates all RADIUS traffic. Subsystems which do not | ||||
implement DTLS can remain unaware of DTLS. DTLS connections opened | ||||
by the proxy can remain open for long periods of time, even when | ||||
client subsystems are restarted. The proxy can do RADIUS/UDP to some | ||||
servers, and RADIUS/DTLS to others. | ||||
Delegation of responsibilities and separation of tasks are important | ||||
security principles. By moving all RADIUS/DTLS knowledge to a DTLS- | ||||
aware proxy, security analysis becomes simpler, and enforcement of | ||||
correct security becomes easier. | ||||
11. References | ||||
11.1. Normative references | ||||
[RFC2865] | [RFC2865] | |||
Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote | Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote | |||
Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. | Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. | |||
[RFC3539] | [RFC3539] | |||
Aboba, B. et al., "Authentication, Authorization and Accounting | Aboba, B. et al., "Authentication, Authorization and Accounting | |||
(AAA) Transport Profile", RFC 3539, June 2003. | (AAA) Transport Profile", RFC 3539, June 2003. | |||
[RFC5077] | ||||
Salowey, J, et al., "Transport Layer Security (TLS) Session | ||||
Resumption without Server-Side State", RFC 5077, January 2008 | ||||
[RFC5246] | [RFC5246] | |||
Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) | Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) | |||
Protocol Version 1.2", RFC 5246, August 2008. | Protocol Version 1.2", RFC 5246, August 2008. | |||
[RFC5997] | [RFC5997] | |||
DeKok, A., "Use of Status-Server Packets in the Remote | DeKok, A., "Use of Status-Server Packets in the Remote | |||
Authentication Dial In User Service (RADIUS) Protocol", RFC 5997, | Authentication Dial In User Service (RADIUS) Protocol", RFC 5997, | |||
August 2010. | August 2010. | |||
[RFC6347] | [RFC6347] | |||
Rescorla E., and Modadugu, N., "Datagram Transport Layer Security", | Rescorla E., and Modadugu, N., "Datagram Transport Layer Security", | |||
RFC 6347, April 2006. | RFC 6347, April 2006. | |||
[RFC6520] | ||||
Seggelmann, R., et al.,"Transport Layer Security (TLS) and Datagram | ||||
Transport Layer Security (DTLS) Heartbeat Extension", RFC 6520, | ||||
February 2012. | ||||
[RFC6614] | [RFC6614] | |||
Winter. S, et. al., "TLS encryption for RADIUS over TCP", RFFC | Winter. S, et. al., "TLS encryption for RADIUS over TCP", RFFC | |||
6614, May 2012 | 6614, May 2012 | |||
8.2. Informative references | 11.2. Informative references | |||
[RFC1321] | [RFC1321] | |||
Rivest, R. and S. Dusse, "The MD5 Message-Digest Algorithm", RFC | Rivest, R. and S. Dusse, "The MD5 Message-Digest Algorithm", RFC | |||
1321, April 1992. | 1321, April 1992. | |||
[RFC2119] | [RFC2119] | |||
Bradner, S., "Key words for use in RFCs to Indicate Requirement | Bradner, S., "Key words for use in RFCs to Indicate Requirement | |||
Levels", RFC 2119, March, 1997. | Levels", RFC 2119, March, 1997. | |||
[RFC2866] | [RFC2866] | |||
Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. | Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. | |||
[RFC5176] | [RFC5176] | |||
Chiba, M. et al., "Dynamic Authorization Extensions to Remote | Chiba, M. et al., "Dynamic Authorization Extensions to Remote | |||
Authentication Dial In User Service (RADIUS)", RFC 5176, January | Authentication Dial In User Service (RADIUS)", RFC 5176, January | |||
2008. | 2008. | |||
[RFC6421] | ||||
Nelson, D. (Ed), "Crypto-Agility Requirements for Remote | ||||
Authentication Dial-In User Service (RADIUS)", RFC 6421, November | ||||
2011. | ||||
[MD5Attack] | [MD5Attack] | |||
Dobbertin, H., "The Status of MD5 After a Recent Attack", | Dobbertin, H., "The Status of MD5 After a Recent Attack", | |||
CryptoBytes Vol.2 No.2, Summer 1996. | CryptoBytes Vol.2 No.2, Summer 1996. | |||
[MD5Break] | [MD5Break] | |||
Wang, Xiaoyun and Yu, Hongbo, "How to Break MD5 and Other Hash | Wang, Xiaoyun and Yu, Hongbo, "How to Break MD5 and Other Hash | |||
Functions", EUROCRYPT. ISBN 3-540-25910-4, 2005. | Functions", EUROCRYPT. ISBN 3-540-25910-4, 2005. | |||
Acknowledgments | Acknowledgments | |||
End of changes. 70 change blocks. | ||||
172 lines changed or deleted | 421 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/ |