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/