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/