draft-ietf-radext-dtls-09.txt | draft-ietf-radext-dtls-10.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-09.txt> | <draft-ietf-radext-dtls-10.txt> | |||
Expires: October 5, 2014 | Expires: October 15, 2015 | |||
5 February 2014 | 16 April 2014 | |||
DTLS as a Transport Layer for RADIUS | DTLS as a Transport Layer for RADIUS | |||
draft-ietf-radext-dtls-09 | draft-ietf-radext-dtls-10 | |||
Abstract | Abstract | |||
The RADIUS protocol defined in RFC 2865 has limited support for | The RADIUS protocol defined in RFC 2865 has limited support for | |||
authentication and encryption of RADIUS packets. The protocol | authentication and encryption of RADIUS packets. The protocol | |||
transports data in the clear, although some parts of the packets can | transports data in the clear, although some parts of the packets can | |||
have obfuscated content. Packets may be replayed verbatim by an | have obfuscated content. Packets may be replayed verbatim by an | |||
attacker, and client-server authentication is based on fixed shared | attacker, and client-server authentication is based on fixed shared | |||
secrets. This document specifies how the Datagram Transport Layer | secrets. This document specifies how the Datagram Transport Layer | |||
Security (DTLS) protocol may be used as a fix for these problems. It | Security (DTLS) protocol may be used as a fix for these problems. It | |||
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 October 5, 2014 | This Internet-Draft will expire on October 15, 2014 | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2014 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 | |||
skipping to change at page 3, line 26 | skipping to change at page 3, line 26 | |||
3.1. DTLS Port and Packet Types .......................... 10 | 3.1. DTLS Port and Packet Types .......................... 10 | |||
3.2. Server Behavior ..................................... 10 | 3.2. Server Behavior ..................................... 10 | |||
4. Client Behavior .......................................... 11 | 4. Client Behavior .......................................... 11 | |||
5. Session Management ....................................... 11 | 5. Session Management ....................................... 11 | |||
5.1. Server Session Management ........................... 12 | 5.1. Server Session Management ........................... 12 | |||
5.1.1. Session Opening and Closing .................... 12 | 5.1.1. Session Opening and Closing .................... 12 | |||
5.2. Client Session Management ........................... 14 | 5.2. Client Session Management ........................... 14 | |||
6. Implementation Guidelines ................................ 15 | 6. Implementation Guidelines ................................ 15 | |||
6.1. Client Implementations .............................. 16 | 6.1. Client Implementations .............................. 16 | |||
6.2. Server Implementations .............................. 17 | 6.2. Server Implementations .............................. 17 | |||
7. Implementation Experience ................................ 17 | 7. Diameter Considerations .................................. 17 | |||
8. Diameter Considerations .................................. 18 | 8. IANA Considerations ...................................... 17 | |||
9. IANA Considerations ...................................... 18 | 9. Implementation Status .................................... 18 | |||
10. Security Considerations ................................. 18 | 9.1. Radsecproxy ......................................... 18 | |||
10.1. Legacy RADIUS Security ............................. 19 | 9.2. jradius ............................................. 18 | |||
10.2. Resource Exhaustion ................................ 20 | 10. Security Considerations ................................. 19 | |||
10.3. Client-Server Authentication with DTLS ............. 20 | 10.1. Crypto-Agility ..................................... 19 | |||
10.4. Network Address Translation ........................ 21 | 10.2. Legacy RADIUS Security ............................. 20 | |||
10.5. Wildcard Clients ................................... 22 | 10.3. Resource Exhaustion ................................ 21 | |||
10.6. Session Closing .................................... 22 | 10.4. Client-Server Authentication with DTLS ............. 21 | |||
10.7. Client Subsystems .................................. 22 | 10.5. Network Address Translation ........................ 22 | |||
11. References .............................................. 23 | 10.6. Wildcard Clients ................................... 23 | |||
11.1. Normative references ............................... 23 | 10.7. Session Closing .................................... 23 | |||
11.2. Informative references ............................. 24 | 10.8. Client Subsystems .................................. 23 | |||
11. References .............................................. 24 | ||||
11.1. Normative references ............................... 24 | ||||
11.2. Informative references ............................. 25 | ||||
1. Introduction | 1. Introduction | |||
The RADIUS protocol as described in [RFC2865], [RFC2866], [RFC5176], | The RADIUS protocol as described in [RFC2865], [RFC2866], [RFC5176], | |||
and others has traditionally used methods based on MD5 [RFC1321] for | and others has traditionally used methods based on MD5 [RFC1321] for | |||
per-packet authentication and integrity checks. However, the MD5 | per-packet authentication and integrity checks. However, the MD5 | |||
algorithm has known weaknesses such as [MD5Attack] and [MD5Break]. | algorithm has known weaknesses such as [MD5Attack] and [MD5Break]. | |||
As a result, some specifications such as [RFC5176] have recommended | As a result, some specifications such as [RFC5176] have recommended | |||
using IPSec to secure RADIUS traffic. | using IPSec to secure RADIUS traffic. | |||
skipping to change at page 4, line 34 | skipping to change at page 4, line 34 | |||
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. The change from RADIUS/UDP | Datagram Protocol (UDP) based protocol. The change from RADIUS/UDP | |||
is largely only to add TLS support. This allows implementations to | is largely only to add TLS support. This allows implementations to | |||
remain UDP based, without changing to a TCP architecture. | remain UDP based, without changing to a TCP architecture. | |||
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/UDP. The DTLS protocol does not add reliable | |||
in-order transport to RADIUS. DTLS also does not support | or 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. These | RADIUS the issues of order, reliability, and fragmentation. These | |||
issues are dealt with in RADIUS/TCP [RFC6613] and RADIUS/TLS | issues are dealt with in RADIUS/TCP [RFC6613] and RADIUS/TLS | |||
[RFC6614]. | [RFC6614]. | |||
1.1. Terminology | 1.1. Terminology | |||
This document uses the following terms: | This document uses the following terms: | |||
skipping to change at page 12, line 7 | skipping to change at page 12, line 7 | |||
[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 Session Management | 5.1. Server Session Management | |||
A RADIUS/DTLS server MUST track ongoing DTLS client session based the | A RADIUS/DTLS server MUST track ongoing DTLS sessions for each based | |||
following 4-tuple: | 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 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 4-tuple points to a unique session entry, which contains the | Each 4-tuple points to a unique session entry, which usually contain | |||
following information: | the following information: | |||
DTLS Data | DTLS Session | |||
An implementation-specific variable containing information about | Any information required to maintain and manage the DTLS session. | |||
the active DTLS session. | ||||
Last Taffic | Last Taffic | |||
A variable containing a timestamp which indicates when this session | A variable containing a timestamp which indicates when this session | |||
last received valid traffic. | last received valid traffic. If "Last Traffic" is not used, this | |||
variable may not exist. | ||||
Each entry may contain other information, such as idle timeouts, | DTLS Data | |||
An implementation-specific variable which may information about the | ||||
active DTLS session. This variable may be empty or non existent. | ||||
This data will typically contain information such as idle timeouts, | ||||
session lifetimes, and other implementation-specific data. | session lifetimes, and other implementation-specific data. | |||
5.1.1. Session Opening and Closing | 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 | |||
skipping to change at page 15, line 19 | skipping to change at page 15, line 22 | |||
When client fails to implement both DTLS heartbeats and watchdog | When client fails to implement both DTLS heartbeats and watchdog | |||
packets, it has no way of knowing that a DTLS 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 all DTLS sessions are | |||
implement DTLS heartbeats and/or watchdog packets for all DTLS | configured to use DTLS heartbeats and/or watchdog packets. | |||
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 | |||
skipping to change at page 17, line 28 | skipping to change at page 17, line 29 | |||
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. Diameter Considerations | |||
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. | |||
9. IANA Considerations | 8. IANA Considerations | |||
No new RADIUS attributes or packet codes are defined. IANA is | No new RADIUS attributes or packet codes are defined. IANA is | |||
requested to update the already-assigned UDP port number 2083 in the | requested to update the "Service Name and Transport Protocol Port | |||
following ways: | Number Registry". The entry corresponding to port service name | |||
"radsec", port number "2083", and transport protocol "UDP" should be | ||||
updated as follows: | ||||
o Reference: list the RFC number of this document as the reference | o Assignee: change "Mike McCauley" to "IESG". | |||
o Contact: change ""Mike McCauley" to "IETF Chair" | ||||
o Reference: Add this document as a reference | ||||
o Assignment Notes: add the text "The UDP port 2083 was already | o Assignment Notes: add the text "The UDP port 2083 was already | |||
previously assigned by IANA for "RadSec", an early implementation | previously assigned by IANA for "RadSec", an early implementation | |||
of RADIUS/TLS, prior to issuance of this RFC." | of RADIUS/TLS, prior to issuance of this RFC." | |||
9. Implementation Status | ||||
This section records the status of known implementations of | ||||
RADIUS/DTLS at the time of posting of this Internet- Draft, and is | ||||
based on a proposal described in [RFC6982]. | ||||
The description of implementations in this section is intended to | ||||
assist the IETF in its decision processes in progressing drafts to | ||||
RFCs. | ||||
9.1. Radsecproxy | ||||
Organization: Radsecproxy | ||||
URL: https://software.uninett.no/radsecproxy/ | ||||
Maturity: Widely-used software based on early drafts of this | ||||
document. | ||||
The use of the DTLS functionality is not clear. | ||||
Coverage: The bulk of this specification is implemented, based on | ||||
earlier versions of this document. Exact revisions | ||||
which were implemented are unknown. | ||||
Licensing: Freely distributable with acknowledgement | ||||
Implementation experience: No comments from implementors. | ||||
9.2. jradius | ||||
Organization: Coova | ||||
URL: http://www.coova.org/JRadius/RadSec | ||||
Maturity: Production software based on early drafts of this | ||||
document. | ||||
The use of the DTLS functionality is not clear. | ||||
Coverage: The bulk of this specification is implemented, based on | ||||
earlier versions of this document. Exact revisions | ||||
which were implemented are unknown. | ||||
Licensing: Freely distributable with requirement to | ||||
redistribute source. | ||||
Implementation experience: No comments from implementors. | ||||
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 | |||
skipping to change at page 19, line 18 | skipping to change at page 19, line 45 | |||
implementation error, all of the RADIUS traffic will be readable by | implementation error, all of the RADIUS traffic will be readable by | |||
an observer. Implementations therefore MUST NOT use null encryption | an observer. Implementations therefore MUST NOT use null encryption | |||
methods for RADIUS/DTLS. | methods for RADIUS/DTLS. | |||
For systems which perform protocol-based firewalling and/or | For systems which perform protocol-based firewalling and/or | |||
filtering, it is RECOMMENDED that they be configured to permit only | filtering, it is RECOMMENDED that they be configured to permit only | |||
DTLS over the RADIUS/DTLS port. Where deep packet inspection is | DTLS over the RADIUS/DTLS port. Where deep packet inspection is | |||
possible, there should be further restrictions to allow only RADIUS | possible, there should be further restrictions to allow only RADIUS | |||
packets inside of the DTLS session. | packets inside of the DTLS session. | |||
10.1. Legacy RADIUS Security | 10.1. Crypto-Agility | |||
protocol. We suggest that RADIUS clients and servers implement | Section 4.2 of [RFC6421] makes a number of recommendations about | |||
either this specification, or [RFC6614]. New attacks on MD5 have | security properties of new RADIUS proposals. All of those | |||
appeared over the past few years, and there is a distinct possibility | recommendations are satisfied by using DTLS as the transport layer. | |||
that MD5 may be completely broken in the near future. Such a break | ||||
would mean that RADIUS/UDP was completely insecure. | 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 using DTLS key management. | ||||
10.2. Legacy RADIUS Security | ||||
We reiterate here the poor security of the legacy RADIUS protocol. | ||||
We suggest that RADIUS clients and servers implement either this | ||||
specification, or [RFC6614]. New attacks on MD5 have appeared over | ||||
the past few years, and there is a distinct possibility that MD5 may | ||||
be completely broken in the near future. Such a break would mean | ||||
that RADIUS/UDP was completely insecure. | ||||
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 | |||
cannot overstate the disastrous consequences of a successful attack | cannot overstate the disastrous consequences of a successful attack | |||
on RADIUS. | on RADIUS. | |||
We also caution implementors (especially client implementors) about | We also caution implementors (especially client implementors) about | |||
using RADIUS/DTLS. It may be tempting to use the shared secret as | using RADIUS/DTLS. It may be tempting to use the shared secret as | |||
the basis for a TLS pre-shared key (PSK) method, and to leave the | the basis for a TLS pre-shared key (PSK) method, and to leave the | |||
skipping to change at page 19, line 49 | skipping to change at page 20, line 51 | |||
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. | |||
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 Cryptographically | |||
Secure Pseudo-Random Number Generator (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 (here, PSKs) | The historic RADIUS practice of using shared secrets (here, PSKs) | |||
that are minor variations of words is NOT RECOMMENDED, as it would | that are minor variations of words is NOT RECOMMENDED, as it would | |||
negate all of the security of DTLS. | negate all of the security of DTLS. | |||
10.2. Resource Exhaustion | 10.3. 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 | |||
is going to exceed the configured limit, servers MAY free up | is going to exceed the configured limit, servers MAY free up | |||
resources by closing the session which has been idle for the longest | resources by closing the session which has been idle for the longest | |||
time. Doing so may free up idle resources which then allow the | time. Doing so may free up idle resources which then allow the | |||
server to accept a new session. | server to accept a new session. | |||
Servers MUST limit the number of partially open DTLS sessions. These | Servers MUST limit the number of partially open DTLS sessions. These | |||
limits SHOULD be exposed to the administrator as configurable | limits SHOULD be exposed to the administrator as configurable | |||
settings. | settings. | |||
10.3. Client-Server Authentication with DTLS | 10.4. Client-Server Authentication with DTLS | |||
We expect that the initial deployment of DTLS will be follow the | We expect that the initial deployment of DTLS will be follow the | |||
RADIUS/UDP model of statically configured client-server | RADIUS/UDP model of statically configured client-server | |||
relationships. The specification for dynamic discovery of RADIUS | relationships. The specification for dynamic discovery of RADIUS | |||
servers is under development, so we will not address that here. | servers is under development, so we will not address that here. | |||
Static configuration of client-server relationships for RADIUS/UDP | Static configuration of client-server relationships for RADIUS/UDP | |||
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 identities 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. See [RFC6614] Section 2.4 for a discussion | not from an IP address. See [RFC6614] Section 2.4 for a discussion | |||
of how to match a certificate to a client identity. | 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. | |||
skipping to change at page 21, line 41 | skipping to change at page 22, line 46 | |||
servers. | servers. | |||
This requirement does not prevent clients from using hostnames | This requirement does not prevent clients from using hostnames | |||
instead of IP addresses for locating a particular server. Instead, | instead of IP addresses for locating a particular server. Instead, | |||
it means that the credentials for that server should be | it means that the credentials for that server should be | |||
preconfigured, and strongly tied to that hostname. This requirement | preconfigured, and strongly tied to that hostname. This requirement | |||
does suggest that in the absence of a specification for dynamic | does suggest that in the absence of a specification for dynamic | |||
discovery, clients SHOULD use only those servers which have been | discovery, clients SHOULD use only those servers which have been | |||
manually configured by an administrator. | manually configured by an administrator. | |||
10.4. Network Address Translation | 10.5. 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. | |||
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, then the client would have an inconsistent | behavior is allowed, then the client would have an inconsistent | |||
security profile, allowing an attacker to choose the most insecure | security profile, allowing an attacker to choose the most insecure | |||
method. | method. | |||
As a result, RADIUS/UDP 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.6. 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.7. 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 session 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 session 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 session 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. Client Subsystems | 10.8. 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 | |||
skipping to change at page 24, line 49 | skipping to change at page 26, line 6 | |||
[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] | [RFC6421] | |||
Nelson, D. (Ed), "Crypto-Agility Requirements for Remote | Nelson, D. (Ed), "Crypto-Agility Requirements for Remote | |||
Authentication Dial-In User Service (RADIUS)", RFC 6421, November | Authentication Dial-In User Service (RADIUS)", RFC 6421, November | |||
2011. | 2011. | |||
[RFC6982] | ||||
Sheffer, Y. and A. Farrel, "Improving Awareness of Running Code: | ||||
The Implementation Status Section", RFC 6982, July 2013. | ||||
[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. 27 change blocks. | ||||
80 lines changed or deleted | 140 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/ |