draft-ietf-radext-dtls-06.txt   draft-ietf-radext-dtls-07.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-06.txt> <draft-ietf-radext-dtls-07.txt>
Expires: January 12, 2014 Expires: October 09, 2014
12 July 2013 9 October 2013
DTLS as a Transport Layer for RADIUS DTLS as a Transport Layer for RADIUS
draft-ietf-radext-dtls-06 draft-ietf-radext-dtls-07
Abstract Abstract
The RADIUS protocol [RFC2865] has limited support for authentication The RADIUS protocol [RFC2865] has limited support for authentication
and encryption of RADIUS packets. The protocol transports data "in and encryption of RADIUS packets. The protocol transports data "in
the clear", although some parts of the packets can have "obfuscated" the clear", although some parts of the packets can have "obfuscated"
content. Packets may be replayed verbatim by an attacker, and content. Packets may be replayed verbatim by an attacker, and
client-server authentication is based on fixed shared secrets. This client-server authentication is based on fixed shared secrets. This
document specifies how the Datagram Transport Layer Security (DTLS) document specifies how the Datagram Transport Layer Security (DTLS)
protocol may be used as a fix for these problems. It also describes protocol may be used as a fix for these problems. It also describes
skipping to change at page 3, line 20 skipping to change at page 3, line 20
2. Building on Existing Foundations ......................... 6 2. Building on Existing Foundations ......................... 6
2.1. Changes to RADIUS ................................... 6 2.1. Changes to RADIUS ................................... 6
2.2. Similarities with RADIUS/TLS ........................ 7 2.2. Similarities with RADIUS/TLS ........................ 7
2.2.1. Changes from RADIUS/TLS to RADIUS/DTLS ......... 7 2.2.1. Changes from RADIUS/TLS to RADIUS/DTLS ......... 7
2.2.2. Reinforcement of RADIUS/TLS .................... 8 2.2.2. Reinforcement of RADIUS/TLS .................... 8
3. 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. Connection Management .................................... 10
5.1. Server Connection Management ........................ 11 5.1. Server Connection Management ........................ 10
5.1.1. Session Management ............................. 11 5.1.1. Session Management ............................. 11
5.2. Client Connection Management ........................ 13 5.2. Client Connection Management ........................ 13
6. Implementation Guidelines ................................ 14 6. Implementation Guidelines ................................ 14
6.1. Client Implementations .............................. 15 6.1. Client Implementations .............................. 14
6.2. Server Implementations .............................. 15 6.2. Server Implementations .............................. 15
7. Implementation Experience ................................ 16 7. Implementation Experience ................................ 15
8. Diameter Considerations .................................. 16 8. Diameter Considerations .................................. 16
9. IANA Considerations ...................................... 16 9. IANA Considerations ...................................... 16
10. Security Considerations ................................. 17 10. Security Considerations ................................. 16
10.1. Legacy RADIUS Security ............................. 17 10.1. Legacy RADIUS Security ............................. 17
10.2. Resource Exhaustion ................................ 18 10.2. Resource Exhaustion ................................ 18
10.3. Network Address Translation ........................ 19 10.3. Client-Server Authentication with DTLS ............. 18
10.4. Wildcard Clients ................................... 19 10.4. Network Address Translation ........................ 20
10.5. Session Closing .................................... 19 10.5. Wildcard Clients ................................... 20
10.6. Clients Subsystems ................................. 20 10.6. Session Closing .................................... 20
11. References .............................................. 20 10.7. Clients Subsystems ................................. 21
11.1. Normative references ............................... 20 11. References .............................................. 21
11.2. Informative references ............................. 21 11.1. Normative references ............................... 21
11.2. Informative references ............................. 22
1. Introduction 1. Introduction
The RADIUS protocol as described in [RFC2865], [RFC2866], [RFC5176], The RADIUS protocol as described in [RFC2865], [RFC2866], [RFC5176],
and others has traditionally used methods based on MD5 [RFC1321] for and others has traditionally used methods based on MD5 [RFC1321] for
per-packet authentication and integrity checks. However, the MD5 per-packet authentication and integrity checks. However, the MD5
algorithm has known weaknesses such as [MD5Attack] and [MD5Break]. algorithm has known weaknesses such as [MD5Attack] and [MD5Break].
As a result, some specifications such as [RFC5176] have recommended As a result, some specifications such as [RFC5176] have recommended
using IPSec to secure RADIUS traffic. using IPSec to secure RADIUS traffic.
skipping to change at page 4, line 32 skipping to change at page 4, line 32
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. This continuity ensures that
existing network-layer infrastructure (firewall rules, etc.) does not existing network-layer infrastructure (firewall rules, etc.) does not
need to be changed when RADIUS clients and servers are upgraded to need to be changed when RADIUS clients and servers are upgraded to
support RADIUS over DTLS. 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.
1.1. Terminology 1.1. Terminology
skipping to change at page 6, line 46 skipping to change at page 6, line 46
"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 encapsulated RADIUS packets of 4096 in length, with a
corresponding increase in the maximum size of the encapsulated DTLS corresponding increase in the maximum size of the encapsulated DTLS
packets. packets. This larger packet size may cause the packet to be larger
than the Path MTU (PMTU), where a 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.
(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".
skipping to change at page 8, line 5 skipping to change at page 8, line 7
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 identies can be Section 2.4 applies to RADIUS/DTLS. Client identities SHOULD be
determined from TLS parameters, instead of relying solely on the determined from TLS 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"
of RADIUS packets inside of a TLS session. Implementors MUST enforce of RADIUS packets inside of a TLS session. Implementors MUST enforce
the requirements of [RFC2865] Section 3 for the RADIUS Length field, the requirements of [RFC2865] Section 3 for the RADIUS Length field,
using the length of the decrypted DTLS data for the checks. This using the length of the decrypted DTLS data for the checks. This
check replaces the RADIUS method of using the length field from the check replaces the RADIUS method of using the length field from the
UDP packet. UDP packet.
Section 3.4 item (3) applies to RADIUS/DTLS when the new port is Section 3.4 items (2), (3), (4), and (5) apply to RADIUS/DTLS.
used. When DTLS is used over the existing RADIUS/UDP ports, the
relationship between RADIUS packet codes and UDP ports in RADIUS/DTLS
is unchanged from RADIUS.
Section 3.4 item (4) applies to RADIUS/DTLS when the new port is
used. When DTLS is used over the existing RADIUS/UDP ports, the use
of negative ICMP responses is unchanged from RADIUS.
Section 3.4 item (5) applies to RADIUS/DTLS when the new port is
used. When DTLS is used over the existing RADIUS/UDP ports, the use
of negative ICMP responses is unchanged from RADIUS.
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 2.2.2. Reinforcement of RADIUS/TLS
We re-iterate that much of [RFC6614] applies to this document. We re-iterate that much of [RFC6614] applies to this document.
Specifically, Section 4 and Section 6 of that document are applicable Specifically, Section 4 and Section 6 of that document are applicable
to RADIUS/DTLS. to RADIUS/DTLS.
skipping to change at page 9, line 38 skipping to change at page 9, line 30
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
without notice. without notice.
As RADIUS has no provisions for capability signalling, there is no As RADIUS has no provisions for capability signalling, there is no
way for a RADIUS server to indicate to a client that it should way for a RADIUS server to indicate to a client that it should
transition to using DTLS. This action has to be taken by the transition to using DTLS. This action has to be taken by the
administrators of the two systems, using a method other than RADIUS. administrators of the two systems, using a method other than RADIUS.
This method will likely be out of band, or manual configuration.
Some servers maintain a list of allowed clients per destination port. Some servers maintain a list of allowed clients per destination port.
Others maintain a global list of clients, which are permitted to send Others maintain a global list of clients, which are permitted to send
packets to any port. Where a client can send packets to multiple packets to any port. Where a client can send packets to multiple
ports, the server MUST maintain a "DTLS Required" flag per client. ports, the server MUST maintain a "DTLS Required" flag per client.
This flag indicates whether or not the client is required to use This flag indicates whether or not the client is required to use
DTLS. When set, the flag indicates that the only traffic accepted DTLS. When set, the flag indicates that the only traffic accepted
from the client is over UDP/2083. When packets are received from a from the client is over UDP/2083. When packets are received from a
client on non-DTLS ports, for which DTLS is required, the server MUST client on non-DTLS ports, for which DTLS is required, the server MUST
skipping to change at page 10, line 17 skipping to change at page 10, line 12
Allowing RADIUS/UDP and RADIUS/DTLS from the same client exposes the Allowing RADIUS/UDP and RADIUS/DTLS from the same client exposes the
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. Doing so could cause problems for servers which do DTLS transport. Instead, clients SHOULD use DTLS as a transport
not implement DTLS. Instead, clients SHOULD use DTLS as a transport
layer only when administratively configured. layer only when administratively configured.
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 or processes that originate packets. This practice was simple to
implement, but means that each independent subsystem must implement, but means 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-
skipping to change at page 11, line 10 skipping to change at page 10, line 52
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 Connection Management
A RADIUS/DTLS server MUST track ongoing DTLS client connections based A RADIUS/DTLS server MUST track ongoing DTLS client connections based
on a key composed of the 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 key 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 key contains the following information: Each entry associated with a 4-tuple contains the 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 connection.
Last Taffic Last Taffic
A variable containing a timestamp which indicates when this A variable containing a timestamp which indicates when this
connection last received valid traffic. connection 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. connection lifetimes, and other implementation-specific data.
5.1.1. Session Management 5.1.1. Session Management
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. The requirement to accept RADIUS/UDP and RADIUS/DTLS on the value. Server implementation SHOULD have a way of tracking partially
same port makes this recommendation difficult to implement in setup DTLS connections. Servers SHOULD limit both the number and
practice. Server implementation SHOULD therefore have a way of impact on resources of partial connections.
tracking partially setup DTLS connections. Servers SHOULD limit both
the number and impact on resources of partial connections.
Sessions (both key and entry) MUST deleted when a TLS Closure Alert Sessions (both 4-tuple and entry) MUST be deleted when a TLS Closure
([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 failed Section 7.2.2) is received. When a session is deleted due to it
security, the DTLS session MUST be closed, and any TLS session failing security requirements, the DTLS session MUST be closed, and
resumption parameters for that session MUST be discarded, and all any TLS session resumption parameters for that session MUST be
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.
skipping to change at page 13, line 31 skipping to change at page 13, line 22
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 Connection Management
Clients SHOULD use Path MTU (PMTU) discovery [RFC6520] to determine Clients SHOULD use PMTU discovery [RFC6520] to determine the PMTU
the PMTU between the client and server, prior to sending any RADIUS between the client and server, prior to sending any RADIUS traffic.
traffic. Once a DTLS session is established, a RADIUS/DTLS client Once a DTLS session is established, a RADIUS/DTLS client SHOULD use
SHOULD use DTLS Heartbeats [RFC6520] to determine connectivity DTLS Heartbeats [RFC6520] to determine connectivity between the two
between the two systems. Alternatively, RADIUS/DTLS clients may use systems. Alternatively, RADIUS/DTLS clients may use the application-
the application-layer watchdog algorithm defined in [RFC3539] to layer watchdog algorithm defined in [RFC3539] to determine server
determine server responsiveness. The Status-Server packet defined in responsiveness. The Status-Server packet defined in [RFC5997] SHOULD
[RFC5997] SHOULD be used as the "watchdog packet" in any application- be used as the "watchdog packet" in any application-layer watchdog
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 A client may choose to avoid DTLS heartbeats and watchdog packets
skipping to change at page 14, line 45 skipping to change at page 14, line 36
additional implementation guidelines. These guidelines are not part additional implementation guidelines. These guidelines are not part
of the protocol, but may help implementors create simple, secure, and of the protocol, but may help implementors create simple, secure, and
inter-operable implementations. inter-operable implementations.
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 hex strings. allows for the keys to be entered as humanly readable strings in hex
format.
It is RECOMMENDED that keys be derived from a cryptographically It is RECOMMENDED that keys be derived from a cryptographically
secure pseudo-random number generator (CSPRNG). If managing keys is secure pseudo-random number generator (CSPRNG). If managing keys is
too complicated, a certificate-based TLS method SHOULD be used too complicated, a certificate-based TLS method SHOULD be used
instead. 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
skipping to change at page 17, line 8 skipping to change at page 16, line 47
following ways: following ways:
o Reference: list the RFC number of this document as the reference o Reference: list the RFC number of this document as the 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."
10. Security Considerations 10. Security Considerations
This entire 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. All 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.
The main portion of the specification that could have security
implications is a servers ability to accept both RADIUS and DTLS
packets on the same port. The filter that disambiguates the two
protocols is simple, and is just a check for the value of one octet.
We do not expect this check to have any security issues.
We also note that nothing prevents malicious clients from sending
DTLS packets to existing RADIUS implementations, or RADIUS packets to
existing DTLS implementations. There should therefore be no issue
with clients sending RADIUS/DTLS packets to legacy servers that do
not support the protocol. These packets will be silently discarded,
and will not change the security profile of the server.
This specification also suggests that implementations use a This specification also suggests that implementations use a
connection tracking table. This table is an extension of the connection tracking table. This table is an extension of the
duplicate detection cache mandated in [RFC5080] Section 2.2.2. The duplicate detection cache mandated in [RFC5080] Section 2.2.2. The
changes given here are that DTLS-specific information is tracked for changes given here are that DTLS-specific information is tracked for
each table entry. Section 5.1.1, above, describes steps to mitigate each table entry. Section 5.1.1, above, describes steps to mitigate
any DoS issues which result from tracking additional information. any DoS issues which result from tracking additional information.
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
DTLS session uses a null encryption method due to misconfiguration or
implementation error, all of the RADIUS traffic will be readable by
an observer.
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. New attacks on MD5 have appeared over the past few specification, or [RFC6614]. New attacks on MD5 have appeared over
years, and there is a distinct possibility that MD5 may be completely the past few years, and there is a distinct possibility that MD5 may
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
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 9 skipping to change at page 18, line 40
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. Network Address Translation 10.3. Client-Server Authentication with DTLS
We expect that the initial deployment of DTLS will be follow the
RADIUS/UDP model of statically configured client-server
relationships. The specification for dynamic discovery of RADIUS
servers is under development, so we will not address that here.
Static configuration of client-server relationships for RADIUS/UDP
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
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
extended for RADIUS/DTLS.
When DTLS is used, the fixed IP address model can be relaxed. As
discussed earlier in Section 2.2.1, client identies should be
determined from TLS parameters. Any authentication credentials for
that client are then determined solely from the client identity, and
not from an IP address.
However, servers SHOULD use IP address filtering to minimize the
possibility of attacks. That is, they SHOULD permit clients only
from a particular IP address range or ranges. They SHOULD silently
discard all traffic from outside of those ranges.
Since the client-server relationship is static, the authentication
credentials for that relationship should also be statically
configured. That is, a client connecting to a DTLS server SHOULD be
pre-configured with the servers credentials (e.g. PSK or
certificate). If the server fails to present the correct
credentials, the DTLS session MUST be closed.
The above requirement is best met by using a private Certificate
Authority (CA) for certificates used in RADIUS/DTLS environments. If
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
traffic would be secure from third-party observers. The invalid
server would, howrver, have unrestricted access to all of the RADIUS
traffic, including all user credentials and passwords.
Therefore, clients SHOULD NOT be pre-configured with a list of known
public CAs. Instead, the clients SHOULD start off with an empty CA
list. The addition of a CA SHOULD be done only when manually
configured by an administrator.
This scenario is the opposite of web browsers, where they are pre-
configured with many known CAs. The goal there is security from
third-party observers, but also the ability to communicate with any
unknown site which presents a signed certificate. In contrast, the
goal of RADIUS/DTLS is both security from third-party observers, and
the ability to communicate with only a small set of well-known
servers.
This requirement does not prevent clients from using hostnames
instead of IP addresses for locating a particular server. Instead,
it means that the credentials for that server should be
preconfigured, and strongly tied to that hostname. This requirement
does suggest that in the absence of a specification for dynamic
discovery, clients SHOULD use only those servers which have been
manually configured by an administrator.
10.4. 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, it would permit a downgrade attack to occur, and behavior is allowed, it would permit a downgrade attack to occur, and
would negate all of the security added by RADIUS/DTLS. would negate all of the security added by RADIUS/DTLS.
As a result, RADIUS clients SHOULD NOT be located behind a NAT As a result, RADIUS clients SHOULD NOT be located behind a NAT
gateway. If clients are located behind a NAT gateway, then a secure gateway. If clients are located behind a NAT gateway, then a secure
transport such as DTLS MUST be used. As discussed below, a method transport such as DTLS MUST be used. As discussed below, a method
for uniquely identifying each client MUST be used. for uniquely identifying each client MUST be used.
10.4. 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.
When a client is a "wildcard", RADIUS/DTLS MUST be used. Clients The use of RADIUS/DTLS can allow for the safe usage of wildcards.
MUST be uniquely identified, and any certificate or PSK used MUST be When RADIUS/DTLS is used with wildcards clients MUST be uniquely
unique to each client. identified using TLS parameters, and any certificate or PSK used MUST
be unique to each client.
10.5. 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 various transported RADIUS packets are malformed, or fail the authenticator
authenticator checks. This requirement is due to security checks. The reason is that the connection is expected to be used for
considerations. transport of RADIUS packets only.
When an implementation has a DTLS connection, it is expected that the Any non-RADIUS traffic on that connection means the other party is
connection be used to transport RADIUS. Any non-RADIUS traffic on misbehaving, and is a potential security risk. Similarly, any RADIUS
that connection means the other party is misbehaving, and a potential traffic failing authentication vector or Message-Authenticator
security risk. Similarly, any RADIUS traffic failing validation validation means that two parties do not have a common shared secret,
means that two parties do not share the same security parameters, and and the session is therefore unauthenticated and insecure.
the session is therefore a security risk.
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 connection to close.
Therefore, in other situations, the session may 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.6. Clients Subsystems 10.7. Clients 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
 End of changes. 33 change blocks. 
92 lines changed or deleted 141 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/