draft-ietf-radext-dtls-07.txt | draft-ietf-radext-dtls-08.txt | |||
---|---|---|---|---|
Network Working Group Alan DeKok | Network Working Group Alan DeKok | |||
INTERNET-DRAFT FreeRADIUS | INTERNET-DRAFT FreeRADIUS | |||
Category: Experimental | Category: Experimental | |||
<draft-ietf-radext-dtls-07.txt> | <draft-ietf-radext-dtls-08.txt> | |||
Expires: October 09, 2014 | Expires: September 24, 2014 | |||
9 October 2013 | 24 January 2014 | |||
DTLS as a Transport Layer for RADIUS | DTLS as a Transport Layer for RADIUS | |||
draft-ietf-radext-dtls-07 | draft-ietf-radext-dtls-08 | |||
Abstract | Abstract | |||
The RADIUS protocol [RFC2865] has limited support for authentication | The RADIUS protocol defined in RFC 2865 has limited support for | |||
and encryption of RADIUS packets. The protocol transports data "in | authentication and encryption of RADIUS packets. The protocol | |||
the clear", although some parts of the packets can have "obfuscated" | transports data in the clear, although some parts of the packets can | |||
content. Packets may be replayed verbatim by an attacker, and | have obfuscated content. Packets may be replayed verbatim by an | |||
client-server authentication is based on fixed shared secrets. This | attacker, and client-server authentication is based on fixed shared | |||
document specifies how the Datagram Transport Layer Security (DTLS) | secrets. This document specifies how the Datagram Transport Layer | |||
protocol may be used as a fix for these problems. It also describes | Security (DTLS) protocol may be used as a fix for these problems. It | |||
how implementations of this proposal can co-exist with current RADIUS | also describes how implementations of this proposal can co-exist with | |||
systems. | current RADIUS systems. | |||
Status of this Memo | Status of this Memo | |||
This Internet-Draft is submitted to IETF in full conformance with the | This Internet-Draft is submitted to IETF in full conformance with the | |||
provisions of BCP 78 and BCP 79. | provisions of BCP 78 and BCP 79. | |||
Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
Task Force (IETF), its areas, and its working groups. Note that | Task Force (IETF), its areas, and its working groups. Note that | |||
other groups may also distribute working documents as Internet- | other groups may also distribute working documents as Internet- | |||
Drafts. | Drafts. | |||
skipping to change at page 1, line 46 | skipping to change at page 1, line 46 | |||
and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
The list of current Internet-Drafts can be accessed at | The list of current Internet-Drafts can be accessed at | |||
http://www.ietf.org/ietf/1id-abstracts.txt. | http://www.ietf.org/ietf/1id-abstracts.txt. | |||
The list of Internet-Draft Shadow Directories can be accessed at | The list of Internet-Draft Shadow Directories can be accessed at | |||
http://www.ietf.org/shadow.html. | http://www.ietf.org/shadow.html. | |||
This Internet-Draft will expire on January 12, 2014 | This Internet-Draft will expire on September 24, 2014 | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2013 IETF Trust and the persons identified as the | Copyright (c) 2014 IETF Trust and the persons identified as the | |||
document authors. All rights reserved. | document authors. All rights reserved. | |||
This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
Provisions Relating to IETF Documents | Provisions Relating to IETF Documents | |||
(http://trustee.ietf.org/license-info/) in effect on the date of | (http://trustee.ietf.org/license-info/) in effect on the date of | |||
publication of this document. Please review these documents | publication of this document. Please review these documents | |||
carefully, as they describe your rights and restrictions with respect | carefully, as they describe your rights and restrictions with respect | |||
to this document. Code Components extracted from this document must | to this document. Code Components extracted from this document must | |||
include Simplified BSD License text as described in Section 4.e of | include Simplified BSD License text as described in Section 4.e of | |||
the Trust Legal Provisions and are provided without warranty as | the Trust Legal Provisions and are provided without warranty as | |||
described in the Simplified BSD License. | described in the Simplified BSD License. | |||
Table of Contents | Table of Contents | |||
1. Introduction ............................................. 4 | 1. Introduction ............................................. 4 | |||
1.1. Terminology ......................................... 4 | 1.1. Terminology ......................................... 4 | |||
1.2. Requirements Language ............................... 5 | 1.2. Requirements Language ............................... 5 | |||
1.3. Document Status ..................................... 5 | ||||
2. Building on Existing Foundations ......................... 6 | 2. Building on Existing Foundations ......................... 6 | |||
2.1. Changes to RADIUS ................................... 6 | 2.1. Changes to RADIUS ................................... 6 | |||
2.2. Similarities with RADIUS/TLS ........................ 7 | 2.2. Similarities with RADIUS/TLS ........................ 7 | |||
2.2.1. Changes from RADIUS/TLS to RADIUS/DTLS ......... 7 | 2.2.1. Changes from RADIUS/TLS to RADIUS/DTLS ......... 7 | |||
2.2.2. Reinforcement of RADIUS/TLS .................... 8 | ||||
3. Interaction with RADIUS/UDP .............................. 8 | 3. Interaction with RADIUS/UDP .............................. 8 | |||
3.1. DTLS Port and Packet Types .......................... 9 | 3.1. DTLS Port and Packet Types .......................... 9 | |||
3.2. Server Behavior ..................................... 9 | 3.2. Server Behavior ..................................... 9 | |||
4. Client Behavior .......................................... 10 | 4. Client Behavior .......................................... 10 | |||
5. Connection Management .................................... 10 | 5. Session Management ....................................... 10 | |||
5.1. Server Connection Management ........................ 10 | 5.1. Server Session Management ........................... 11 | |||
5.1.1. Session Management ............................. 11 | 5.1.1. Session Opening and Closing .................... 11 | |||
5.2. Client Connection Management ........................ 13 | 5.2. Client Session Management ........................... 13 | |||
6. Implementation Guidelines ................................ 14 | 6. Implementation Guidelines ................................ 14 | |||
6.1. Client Implementations .............................. 14 | 6.1. Client Implementations .............................. 15 | |||
6.2. Server Implementations .............................. 15 | 6.2. Server Implementations .............................. 16 | |||
7. Implementation Experience ................................ 15 | 7. Implementation Experience ................................ 16 | |||
8. Diameter Considerations .................................. 16 | 8. Diameter Considerations .................................. 16 | |||
9. IANA Considerations ...................................... 16 | 9. IANA Considerations ...................................... 17 | |||
10. Security Considerations ................................. 16 | 10. Security Considerations ................................. 17 | |||
10.1. Legacy RADIUS Security ............................. 17 | 10.1. Legacy RADIUS Security ............................. 18 | |||
10.2. Resource Exhaustion ................................ 18 | 10.2. Resource Exhaustion ................................ 18 | |||
10.3. Client-Server Authentication with DTLS ............. 18 | 10.3. Client-Server Authentication with DTLS ............. 19 | |||
10.4. Network Address Translation ........................ 20 | 10.4. Network Address Translation ........................ 20 | |||
10.5. Wildcard Clients ................................... 20 | 10.5. Wildcard Clients ................................... 21 | |||
10.6. Session Closing .................................... 20 | 10.6. Session Closing .................................... 21 | |||
10.7. Clients Subsystems ................................. 21 | 10.7. Client Subsystems .................................. 21 | |||
11. References .............................................. 21 | 11. References .............................................. 22 | |||
11.1. Normative references ............................... 21 | 11.1. Normative references ............................... 22 | |||
11.2. Informative references ............................. 22 | 11.2. Informative references ............................. 23 | |||
1. Introduction | 1. Introduction | |||
The RADIUS protocol as described in [RFC2865], [RFC2866], [RFC5176], | The RADIUS protocol as described in [RFC2865], [RFC2866], [RFC5176], | |||
and others has traditionally used methods based on MD5 [RFC1321] for | and others has traditionally used methods based on MD5 [RFC1321] for | |||
per-packet authentication and integrity checks. However, the MD5 | per-packet authentication and integrity checks. However, the MD5 | |||
algorithm has known weaknesses such as [MD5Attack] and [MD5Break]. | algorithm has known weaknesses such as [MD5Attack] and [MD5Break]. | |||
As a result, some specifications such as [RFC5176] have recommended | As a result, some specifications such as [RFC5176] have recommended | |||
using IPSec to secure RADIUS traffic. | using IPSec to secure RADIUS traffic. | |||
skipping to change at page 4, line 29 | skipping to change at page 4, line 29 | |||
is implicit in the network configuration, and is not enforced by the | is implicit in the network configuration, and is not enforced by the | |||
RADIUS application. | RADIUS application. | |||
This specification takes a different approach. We define a method | This specification takes a different approach. We define a method | |||
for using DTLS [RFC6347] as a RADIUS transport protocol. This | for using DTLS [RFC6347] as a RADIUS transport protocol. This | |||
approach has the benefit that the RADIUS application can directly | approach has the benefit that the RADIUS application can directly | |||
monitor and control the security policies associated with the traffic | monitor and control the security policies associated with the traffic | |||
that it processes. | that it processes. | |||
Another benefit is that RADIUS over DTLS continues to be a User | Another benefit is that RADIUS over DTLS continues to be a User | |||
Datagram Protocol (UDP) based protocol. This continuity ensures that | Datagram Protocol (UDP) based protocol. The change from RADIUS/UDP | |||
existing network-layer infrastructure (firewall rules, etc.) does not | is largely only to add TLS support. This allows implementations to | |||
need to be changed when RADIUS clients and servers are upgraded to | remain UDP based, without changing to a TCP architecture. | |||
support RADIUS over DTLS. It is RECOMMENDED that firewalls | ||||
performing packet inspection be configured to permit only DTLS over | ||||
the RADIUS/DTLS port. The alternative could be for then to either | ||||
block RADIUS/DTLS, or allow another, non-standard protocol. | ||||
This specification does not, however, solve all of the problems | This specification does not, however, solve all of the problems | |||
associated with RADIUS. The DTLS protocol does not add reliable or | associated with RADIUS. The DTLS protocol does not add reliable or | |||
in-order transport to RADIUS. DTLS also does not support | in-order transport to RADIUS. DTLS also does not support | |||
fragmentation of application-layer messages, or of the DTLS messages | fragmentation of application-layer messages, or of the DTLS messages | |||
themselves. This specification therefore shares with traditional | themselves. This specification therefore shares with traditional | |||
RADIUS the issues of order, reliability, and fragmentation. | RADIUS the issues of order, reliability, and fragmentation. These | |||
issues are dealt with in RADIUS/TCP [RFC6613] and RADIUS/TLS | ||||
[RFC6614]. | ||||
1.1. Terminology | 1.1. Terminology | |||
This document uses the following terms: | This document uses the following terms: | |||
RADIUS/DTLS | RADIUS/DTLS | |||
This term is a short-hand for "RADIUS over DTLS". | This term is a short-hand for "RADIUS over DTLS". | |||
RADIUS/DTLS client | RADIUS/DTLS client | |||
This term refers both to RADIUS clients as defined in [RFC2865], | This term refers both to RADIUS clients as defined in [RFC2865], | |||
skipping to change at page 6, line 5 | skipping to change at page 5, line 28 | |||
further processing. | further processing. | |||
1.2. Requirements Language | 1.2. Requirements Language | |||
In this document, several words are used to signify the requirements | In this document, several words are used to signify the requirements | |||
of the specification. The key words "MUST", "MUST NOT", "REQUIRED", | of the specification. The key words "MUST", "MUST NOT", "REQUIRED", | |||
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", | "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", | |||
and "OPTIONAL" in this document are to be interpreted as described in | and "OPTIONAL" in this document are to be interpreted as described in | |||
[RFC2119]. | [RFC2119]. | |||
1.3. Document Status | ||||
This document is an Experimental RFC. Please see [RFC6614] Section | ||||
1.3 for a discussion of the issues surrounding the use of TLS with | ||||
RADIUS. | ||||
2. Building on Existing Foundations | 2. Building on Existing Foundations | |||
Adding DTLS as a RADIUS transport protocol requires a number of | Adding DTLS as a RADIUS transport protocol requires a number of | |||
changes to systems implementing standard RADIUS. This section | changes to systems implementing standard RADIUS. This section | |||
outlines those changes, and defines new behaviors necessary to | outlines those changes, and defines new behaviors necessary to | |||
implement DTLS. | implement DTLS. | |||
2.1. Changes to RADIUS | 2.1. Changes to RADIUS | |||
The RADIUS packet format is unchanged from [RFC2865], [RFC2866], and | The RADIUS packet format is unchanged from [RFC2865], [RFC2866], and | |||
skipping to change at page 6, line 44 | skipping to change at page 6, line 44 | |||
packet to a DTLS layer for encapsulation. DTLS then acts as a | packet to a DTLS layer for encapsulation. DTLS then acts as a | |||
transport layer for RADIUS, hence the names "RADIUS/UDP" and | transport layer for RADIUS, hence the names "RADIUS/UDP" and | |||
"RADIUS/DTLS". | "RADIUS/DTLS". | |||
The requirement that RADIUS remain largely unchanged ensures the | The requirement that RADIUS remain largely unchanged ensures the | |||
simplest possible implementation and widest interoperability of this | simplest possible implementation and widest interoperability of this | |||
specification. | specification. | |||
We note that the DTLS encapsulation of RADIUS means that RADIUS | We note that the DTLS encapsulation of RADIUS means that RADIUS | |||
packets have an additional overhead due to DTLS. Implementations | packets have an additional overhead due to DTLS. Implementations | |||
MUST support encapsulated RADIUS packets of 4096 in length, with a | MUST support sending and receiving encapsulated RADIUS packets of | |||
corresponding increase in the maximum size of the encapsulated DTLS | 4096 octets in length, with a corresponding increase in the maximum | |||
packets. This larger packet size may cause the packet to be larger | size of the encapsulated DTLS packets. This larger packet size may | |||
than the Path MTU (PMTU), where a RADIUS/UDP packet may be smaller. | cause the packet to be larger than the Path MTU (PMTU), where a | |||
See Section 5.2, below, for more discussion. | RADIUS/UDP packet may be smaller. See Section 5.2, below, for more | |||
discussion. | ||||
The only changes made from RADIUS/UDP to RADIUS/DTLS are the | The only changes made from RADIUS/UDP to RADIUS/DTLS are the | |||
following two items: | following two items: | |||
(1) The Length checks defined in [RFC2865] Section 3 MUST use the | (1) The Length checks defined in [RFC2865] Section 3 MUST use the | |||
length of the decrypted DTLS data instead of the UDP packet | length of the decrypted DTLS data instead of the UDP packet | |||
length. | length. They MUST treat any decrypted DTLS data octets outside | |||
the range of the Length field as padding, and ignore it on | ||||
reception. | ||||
(2) The shared secret secret used to compute the MD5 integrity | (2) The shared secret secret used to compute the MD5 integrity | |||
checks and the attribute encryption MUST be "radius/dtls". | checks and the attribute encryption MUST be "radius/dtls". | |||
All other aspects of RADIUS are unchanged. | All other aspects of RADIUS are unchanged. | |||
2.2. Similarities with RADIUS/TLS | 2.2. Similarities with RADIUS/TLS | |||
While this specification can be thought of as RADIUS/TLS over UDP | While this specification can be thought of as RADIUS/TLS over UDP | |||
instead of the Transmission Control Protocol (TCP), there are some | instead of the Transmission Control Protocol (TCP), there are some | |||
skipping to change at page 8, line 8 | skipping to change at page 8, line 10 | |||
Most of Section 2.3 applies also to RADIUS/DTLS. Item (1) should be | Most of Section 2.3 applies also to RADIUS/DTLS. Item (1) should be | |||
interpreted as applying to DTLS session initiation, instead of TCP | interpreted as applying to DTLS session initiation, instead of TCP | |||
connection establishment. Item (2) applies, except for the | connection establishment. Item (2) applies, except for the | |||
recommendation that implementations "SHOULD" support | recommendation that implementations "SHOULD" support | |||
TLS_RSA_WITH_RC4_128_SHA. This recommendation is a historical | TLS_RSA_WITH_RC4_128_SHA. This recommendation is a historical | |||
artifact of RADIUS/TLS, and does not apply to RADIUS/DTLS. Item (3) | artifact of RADIUS/TLS, and does not apply to RADIUS/DTLS. Item (3) | |||
applies to RADIUS/DTLS. Item (4) applies, except that the fixed | applies to RADIUS/DTLS. Item (4) applies, except that the fixed | |||
shared secret is "radius/dtls", as described above. | shared secret is "radius/dtls", as described above. | |||
Section 2.4 applies to RADIUS/DTLS. Client identities SHOULD be | Section 2.4 applies to RADIUS/DTLS. Client identities SHOULD be | |||
determined from TLS parameters, instead of relying solely on the | determined from DTLS parameters, instead of relying solely on the | |||
source IP address of the packet. | source IP address of the packet. | |||
Section 2.5 does not apply to RADIUS/DTLS. The relationship between | Section 2.5 does not apply to RADIUS/DTLS. The relationship between | |||
RADIUS packet codes and UDP ports in RADIUS/DTLS is unchanged from | RADIUS packet codes and UDP ports in RADIUS/DTLS is unchanged from | |||
RADIUS/UDP. | RADIUS/UDP. | |||
Sections 3.1, 3.2, and 3.3 apply to RADIUS/DTLS. | Sections 3.1, 3.2, and 3.3 apply to RADIUS/DTLS. | |||
Section 3.4 item (1) does not apply to RADIUS/DTLS. Each RADIUS | Section 3.4 item (1) does not apply to RADIUS/DTLS. Each RADIUS | |||
packet is encapsulated in one DTLS packet, and there is no "stream" | packet is encapsulated in one DTLS packet, and there is no "stream" | |||
skipping to change at page 8, line 30 | skipping to change at page 8, line 32 | |||
the requirements of [RFC2865] Section 3 for the RADIUS Length field, | the requirements of [RFC2865] Section 3 for the RADIUS Length field, | |||
using the length of the decrypted DTLS data for the checks. This | using the length of the decrypted DTLS data for the checks. This | |||
check replaces the RADIUS method of using the length field from the | check replaces the RADIUS method of using the length field from the | |||
UDP packet. | UDP packet. | |||
Section 3.4 items (2), (3), (4), and (5) apply to RADIUS/DTLS. | Section 3.4 items (2), (3), (4), and (5) apply to RADIUS/DTLS. | |||
Section 4 does not apply to RADIUS/DTLS. Protocol compatibility | Section 4 does not apply to RADIUS/DTLS. Protocol compatibility | |||
considerations are defined in this document. | considerations are defined in this document. | |||
2.2.2. Reinforcement of RADIUS/TLS | Section 6 applies to RADIUS/DTLS. | |||
We re-iterate that much of [RFC6614] applies to this document. | ||||
Specifically, Section 4 and Section 6 of that document are applicable | ||||
to RADIUS/DTLS. | ||||
3. Interaction with RADIUS/UDP | 3. Interaction with RADIUS/UDP | |||
Transitioning to DTLS is a process which needs to be done carefully. | Transitioning to DTLS is a process which needs to be done carefully. | |||
A poorly handled transition is complex for administrators, and | A poorly handled transition is complex for administrators, and | |||
potentially subject to security downgrade attacks. It is not | potentially subject to security downgrade attacks. It is not | |||
sufficient to just disable RADIUS/UDP and enable RADIUS/DTLS. That | sufficient to just disable RADIUS/UDP and enable RADIUS/DTLS. RADIUS | |||
approach would result in timeouts, lost traffic, and network | has no provisions for protocol negotiation, so simply disabling | |||
RADIUS/UDP would result in timeouts, lost traffic, and network | ||||
instabilities. | instabilities. | |||
The end result of this specification is that nearly all RADIUS/UDP | The end result of this specification is that nearly all RADIUS/UDP | |||
implementations should transition to using a secure alternative. In | implementations should transition to using a secure alternative. In | |||
some cases, RADIUS/UDP may remain where IPSec is used as a transport, | some cases, RADIUS/UDP may remain where IPSec is used as a transport, | |||
or where implementation and/or business reasons preclude a change. | or where implementation and/or business reasons preclude a change. | |||
However, long-term use of RADIUS/UDP is NOT RECOMMENDED. | However, long-term use of RADIUS/UDP is not recommended. | |||
This section describes how clients and servers should use | This section describes how clients and servers should use | |||
RADIUS/DTLS, and how it interacts with RADIUS/UDP. | RADIUS/DTLS, and how it interacts with RADIUS/UDP. | |||
3.1. DTLS Port and Packet Types | 3.1. DTLS Port and Packet Types | |||
The default destination port number for RADIUS/DTLS is UDP/2083. | The default destination port number for RADIUS/DTLS is UDP/2083. | |||
There are no separate ports for authentication, accounting, and | There are no separate ports for authentication, accounting, and | |||
dynamic authorization changes. The source port is arbitrary. The | dynamic authorization changes. The source port is arbitrary. The | |||
text above in Section 2.2.1 describes issues surrounding the use of | text above in [RFC6614] Section 3.4 describes issues surrounding the | |||
one port for multiple packet types, by referencing [RFC6614] Section | use of one port for multiple packet types. We recognize that | |||
3.4. | implementations may allow the the use of RADIUS/DTLS over non- | |||
standard ports. In that case, the references to UDP/2083 in this | ||||
document should be read as applying to any port used for transport of | ||||
RADIUS/DTLS traffic. | ||||
3.2. Server Behavior | 3.2. Server Behavior | |||
When a server receives packets on UDP/2083, all packets MUST be | When a server receives packets on UDP/2083, all packets MUST be | |||
treated as being DTLS. RADIUS/UDP packets MUST NOT be accepted on | treated as being DTLS. RADIUS/UDP packets MUST NOT be accepted on | |||
this port. | this port. | |||
Servers MUST NOT accept DTLS packets on the old RADIUS/UDP ports. | Servers MUST NOT accept DTLS packets on the old RADIUS/UDP ports. | |||
Early drafts of this specification permitted this behavior. It is | Early drafts of this specification permitted this behavior. It is | |||
forbidden here, as it depended on behavior in DTLS which may change | forbidden here, as it depended on behavior in DTLS which may change | |||
skipping to change at page 10, line 13 | skipping to change at page 10, line 13 | |||
traffic to downbidding attacks, and is NOT RECOMMENDED. | traffic to downbidding attacks, and is NOT RECOMMENDED. | |||
4. Client Behavior | 4. Client Behavior | |||
When a client sends packets to the assigned RADIUS/DTLS port, all | When a client sends packets to the assigned RADIUS/DTLS port, all | |||
packets MUST be DTLS. RADIUS/UDP packets MUST NOT be sent to this | packets MUST be DTLS. RADIUS/UDP packets MUST NOT be sent to this | |||
port. | port. | |||
RADIUS/DTLS clients SHOULD NOT probe servers to see if they support | RADIUS/DTLS clients SHOULD NOT probe servers to see if they support | |||
DTLS transport. Instead, clients SHOULD use DTLS as a transport | DTLS transport. Instead, clients SHOULD use DTLS as a transport | |||
layer only when administratively configured. | layer only when administratively configured. If a client is | |||
configured to use DTLS and the server appears to be unresponsive, the | ||||
client MUST NOT fall back to using RADIUS/UDP. Instead, the client | ||||
should treat the server as being down. | ||||
RADIUS clients often had multiple independent RADIUS implementations, | RADIUS clients often had multiple independent RADIUS implementations | |||
or processes that originate packets. This practice was simple to | and/or processes that originate packets. This practice was simple to | |||
implement, but means that each independent subsystem must | implement, but the result is that each independent subsystem must | |||
independently discover network issues or server failures. It is | independently discover network issues or server failures. It is | |||
therefore RECOMMENDED that clients use a local proxy as described in | therefore RECOMMENDED that clients use a local proxy as described in | |||
Section 6.1, below. | Section 6.1, below. | |||
Clients may implement "pools" of servers for fail-over or load- | Clients may implement "pools" of servers for fail-over or load- | |||
balancing. These pools SHOULD NOT mix RADIUS/UDP and RADIUS/DTLS | balancing. These pools SHOULD NOT mix RADIUS/UDP and RADIUS/DTLS | |||
servers. | servers. | |||
5. Connection Management | 5. Session Management | |||
Where [RFC6614] can rely on the TCP state machine to perform | Where [RFC6614] can rely on the TCP state machine to perform session | |||
connection tracking, this specification cannot. As a result, | tracking, this specification cannot. As a result, implementations of | |||
implementations of this specification may need to perform connection | this specification may need to perform session management of the DTLS | |||
management of the DTLS session in the application layer. This | session in the application layer. This section describes logically | |||
section describes logically how this tracking is done. | how this tracking is done. Implementations may choose to use the | |||
Implementations may choose to use the method described here, or | method described here, or another, equivalent method. | |||
another, equivalent method. | ||||
We note that [RFC5080] Section 2.2.2 already mandates a duplicate | We note that [RFC5080] Section 2.2.2 already mandates a duplicate | |||
detection cache. The connection tracking described below can be seen | detection cache. The session tracking described below can be seen as | |||
as an extension of that cache, where entries contain DTLS sessions | an extension of that cache, where entries contain DTLS sessions | |||
instead of RADIUS/UDP packets. | instead of RADIUS/UDP packets. | |||
[RFC5080] section 2.2.2 describes how duplicate RADIUS/UDP requests | [RFC5080] section 2.2.2 describes how duplicate RADIUS/UDP requests | |||
result in the retransmission of a previously cached RADIUS/UDP | result in the retransmission of a previously cached RADIUS/UDP | |||
response. Due to DTLS sequence window requirements, a server MUST | response. Due to DTLS sequence window requirements, a server MUST | |||
NOT retransmit a previously sent DTLS packet. Instead, it should | NOT retransmit a previously sent DTLS packet. Instead, it should | |||
cache the RADIUS response packet, and re-process it through DTLS to | cache the RADIUS response packet, and re-process it through DTLS to | |||
create a new RADIUS/DTLS packet, every time it is necessary to | create a new RADIUS/DTLS packet, every time it is necessary to | |||
retransmit a RADIUS response. | retransmit a RADIUS response. | |||
5.1. Server Connection Management | 5.1. Server Session Management | |||
A RADIUS/DTLS server MUST track ongoing DTLS client connections based | A RADIUS/DTLS server MUST track ongoing DTLS client session based the | |||
the following 4-tuple: | following 4-tuple: | |||
* source IP address | * source IP address | |||
* source port | * source port | |||
* destination IP address | * destination IP address | |||
* destination port | * destination port | |||
Note that this 4-tuple is independent of IP address version (IPv4 or | Note that this 4-tuple is independent of IP address version (IPv4 or | |||
IPv6). | IPv6). | |||
Each entry associated with a 4-tuple contains the following | Each 4-tuple points to a unique session entry, which contains the | |||
information: | following information: | |||
DTLS Data | DTLS Data | |||
An implementation-specific variable containing information about | An implementation-specific variable containing information about | |||
the active DTLS connection. | the active DTLS session. | |||
Last Taffic | Last Taffic | |||
A variable containing a timestamp which indicates when this | A variable containing a timestamp which indicates when this session | |||
connection last received valid traffic. | last received valid traffic. | |||
Each entry may contain other information, such as idle timeouts, | Each entry may contain other information, such as idle timeouts, | |||
connection lifetimes, and other implementation-specific data. | session lifetimes, and other implementation-specific data. | |||
5.1.1. Session Management | 5.1.1. Session Opening and Closing | |||
Session tracking is subject to Denial of Service (DoS) attacks due to | Session tracking is subject to Denial of Service (DoS) attacks due to | |||
the ability of an attacker to forge UDP traffic. RADIUS/DTLS servers | the ability of an attacker to forge UDP traffic. RADIUS/DTLS servers | |||
SHOULD use the stateless cookie tracking technique described in | SHOULD use the stateless cookie tracking technique described in | |||
[RFC6347] Section 4.2.1. DTLS sessions SHOULD NOT be tracked until a | [RFC6347] Section 4.2.1. DTLS sessions SHOULD NOT be tracked until a | |||
ClientHello packet has been received with an appropriate Cookie | ClientHello packet has been received with an appropriate Cookie | |||
value. Server implementation SHOULD have a way of tracking partially | value. Server implementation SHOULD have a way of tracking partially | |||
setup DTLS connections. Servers SHOULD limit both the number and | setup DTLS sessions. Servers SHOULD limit both the number and impact | |||
impact on resources of partial connections. | on resources of partial sessions. | |||
Sessions (both 4-tuple and entry) MUST be deleted when a TLS Closure | Sessions (both 4-tuple and entry) MUST be deleted when a TLS Closure | |||
Alert ([RFC5246] Section 7.2.1) or a fatal TLS Error Alert ([RFC5246] | Alert ([RFC5246] Section 7.2.1) or a fatal TLS Error Alert ([RFC5246] | |||
Section 7.2.2) is received. When a session is deleted due to it | Section 7.2.2) is received. When a session is deleted due to it | |||
failing security requirements, the DTLS session MUST be closed, and | failing security requirements, the DTLS session MUST be closed, and | |||
any TLS session resumption parameters for that session MUST be | any TLS session resumption parameters for that session MUST be | |||
discarded, and all tracking information MUST be deleted. | discarded, and all tracking information MUST be deleted. | |||
Sessions MUST also be deleted when a RADIUS packet fails validation | Sessions MUST also be deleted when a RADIUS packet fails validation | |||
due to a packet being malformed, or when it has an invalid Message- | due to a packet being malformed, or when it has an invalid Message- | |||
Authenticator, or invalid Request Authenticator. There are other | Authenticator, or invalid Request Authenticator. There are other | |||
cases when the specifications require that a packet received via a | cases when the specifications require that a packet received via a | |||
DTLS session be "silently discarded". In those cases, | DTLS session be "silently discarded". In those cases, | |||
implementations MAY delete the underlying session as described above. | implementations MAY delete the underlying session as described above. | |||
There are few reasons to communicate with a NAS which is not | There are few reasons to communicate with a NAS which is not | |||
implementing RADIUS. | implementing RADIUS. | |||
The above paragraph can be rephrased more generically. A session | The above paragraph can be rephrased more generically. A session | |||
MUST be deleted when non-RADIUS traffic is received over it. This | MUST be deleted when non-RADIUS traffic is received over it. This | |||
specification is for RADIUS, and there is no reason to allow non- | specification is for RADIUS, and there is no reason to allow non- | |||
RADIUS traffic over a RADIUS/DTLS connection. A session MUST be | RADIUS traffic over a RADIUS/DTLS session. A session MUST be deleted | |||
deleted when RADIUS traffic fails to pass security checks. There is | when RADIUS traffic fails to pass security checks. There is no | |||
no reason to permit insecure networks. A session SHOULD NOT be | reason to permit insecure networks. A session SHOULD NOT be deleted | |||
deleted when a well-formed, but "unexpected" RADIUS packet is | when a well-formed, but "unexpected" RADIUS packet is received over | |||
received over it. Future specifications may extend RADIUS/DTLS, and | it. Future specifications may extend RADIUS/DTLS, and we do not want | |||
we do not want to forbid those specifications. | to forbid those specifications. | |||
Once a DTLS session is established, a RADIUS/DTLS server SHOULD use | Once a DTLS session is established, a RADIUS/DTLS server SHOULD use | |||
DTLS Heartbeats [RFC6520] to determine connectivity between the two | DTLS Heartbeats [RFC6520] to determine connectivity between the two | |||
servers. A server SHOULD also use watchdog packets from the client | servers. A server SHOULD also use watchdog packets from the client | |||
to determine that the connection is still active. | to determine that the session is still active. | |||
As UDP does not guarantee delivery of messages, RADIUS/DTLS servers | As UDP does not guarantee delivery of messages, RADIUS/DTLS servers | |||
which do not implement an application-layer watchdog MUST also | which do not implement an application-layer watchdog MUST also | |||
maintain a "Last Traffic" timestamp per DTLS session. The timestamp | maintain a "Last Traffic" timestamp per DTLS session. The timestamp | |||
SHOULD be updated on reception of a valid RADIUS/DTLS packet, or a | SHOULD be updated on reception of a valid RADIUS/DTLS packet, or a | |||
DTLS heartbeat. The timestamp MUST NOT be updated in other | DTLS heartbeat. The timestamp MUST NOT be updated in other | |||
situations. When a session has not received a packet for a period of | situations. When a session has not received a packet for a period of | |||
time, it is labelled "idle". The server SHOULD delete idle DTLS | time, it is labelled "idle". The server SHOULD delete idle DTLS | |||
sessions after an "idle timeout". The server MAY cache the TLS | sessions after an "idle timeout". The server MAY cache the TLS | |||
session parameters, in order to provide for fast session resumption. | session parameters, in order to provide for fast session resumption. | |||
This session "idle timeout" SHOULD be exposed to the administrator as | This session "idle timeout" SHOULD be exposed to the administrator as | |||
a configurable setting. It SHOULD NOT be set to less than 60 | a configurable setting. It SHOULD NOT be set to less than 60 | |||
seconds, and SHOULD NOT be set to more than 600 seconds (10 minutes). | seconds, and SHOULD NOT be set to more than 600 seconds (10 minutes). | |||
The minimum value useful value for this timer is determined by the | The minimum value useful value for this timer is determined by the | |||
application-layer watchdog mechanism defined in the following | application-layer watchdog mechanism defined in the following | |||
section. | section. | |||
RADIUS/DTLS servers SHOULD also monitor the total number of sessions | RADIUS/DTLS servers SHOULD also monitor the total number of open | |||
they are tracking. They SHOULD stop the creating of new sessions | sessions. They SHOULD have a "maximum sessions" setting exposed to | |||
when a large number are already being tracked. This "maximum | administrators as a configurable parameter. When this maximum is | |||
sessions" number SHOULD be exposed to administrators as a | reached and a new session is started, the server MUST either drop an | |||
configurable setting. | old session in order to open the new one, or instead not create a new | |||
session. | ||||
RADIUS/DTLS servers SHOULD implement session resumption, preferably | RADIUS/DTLS servers SHOULD implement session resumption, preferably | |||
stateless session resumption as given in [RFC5077]. This practice | stateless session resumption as given in [RFC5077]. This practice | |||
lowers the time and effort required to start a DTLS session with a | lowers the time and effort required to start a DTLS session with a | |||
client, and increases network responsiveness. | client, and increases network responsiveness. | |||
Since UDP is stateless, the potential exists for the client to | Since UDP is stateless, the potential exists for the client to | |||
initiate a new DTLS session using a particular 4-tuple, before the | initiate a new DTLS session using a particular 4-tuple, before the | |||
server has closed the old session. For security reasons, the server | server has closed the old session. For security reasons, the server | |||
must keep the old session active until it has received secure | MUST keep the old session active until either it has received secure | |||
notification from the client that the session is closed. Or, when | notification from the client that the session is closed, or when the | |||
the server has decided for itself that the session is closed. Taking | server decides to close the session based on idle timeouts. Taking | |||
any other action would permit unauthenticated clients to perform a | any other action would permit unauthenticated clients to perform a | |||
DoS attack, by closing active DTLS session. | DoS attack, by re-using a 4-tuple, and thus causing the server to | |||
close an active (and authenticated) DTLS session. | ||||
As a result, servers MUST ignore any attempts to re-use an existing | As a result, servers MUST ignore any attempts to re-use an existing | |||
4-tuple from an active session. This requirement can likely be | 4-tuple from an active session. This requirement can likely be | |||
reached by simply processing the packet through the existing session, | reached by simply processing the packet through the existing session, | |||
as with any other packet received via that 4-tuple. Non-compliant, | as with any other packet received via that 4-tuple. Non-compliant, | |||
or unexpected packets will be ignored by the DTLS layer. | or unexpected packets will be ignored by the DTLS layer. | |||
The above requirement is mitigated by the suggestion in Section 6.1, | The above requirement is mitigated by the suggestion in Section 6.1, | |||
below, that the client use a local proxy for all RADIUS traffic. | below, that the client use a local proxy for all RADIUS traffic. | |||
That proxy can then track the ports which it uses, and ensure that | That proxy can then track the ports which it uses, and ensure that | |||
re-use of 4-tuples is avoided. The exact process by which this | re-use of 4-tuples is avoided. The exact process by which this | |||
tracking is done is outside of the scope of this document. | tracking is done is outside of the scope of this document. | |||
5.2. Client Connection Management | 5.2. Client Session Management | |||
Clients SHOULD use PMTU discovery [RFC6520] to determine the PMTU | Clients SHOULD use PMTU discovery [RFC6520] to determine the PMTU | |||
between the client and server, prior to sending any RADIUS traffic. | between the client and server, prior to sending any RADIUS traffic. | |||
Once a DTLS session is established, a RADIUS/DTLS client SHOULD use | Once a DTLS session is established, a RADIUS/DTLS client SHOULD use | |||
DTLS Heartbeats [RFC6520] to determine connectivity between the two | DTLS Heartbeats [RFC6520] to determine connectivity between the two | |||
systems. Alternatively, RADIUS/DTLS clients may use the application- | systems. RADIUS/DTLS clients SHOULD also use the application-layer | |||
layer watchdog algorithm defined in [RFC3539] to determine server | watchdog algorithm defined in [RFC3539] to determine server | |||
responsiveness. The Status-Server packet defined in [RFC5997] SHOULD | responsiveness. The Status-Server packet defined in [RFC5997] SHOULD | |||
be used as the "watchdog packet" in any application-layer watchdog | be used as the "watchdog packet" in any application-layer watchdog | |||
algorithm. | algorithm. | |||
RADIUS/DTLS clients SHOULD pro-actively close sessions when they have | RADIUS/DTLS clients SHOULD pro-actively close sessions when they have | |||
been idle for a period of time. Clients SHOULD close a session when | been idle for a period of time. Clients SHOULD close a session when | |||
the DTLS Heartbeat algorithm indicates that the session is no longer | the DTLS Heartbeat algorithm indicates that the session is no longer | |||
active. Clients SHOULD close a session when no traffic other than | active. Clients SHOULD close a session when no traffic other than | |||
watchdog packets and (possibly) watchdog responses have been sent for | watchdog packets and (possibly) watchdog responses have been sent for | |||
three watchdog timeouts. This behavior ensures that clients do not | three watchdog timeouts. This behavior ensures that clients do not | |||
waste resources on the server by causing it to track idle sessions. | waste resources on the server by causing it to track idle sessions. | |||
A client may choose to avoid DTLS heartbeats and watchdog packets | When client fails to implement both DTLS heartbeats and watchdog | |||
entirely. However, DTLS provides no signal that a session has been | packets, it has no way of knowing that a DTLS session has been | |||
closed. There is therefore the possibility that the server closes | closed. There is therefore the possibility that the server closes | |||
the session without the client knowing. When that happens, the | the session without the client knowing. When that happens, the | |||
client may later transmit packets in a session, and those packets | client may later transmit packets in a session, and those packets | |||
will be ignored by the server. The client is then forced to time out | will be ignored by the server. The client is then forced to time out | |||
those packets and then the session, leading to delays and network | those packets and then the session, leading to delays and network | |||
instabilities. | instabilities. | |||
For these reasons, it is RECOMMENDED that RADIUS/DTLS clients | For these reasons, it is RECOMMENDED that RADIUS/DTLS clients | |||
implement DTLS heartbeats and/or watchdog packets for all DTLS | implement DTLS heartbeats and/or watchdog packets for all DTLS | |||
sessions. | sessions. | |||
DTLS sessions MUST also be deleted when a RADIUS packet fails | DTLS sessions MUST also be deleted when a RADIUS packet fails | |||
validation due to a packet being malformed, or when it has an invalid | validation due to a packet being malformed, or when it has an invalid | |||
Message-Authenticator, or invalid Response Authenticator. There are | Message-Authenticator, or invalid Response Authenticator. There are | |||
other cases when the specifications require that a packet received | other cases when the specifications require that a packet received | |||
via a DTLS session be "silently discarded". In those cases, | via a DTLS session be "silently discarded". In those cases, | |||
implementations MAY delete the underlying DTLS session. | implementations MAY delete the underlying DTLS session. | |||
RADIUS/DTLS clients SHOULD NOT send both RADIUS/UDP and RADIUS/DTLS | RADIUS/DTLS clients should not send both RADIUS/UDP and RADIUS/DTLS | |||
packets to different servers from the same source socket. This | packets to different servers from the same source socket. This | |||
practice causes increased complexity in the client application, and | practice causes increased complexity in the client application, and | |||
increases the potential for security breaches due to implementation | increases the potential for security breaches due to implementation | |||
issues. | issues. | |||
RADIUS/DTLS clients SHOULD implement session resumption, preferably | RADIUS/DTLS clients SHOULD implement session resumption, preferably | |||
stateless session resumption as given in [RFC5077]. This practice | stateless session resumption as given in [RFC5077]. This practice | |||
lowers the time and effort required to start a DTLS session with a | lowers the time and effort required to start a DTLS session with a | |||
server, and increases network responsiveness. | server, and increases network responsiveness. | |||
skipping to change at page 14, line 39 | skipping to change at page 14, line 47 | |||
Where a TLS pre-shared key (PSK) method is used, implementations MUST | Where a TLS pre-shared key (PSK) method is used, implementations MUST | |||
support keys of at least 16 octets in length. Implementations SHOULD | support keys of at least 16 octets in length. Implementations SHOULD | |||
support key lengths of 32 octets, and SHOULD allow for longer keys. | support key lengths of 32 octets, and SHOULD allow for longer keys. | |||
The key data MUST be capable of being any value (0 through 255, | The key data MUST be capable of being any value (0 through 255, | |||
inclusive). Implementations MUST NOT limit themselves to using | inclusive). Implementations MUST NOT limit themselves to using | |||
textual keys. It is RECOMMENDED that the administration interface | textual keys. It is RECOMMENDED that the administration interface | |||
allows for the keys to be entered as humanly readable strings in hex | allows for the keys to be entered as humanly readable strings in hex | |||
format. | format. | |||
It is RECOMMENDED that keys be derived from a cryptographically | When creating keys, it is RECOMMENDED that keys be derived from a | |||
secure pseudo-random number generator (CSPRNG). If managing keys is | cryptographically secure pseudo-random number generator (CSPRNG) | |||
too complicated, a certificate-based TLS method SHOULD be used | instead of allowing administrators to invent "secure" keys on theur | |||
instead. | own. If managing keys is too complicated, a certificate-based TLS | |||
method SHOULD be used instead. | ||||
6.1. Client Implementations | 6.1. Client Implementations | |||
RADIUS/DTLS clients SHOULD use connected sockets where possible. Use | RADIUS/DTLS clients should use connected sockets where possible. Use | |||
of connected sockets means that the underlying kernel tracks the | of connected sockets means that the underlying kernel tracks the | |||
sessions, so that the client subsystem does not need to. It is a | sessions, so that the client subsystem does not need to multiple | |||
good idea to leverage existing functionality. | multiple sessions on one socket. | |||
RADIUS/DTLS clients SHOULD use one source when sending packets to a | RADIUS/DTLS clients should use a single source (IP + port) when | |||
particular RADIUS/DTLS server. Doing so minimizes the number of DTLS | sending packets to a particular RADIUS/DTLS server. Doing so | |||
session setups. It also ensures that information about the home | minimizes the number of DTLS session setups. It also ensures that | |||
server state is discovered only once. | information about the home server state is discovered only once. | |||
In practice, this means that RADIUS/DTLS clients SHOULD use a local | In practice, this means that RADIUS/DTLS clients with multiple | |||
proxy which arbitrates all RADIUS traffic between the client and all | internal RADIUS sources should use a local proxy which arbitrates all | |||
servers. The proxy SHOULD accept traffic only from the authorized | RADIUS traffic between the client and all servers. The proxy should | |||
subsystems on the client machine, and SHOULD proxy that traffic to | accept traffic only from the authorized subsystems on the client | |||
known servers. Each authorized subsystem SHOULD include an attribute | machine, and should proxy that traffic to known servers. Each | |||
which uniquely identifies that subsystem to the proxy, so that the | authorized subsystem should include an attribute which uniquely | |||
proxy can apply origin-specific proxy rules and security policies. | identifies that subsystem to the proxy, so that the proxy can apply | |||
We suggest using NAS-Identifier for this purpose. | origin-specific proxy rules and security policies. We suggest using | |||
NAS-Identifier for this purpose. | ||||
The local proxy SHOULD be able to interact with multiple servers at | The local proxy should be able to interact with multiple servers at | |||
the same time. There is no requirement that each server have its own | the same time. There is no requirement that each server have its own | |||
unique proxy on the client, as that would be inefficient. | unique proxy on the client, as that would be inefficient. | |||
The suggestion to use a local proxy means that there is only one | ||||
process which discovers network and/or connectivity issues with a | ||||
server. If each client subsystem communicated directly with a | ||||
server, issues with that server would have to be discovered | ||||
independently by each subsystem. The side effect would be increased | ||||
delays in re-routing traffic, error reporting, and network | ||||
instabilities. | ||||
Each client subsystem can include a subsystem-specific NAS-Identifier | Each client subsystem can include a subsystem-specific NAS-Identifier | |||
in each request. The format of this attribute is implementation- | in each request. The format of this attribute is implementation- | |||
specific. The proxy SHOULD verify that the request originated from | specific. The proxy should verify that the request originated from | |||
the local system, ideally via a loopback address. The proxy MUST | the local system, ideally via a loopback address. The proxy MUST | |||
then re-write any subsystem-specific NAS-Identifier to a NAS- | then re-write any subsystem-specific NAS-Identifier to a NAS- | |||
Identifier which identifies the client as a whole. Or, remove NAS- | Identifier which identifies the client as a whole. Or, remove NAS- | |||
Identifier entirely and replace it with NAS-IP-Address or NAS- | Identifier entirely and replace it with NAS-IP-Address or NAS- | |||
IPv6-Address. | IPv6-Address. | |||
In traditional RADIUS, the cost to set up a new "session" between a | In traditional RADIUS, the cost to set up a new "session" between a | |||
client and server was minimal. The client subsystem could simply | client and server was minimal. The client subsystem could simply | |||
open a port, send a packet, wait for the response, and the close the | open a port, send a packet, wait for the response, and the close the | |||
port. With RADIUS/DTLS, the connection setup is significantly more | port. With RADIUS/DTLS, the connection setup is significantly more | |||
expensive. In addition, there may be a requirement to use DTLS in | expensive. In addition, there may be a requirement to use DTLS in | |||
order to communicate with a server, as RADIUS/UDP may not be | order to communicate with a server, as RADIUS/UDP may not be | |||
supported by that server. The knowledge of what protocol to use is | supported by that server. The knowledge of what protocol to use is | |||
best managed by a dedicated RADIUS subsystem, rather than by each | best managed by a dedicated RADIUS subsystem, rather than by each | |||
individual subsystem on the client. | individual subsystem on the client. | |||
6.2. Server Implementations | 6.2. Server Implementations | |||
RADIUS/DTLS servers SHOULD NOT use connected sockets to read DTLS | RADIUS/DTLS servers should not use connected sockets to read DTLS | |||
packets from a client. This recommendation is because a connected | packets from a client. This recommendation is because a connected | |||
UDP socket will accept packets only from one source IP address and | UDP socket will accept packets only from one source IP address and | |||
port. This limitation would prevent the server from accepting | port. This limitation would prevent the server from accepting | |||
packets from multiple clients on the same port. | packets from multiple clients on the same port. | |||
7. Implementation Experience | 7. Implementation Experience | |||
Two implementations of RADIUS/DTLS exist, Radsecproxy, and jradius | Two implementations of RADIUS/DTLS exist, Radsecproxy, and jradius | |||
(http://www.coova.org/JRadius). Some experimental tests have been | (http://www.coova.org/JRadius). Some experimental tests have been | |||
performed, but there are at this time no production implementations | performed, but there are at this time no production implementations | |||
skipping to change at page 17, line 7 | skipping to change at page 17, line 27 | |||
10. Security Considerations | 10. Security Considerations | |||
The bulk of this specification is devoted to discussing security | The bulk of this specification is devoted to discussing security | |||
considerations related to RADIUS. However, we discuss a few | considerations related to RADIUS. However, we discuss a few | |||
additional issues here. | additional issues here. | |||
This specification relies on the existing DTLS, RADIUS/UDP, and | This specification relies on the existing DTLS, RADIUS/UDP, and | |||
RADIUS/TLS specifications. As a result, all security considerations | RADIUS/TLS specifications. As a result, all security considerations | |||
for DTLS apply to the DTLS portion of RADIUS/DTLS. Similarly, the | for DTLS apply to the DTLS portion of RADIUS/DTLS. Similarly, the | |||
TLS and RADIUS security issues discussed in [RFC6614] also apply to | TLS and RADIUS security issues discussed in [RFC6614] also apply to | |||
this specification. All of the security considerations for RADIUS | this specification. Most of the security considerations for RADIUS | |||
apply to the RADIUS portion of the specification. | apply to the RADIUS portion of the specification. | |||
However, many security considerations raised in the RADIUS documents | However, many security considerations raised in the RADIUS documents | |||
are related to RADIUS encryption and authorization. Those issues are | are related to RADIUS encryption and authorization. Those issues are | |||
largely mitigated when DTLS is used as a transport method. The | largely mitigated when DTLS is used as a transport method. The | |||
issues that are not mitigated by this specification are related to | issues that are not mitigated by this specification are related to | |||
the RADIUS packet format and handling, which is unchanged in this | the RADIUS packet format and handling, which is unchanged in this | |||
specification. | specification. | |||
This specification also suggests that implementations use a | This specification also suggests that implementations use a session | |||
connection tracking table. This table is an extension of the | tracking table. This table is an extension of the duplicate | |||
duplicate detection cache mandated in [RFC5080] Section 2.2.2. The | detection cache mandated in [RFC5080] Section 2.2.2. The changes | |||
changes given here are that DTLS-specific information is tracked for | given here are that DTLS-specific information is tracked for each | |||
each table entry. Section 5.1.1, above, describes steps to mitigate | table entry. Section 5.1.1, above, describes steps to mitigate any | |||
any DoS issues which result from tracking additional information. | DoS issues which result from tracking additional information. | |||
The fixed shared secret given above in Section 2.2.1 is acceptible | The fixed shared secret given above in Section 2.2.1 is acceptible | |||
only when DTLS is used with an non-null encryption method. When a | only when DTLS is used with an non-null encryption method. When a | |||
DTLS session uses a null encryption method due to misconfiguration or | DTLS session uses a null encryption method due to misconfiguration or | |||
implementation error, all of the RADIUS traffic will be readable by | implementation error, all of the RADIUS traffic will be readable by | |||
an observer. | an observer. Implementations therefore MUST NOT use null encryption | |||
methods for RADIUS/DTLS. | ||||
For systems which perform protocol-based firewalling and/or | ||||
filtering, it is RECOMMENDED that they be configured to permit only | ||||
DTLS over the RADIUS/DTLS port. | ||||
10.1. Legacy RADIUS Security | 10.1. Legacy RADIUS Security | |||
We reiterate here the poor security of the legacy RADIUS protocol. | We reiterate here the poor security of the legacy RADIUS protocol. | |||
It is RECOMMENDED that all RADIUS clients and servers implement this | It is RECOMMENDED that all RADIUS clients and servers implement this | |||
specification, or [RFC6614]. New attacks on MD5 have appeared over | specification, or [RFC6614]. New attacks on MD5 have appeared over | |||
the past few years, and there is a distinct possibility that MD5 may | the past few years, and there is a distinct possibility that MD5 may | |||
be completely broken in the near future. | be completely broken in the near future. | |||
The existence of fast and cheap attacks on MD5 could result in a loss | The existence of fast and cheap attacks on MD5 could result in a loss | |||
skipping to change at page 18, line 18 | skipping to change at page 18, line 42 | |||
configuration which allows an administrator to configure all | configuration which allows an administrator to configure all | |||
certificates necessary for certificate-based authentication. These | certificates necessary for certificate-based authentication. These | |||
certificates include client, server, and root certificates. | certificates include client, server, and root certificates. | |||
TLS-PSK methods are susceptible to dictionary attacks. Section 6, | TLS-PSK methods are susceptible to dictionary attacks. Section 6, | |||
above, recommends deriving TLS-PSK keys from a CSPRNG, which makes | above, recommends deriving TLS-PSK keys from a CSPRNG, which makes | |||
dictionary attacks significantly more difficult. Servers SHOULD | dictionary attacks significantly more difficult. Servers SHOULD | |||
track failed client connections by TLS-PSK ID, and block TLS-PSK IDs | track failed client connections by TLS-PSK ID, and block TLS-PSK IDs | |||
which seem to be attempting brute-force searchs of the keyspace. | which seem to be attempting brute-force searchs of the keyspace. | |||
The historic RADIUS practice of using shared secrets that are minor | The historic RADIUS practice of using shared secrets (here, PSKs) | |||
variations of words is NOT RECOMMENDED, as it would negate all of the | that are minor variations of words is NOT RECOMMENDED, as it would | |||
security of DTLS. | negate all of the security of DTLS. | |||
10.2. Resource Exhaustion | 10.2. Resource Exhaustion | |||
The use of DTLS allows DoS attacks, and resource exhaustion attacks | The use of DTLS allows DoS attacks, and resource exhaustion attacks | |||
which were not possible in RADIUS/UDP. These attacks are the similar | which were not possible in RADIUS/UDP. These attacks are the similar | |||
to those described in [RFC6614] Section 6, for TCP. | to those described in [RFC6614] Section 6, for TCP. | |||
Session tracking as described in Section 5.1 can result in resource | Session tracking as described in Section 5.1 can result in resource | |||
exhaustion. Servers MUST therefore limit the absolute number of | exhaustion. Servers MUST therefore limit the absolute number of | |||
sessions that they track. When the total number of sessions tracked | sessions that they track. When the total number of sessions tracked | |||
skipping to change at page 19, line 9 | skipping to change at page 19, line 35 | |||
means that a client has a fixed IP address for a server, and a shared | means that a client has a fixed IP address for a server, and a shared | |||
secret used to authenticate traffic sent to that address. The server | secret used to authenticate traffic sent to that address. The server | |||
in turn has a fixed IP address for a client, and a shared secret used | in turn has a fixed IP address for a client, and a shared secret used | |||
to authenticate traffic from that address. This model needs to be | to authenticate traffic from that address. This model needs to be | |||
extended for RADIUS/DTLS. | extended for RADIUS/DTLS. | |||
When DTLS is used, the fixed IP address model can be relaxed. As | When DTLS is used, the fixed IP address model can be relaxed. As | |||
discussed earlier in Section 2.2.1, client identies should be | discussed earlier in Section 2.2.1, client identies should be | |||
determined from TLS parameters. Any authentication credentials for | determined from TLS parameters. Any authentication credentials for | |||
that client are then determined solely from the client identity, and | that client are then determined solely from the client identity, and | |||
not from an IP address. | not from an IP address. See [RFC6614] Section 2.5 for a discussion | |||
of how to match a certificate to a client identity. | ||||
However, servers SHOULD use IP address filtering to minimize the | However, servers SHOULD use IP address filtering to minimize the | |||
possibility of attacks. That is, they SHOULD permit clients only | possibility of attacks. That is, they SHOULD permit clients only | |||
from a particular IP address range or ranges. They SHOULD silently | from a particular IP address range or ranges. They SHOULD silently | |||
discard all traffic from outside of those ranges. | discard all traffic from outside of those ranges. | |||
Since the client-server relationship is static, the authentication | Since the client-server relationship is static, the authentication | |||
credentials for that relationship should also be statically | credentials for that relationship should also be statically | |||
configured. That is, a client connecting to a DTLS server SHOULD be | configured. That is, a client connecting to a DTLS server SHOULD be | |||
pre-configured with the servers credentials (e.g. PSK or | pre-configured with the servers credentials (e.g. PSK or | |||
certificate). If the server fails to present the correct | certificate). If the server fails to present the correct | |||
credentials, the DTLS session MUST be closed. | credentials, the DTLS session MUST be closed. | |||
The above requirement is best met by using a private Certificate | The above requirement can be met by using a private Certificate | |||
Authority (CA) for certificates used in RADIUS/DTLS environments. If | Authority (CA) for certificates used in RADIUS/DTLS environments. If | |||
a client were configured to use a public CA, then it could accept as | a client were configured to use a public CA, then it could accept as | |||
valid any server which has a certificate signed by that CA. The | valid any server which has a certificate signed by that CA. While | |||
traffic would be secure from third-party observers. The invalid | the traffic would be secure from third-party observers, the server | |||
server would, howrver, have unrestricted access to all of the RADIUS | would, howrver, have unrestricted access to all of the RADIUS | |||
traffic, including all user credentials and passwords. | traffic, including all user credentials and passwords. | |||
Therefore, clients SHOULD NOT be pre-configured with a list of known | Therefore, clients SHOULD NOT be pre-configured with a list of known | |||
public CAs. Instead, the clients SHOULD start off with an empty CA | public CAs by the vendor or manufacturer. Instead, the clients | |||
list. The addition of a CA SHOULD be done only when manually | SHOULD start off with an empty CA list. The addition of a CA SHOULD | |||
configured by an administrator. | be done only when manually configured by an administrator. | |||
This scenario is the opposite of web browsers, where they are pre- | This scenario is the opposite of web browsers, where they are pre- | |||
configured with many known CAs. The goal there is security from | configured with many known CAs. The goal there is security from | |||
third-party observers, but also the ability to communicate with any | third-party observers, but also the ability to communicate with any | |||
unknown site which presents a signed certificate. In contrast, the | unknown site which presents a signed certificate. In contrast, the | |||
goal of RADIUS/DTLS is both security from third-party observers, and | goal of RADIUS/DTLS is both security from third-party observers, and | |||
the ability to communicate with only a small set of well-known | the ability to communicate with only a small set of well-known | |||
servers. | servers. | |||
This requirement does not prevent clients from using hostnames | This requirement does not prevent clients from using hostnames | |||
skipping to change at page 20, line 17 | skipping to change at page 20, line 42 | |||
Network Address Translation (NAT) is fundamentally incompatible with | Network Address Translation (NAT) is fundamentally incompatible with | |||
RADIUS/UDP. RADIUS/UDP uses the source IP address to determine the | RADIUS/UDP. RADIUS/UDP uses the source IP address to determine the | |||
shared secret for the client, and NAT hides many clients behind one | shared secret for the client, and NAT hides many clients behind one | |||
source IP address. | source IP address. | |||
In addition, port re-use on a NAT gateway means that packets from | In addition, port re-use on a NAT gateway means that packets from | |||
different clients may appear to come from the same source port on the | different clients may appear to come from the same source port on the | |||
NAT. That is, a RADIUS server may receive a RADIUS/DTLS packet from | NAT. That is, a RADIUS server may receive a RADIUS/DTLS packet from | |||
a client IP/port combination, followed by the reception of a | a client IP/port combination, followed by the reception of a | |||
RADIUS/UDP packet from that same client IP/port combination. If this | RADIUS/UDP packet from that same client IP/port combination. If this | |||
behavior is allowed, it would permit a downgrade attack to occur, and | behavior is allowed, then the client would have an inconsistent | |||
would negate all of the security added by RADIUS/DTLS. | security profile, allowing an attacker to choose the most insecure | |||
method. | ||||
As a result, RADIUS clients SHOULD NOT be located behind a NAT | As a result, RADIUS/UDP clients SHOULD NOT be located behind a NAT | |||
gateway. If clients are located behind a NAT gateway, then a secure | gateway. If clients are located behind a NAT gateway, then a secure | |||
transport such as DTLS MUST be used. As discussed below, a method | transport such as DTLS MUST be used. As discussed below, a method | |||
for uniquely identifying each client MUST be used. | for uniquely identifying each client MUST be used. | |||
10.5. Wildcard Clients | 10.5. Wildcard Clients | |||
Some RADIUS server implementations allow for "wildcard" clients. | Some RADIUS server implementations allow for "wildcard" clients. | |||
That is, clients with an IPv4 netmask of other than 32, or an IPv6 | That is, clients with an IPv4 netmask of other than 32, or an IPv6 | |||
netmask of other than 128. That practice is not recommended for | netmask of other than 128. That practice is not recommended for | |||
RADIUS/UDP, as it means multiple clients use the same shared secret. | RADIUS/UDP, as it means multiple clients use the same shared secret. | |||
The use of RADIUS/DTLS can allow for the safe usage of wildcards. | The use of RADIUS/DTLS can allow for the safe usage of wildcards. | |||
When RADIUS/DTLS is used with wildcards clients MUST be uniquely | When RADIUS/DTLS is used with wildcards, clients MUST be uniquely | |||
identified using TLS parameters, and any certificate or PSK used MUST | identified using TLS parameters, and any certificate or PSK used MUST | |||
be unique to each client. | be unique to each client. | |||
10.6. Session Closing | 10.6. Session Closing | |||
Section 5.1.1, above, requires that DTLS sessions be closed when the | Section 5.1.1, above, requires that DTLS sessions be closed when the | |||
transported RADIUS packets are malformed, or fail the authenticator | transported RADIUS packets are malformed, or fail the authenticator | |||
checks. The reason is that the connection is expected to be used for | checks. The reason is that the session is expected to be used for | |||
transport of RADIUS packets only. | transport of RADIUS packets only. | |||
Any non-RADIUS traffic on that connection means the other party is | Any non-RADIUS traffic on that session means the other party is | |||
misbehaving, and is a potential security risk. Similarly, any RADIUS | misbehaving, and is a potential security risk. Similarly, any RADIUS | |||
traffic failing authentication vector or Message-Authenticator | traffic failing authentication vector or Message-Authenticator | |||
validation means that two parties do not have a common shared secret, | validation means that two parties do not have a common shared secret, | |||
and the session is therefore unauthenticated and insecure. | and the session is therefore unauthenticated and insecure. | |||
We wish to avoid the situation where a third party can send well- | We wish to avoid the situation where a third party can send well- | |||
formed RADIUS packets which cause a DTLS connection to close. | formed RADIUS packets which cause a DTLS session to close. | |||
Therefore, in other situations, the session SHOULD remain open in the | Therefore, in other situations, the session SHOULD remain open in the | |||
face of non-conformant packets. | face of non-conformant packets. | |||
10.7. Clients Subsystems | 10.7. Client Subsystems | |||
Many traditional clients treat RADIUS as subsystem-specific. That | Many traditional clients treat RADIUS as subsystem-specific. That | |||
is, each subsystem on the client has its own RADIUS implementation | is, each subsystem on the client has its own RADIUS implementation | |||
and configuration. These independent implementations work for simple | and configuration. These independent implementations work for simple | |||
systems, but break down for RADIUS when multiple servers, fail-over, | systems, but break down for RADIUS when multiple servers, fail-over, | |||
and load-balancing are required. They have even worse issues when | and load-balancing are required. They have even worse issues when | |||
DTLS is enabled. | DTLS is enabled. | |||
As noted in Section 6.1, above, clients SHOULD use a local proxy | As noted in Section 6.1, above, clients SHOULD use a local proxy | |||
which arbitrates all RADIUS traffic between the client and all | which arbitrates all RADIUS traffic between the client and all | |||
servers. This proxy will encapsulate all knowledge about servers, | servers. This proxy will encapsulate all knowledge about servers, | |||
including security policies, fail-over, and load-balancing. All | including security policies, fail-over, and load-balancing. All | |||
client subsystems SHOULD communicate with this local proxy, ideally | client subsystems SHOULD communicate with this local proxy, ideally | |||
over a loopback address. The requirements on using strong shared | over a loopback address. The requirements on using strong shared | |||
secrets still apply. | secrets still apply. | |||
The benefit of this configuration is that there is one place in the | The benefit of this configuration is that there is one place in the | |||
client which arbitrates all RADIUS traffic. Subsystems which do not | client which arbitrates all RADIUS traffic. Subsystems which do not | |||
implement DTLS can remain unaware of DTLS. DTLS connections opened | implement DTLS can remain unaware of DTLS. DTLS sessions opened by | |||
by the proxy can remain open for long periods of time, even when | the proxy can remain open for long periods of time, even when client | |||
client subsystems are restarted. The proxy can do RADIUS/UDP to some | subsystems are restarted. The proxy can do RADIUS/UDP to some | |||
servers, and RADIUS/DTLS to others. | servers, and RADIUS/DTLS to others. | |||
Delegation of responsibilities and separation of tasks are important | Delegation of responsibilities and separation of tasks are important | |||
security principles. By moving all RADIUS/DTLS knowledge to a DTLS- | security principles. By moving all RADIUS/DTLS knowledge to a DTLS- | |||
aware proxy, security analysis becomes simpler, and enforcement of | aware proxy, security analysis becomes simpler, and enforcement of | |||
correct security becomes easier. | correct security becomes easier. | |||
11. References | 11. References | |||
11.1. Normative references | 11.1. Normative references | |||
skipping to change at page 22, line 28 | skipping to change at page 23, line 6 | |||
[RFC6347] | [RFC6347] | |||
Rescorla E., and Modadugu, N., "Datagram Transport Layer Security", | Rescorla E., and Modadugu, N., "Datagram Transport Layer Security", | |||
RFC 6347, April 2006. | RFC 6347, April 2006. | |||
[RFC6520] | [RFC6520] | |||
Seggelmann, R., et al.,"Transport Layer Security (TLS) and Datagram | Seggelmann, R., et al.,"Transport Layer Security (TLS) and Datagram | |||
Transport Layer Security (DTLS) Heartbeat Extension", RFC 6520, | Transport Layer Security (DTLS) Heartbeat Extension", RFC 6520, | |||
February 2012. | February 2012. | |||
[RFC6613] | ||||
DeKok, A., "RADIUS over TCP", RFFC 6613, May 2012 | ||||
[RFC6614] | [RFC6614] | |||
Winter. S, et. al., "TLS encryption for RADIUS over TCP", RFFC | Winter. S, et. al., "TLS encryption for RADIUS over TCP", RFFC | |||
6614, May 2012 | 6614, May 2012 | |||
11.2. Informative references | 11.2. Informative references | |||
[RFC1321] | [RFC1321] | |||
Rivest, R. and S. Dusse, "The MD5 Message-Digest Algorithm", RFC | Rivest, R. and S. Dusse, "The MD5 Message-Digest Algorithm", RFC | |||
1321, April 1992. | 1321, April 1992. | |||
End of changes. 70 change blocks. | ||||
159 lines changed or deleted | 190 lines changed or added | |||
This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |