draft-ietf-radext-dtls-11.txt | draft-ietf-radext-dtls-12.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-11.txt> | <draft-ietf-radext-dtls-12.txt> | |||
Expires: October 28, 2015 | Expires: November 8, 2014 | |||
30 April 2014 | 8 May 2014 | |||
DTLS as a Transport Layer for RADIUS | DTLS as a Transport Layer for RADIUS | |||
draft-ietf-radext-dtls-11 | draft-ietf-radext-dtls-12 | |||
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 15, 2014 | This Internet-Draft will expire on November 8, 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 36 | skipping to change at page 3, line 36 | |||
7. Diameter Considerations .................................. 17 | 7. Diameter Considerations .................................. 17 | |||
8. IANA Considerations ...................................... 17 | 8. IANA Considerations ...................................... 17 | |||
9. Implementation Status .................................... 18 | 9. Implementation Status .................................... 18 | |||
9.1. Radsecproxy ......................................... 18 | 9.1. Radsecproxy ......................................... 18 | |||
9.2. jradius ............................................. 18 | 9.2. jradius ............................................. 18 | |||
10. Security Considerations ................................. 19 | 10. Security Considerations ................................. 19 | |||
10.1. Crypto-Agility ..................................... 19 | 10.1. Crypto-Agility ..................................... 19 | |||
10.2. Legacy RADIUS Security ............................. 20 | 10.2. Legacy RADIUS Security ............................. 20 | |||
10.3. Resource Exhaustion ................................ 21 | 10.3. Resource Exhaustion ................................ 21 | |||
10.4. Client-Server Authentication with DTLS ............. 21 | 10.4. Client-Server Authentication with DTLS ............. 21 | |||
10.5. Network Address Translation ........................ 22 | 10.5. Network Address Translation ........................ 23 | |||
10.6. Wildcard Clients ................................... 23 | 10.6. Wildcard Clients ................................... 23 | |||
10.7. Session Closing .................................... 23 | 10.7. Session Closing .................................... 24 | |||
10.8. Client Subsystems .................................. 24 | 10.8. Client Subsystems .................................. 24 | |||
11. References .............................................. 24 | 11. References .............................................. 25 | |||
11.1. Normative references ............................... 24 | 11.1. Normative references ............................... 25 | |||
11.2. Informative references ............................. 25 | 11.2. Informative references ............................. 26 | |||
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 5, line 24 | skipping to change at page 5, line 24 | |||
RADIUS over TLS, as defined in [RFC6614]. | RADIUS over TLS, as defined in [RFC6614]. | |||
silently discard | silently discard | |||
This means that the implementation discards the packet without | This means that the implementation discards the packet without | |||
further processing. | 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", "NOT | |||
and "OPTIONAL" in this document are to be interpreted as described in | RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be | |||
[RFC2119]. | interpreted as described in [RFC2119]. | |||
1.3. Document Status | 1.3. Document Status | |||
This document is an Experimental RFC. | This document is an Experimental RFC. | |||
It is one out of several approaches to address known cryptographic | It is one out of several approaches to address known cryptographic | |||
weaknesses of the RADIUS protocol, such as [RFC6614]. This | weaknesses of the RADIUS protocol, such as [RFC6614]. This | |||
specification does not fulfill all recommendations on a AAA transport | specification does not fulfill all recommendations on a AAA transport | |||
profile as per [RFC3539]; however unlike [RFC6614], it is based on | profile as per [RFC3539]; however unlike [RFC6614], it is based on | |||
UDP, does not have head-of-line blocking issues. | UDP, does not have head-of-line blocking issues. | |||
skipping to change at page 12, line 45 | skipping to change at page 12, line 45 | |||
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 | |||
setup DTLS sessions. Servers SHOULD limit both the number and impact | setup DTLS sessions. Servers MUST limit both the number and impact | |||
on resources of partial sessions. | 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 | |||
skipping to change at page 16, line 16 | skipping to change at page 16, line 16 | |||
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. | |||
When creating keys, it is RECOMMENDED that keys be derived from a | When creating keys, it is RECOMMENDED that keys be derived from a | |||
cryptographically secure pseudo-random number generator (CSPRNG) | cryptographically secure pseudo-random number generator (CSPRNG) | |||
instead of allowing administrators to invent "secure" keys on theur | instead of administrators inventing keys on their own. If managing | |||
own. If managing keys is too complicated, a certificate-based TLS | keys is too complicated, a certificate-based TLS method SHOULD be | |||
method SHOULD be used instead. | 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 multiple | sessions, so that the client subsystem does not need to manage | |||
multiple sessions on one socket. | multiple sessions on one socket. | |||
RADIUS/DTLS clients should use a single source (IP + port) when | RADIUS/DTLS clients should use a single source (IP + port) when | |||
sending packets to a particular RADIUS/DTLS server. Doing so | sending packets to a particular RADIUS/DTLS server. Doing so | |||
minimizes the number of DTLS session setups. It also ensures that | minimizes the number of DTLS session setups. It also ensures that | |||
information about the home server state is discovered only once. | information about the home server state is discovered only once. | |||
In practice, this means that RADIUS/DTLS clients with multiple | In practice, this means that RADIUS/DTLS clients with multiple | |||
internal RADIUS sources should use a local proxy which arbitrates all | internal RADIUS sources should use a local proxy which arbitrates all | |||
RADIUS traffic between the client and all servers. The proxy should | RADIUS traffic between the client and all servers. The proxy should | |||
skipping to change at page 21, line 48 | skipping to change at page 21, line 48 | |||
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 | Instead of a shared secret, TLS credentials MUST be used by each | |||
discussed earlier in Section 2.2.1, client identities should be | party to authenticate the other. The issue of identity is more | |||
determined from TLS parameters. Any authentication credentials for | problematic. As with RADIUS/UDP, IP addresses may be used as a key | |||
that client are then determined solely from the client identity, and | to determine the authentication credentials which a client will | |||
not from an IP address. See [RFC6614] Section 2.4 for a discussion | present to a server, or which credentials a server will accept from a | |||
of how to match a certificate to a client identity. | client. This is the fixed IP address model of RADIUS/UDP, with the | |||
shared secret replaced by TLS credentials. | ||||
There are, however, additional considerations with RADIUS/DTLS. When | ||||
a client is configured with a host name for a server, the server may | ||||
present to the client a certificate containing a host name. The | ||||
client MUST then verify that the host names match. Any mismatch is a | ||||
security violation, and the connection MUST be closed. | ||||
A RADIUS/DTLS server MAY be configured with a "wildcard" IP address | ||||
match for clients, instead of a unique fixed IP address for each | ||||
client. In that case, clients MUST be individually configured with a | ||||
unique certificate. When the server receives a connection from a | ||||
client, it MUST determine client identity from the client | ||||
certificate, and MUST authenticate (or not) the client based on that | ||||
certificate. See [RFC6614] Section 2.4 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 limited 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 must also be statically configured. | |||
configured. That is, a client connecting to a DTLS server SHOULD be | That is, a client connecting to a DTLS server SHOULD be pre- | |||
pre-configured with the servers credentials (e.g. PSK or | configured with the servers credentials (e.g. PSK or certificate). | |||
certificate). If the server fails to present the correct | If the server fails to present the correct credentials, the DTLS | |||
credentials, the DTLS session MUST be closed. | session MUST be closed. Each server SHOULD be preconfigured with | |||
sufficient information to authenticate connecting clients. | ||||
The above requirement can be met by using a private Certificate | The above requirements 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. While | valid any server which has a certificate signed by that CA. While | |||
the traffic would be secure from third-party observers, the server | the traffic would be secure from third-party observers, the 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 by the vendor or manufacturer. Instead, the clients | public CAs by the vendor or manufacturer. Instead, the clients | |||
SHOULD start off with an empty CA list. The addition of a CA SHOULD | SHOULD start off with an empty CA list. The addition of a CA SHOULD | |||
skipping to change at page 22, line 41 | skipping to change at page 23, line 10 | |||
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 | |||
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 | |||
preconfigured, and strongly tied to that hostname. This requirement | on the client, and associated with 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.5. 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. | |||
End of changes. 15 change blocks. | ||||
33 lines changed or deleted | 50 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/ |