draft-ietf-radext-dtls-01.txt   draft-ietf-radext-dtls-02.txt 
Network Working Group Alan DeKok Network Working Group Alan DeKok
INTERNET-DRAFT FreeRADIUS INTERNET-DRAFT FreeRADIUS
Category: Informational Category: Informational
<draft-ietf-radext-dtls-01.txt> <draft-ietf-radext-dtls-02.txt>
Expires: April 12, 2011 Expires: May 16, 2013
12 October 2010 16 July 2012
DTLS as a Transport Layer for RADIUS DTLS as a Transport Layer for RADIUS
draft-ietf-radext-dtls-01 draft-ietf-radext-dtls-02
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 "hidden" 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
how implementations of this proposal can co-exist with current RADIUS how implementations of this proposal can co-exist with current RADIUS
systems. systems.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
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 April 12, 2011 This Internet-Draft will expire on May 16, 2013
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2012 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
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction ............................................. 4 1. Introduction ............................................. 4
1.1. Terminology ......................................... 4 1.1. Terminology ......................................... 4
1.2. Requirements Language ............................... 5 1.2. Requirements Language ............................... 5
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. Changes from RADIUS over TLS (RADIUS/TLS) ........... 6 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. Reception of Packets ..................................... 8 3. Reception of Packets ..................................... 8
3.1. Protocol Disambiguation ............................. 9 4. Connection Management .................................... 9
4. Connection Management .................................... 10 4.1. Server Connection Management ........................ 9
4.1. Server Connection Management ........................ 10
4.1.1. Table Management ............................... 10 4.1.1. Table Management ............................... 10
4.2. Client Connection Management ........................ 11 4.1.2. Protocol Disambiguation ........................ 11
5. Processing Algorithm ..................................... 12 4.1.3. Processing Algorithm ........................... 12
6. Diameter Considerations .................................. 14 4.2. Client Connection Management ........................ 13
7. IANA Considerations ...................................... 14 5. Diameter Considerations .................................. 14
8. Security Considerations .................................. 14 6. IANA Considerations ...................................... 14
8.1. Legacy RADIUS Security .............................. 14 7. Security Considerations .................................. 14
8.2. Network Address Translation ......................... 15 7.1. Legacy RADIUS Security .............................. 14
9. References ............................................... 16 7.2. Resource Exhaustion ................................. 15
9.1. Normative references ................................ 16 7.3. Network Address Translation ......................... 16
9.2. Informative references .............................. 17 7.4. Wildcard Clients .................................... 16
8. References ............................................... 16
8.1. Normative references ................................ 16
8.2. Informative references .............................. 17
1. Introduction 1. Introduction
The RADIUS protocol as described in [RFC2865], [RFC2866], and The RADIUS protocol as described in [RFC2865], [RFC2866], [RFC5176],
[RFC5176] 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, previous specifications such as [RFC5176] have As a result, some specifications such as [RFC5176] have recommended
recommended using IPSec to secure RADIUS traffic. using IPSec to secure RADIUS traffic.
While RADIUS over IPSec has been widely deployed, there are While RADIUS over IPSec has been widely deployed, there are
difficulties with this approach. The simplest point against IPSec is difficulties with this approach. The simplest point against IPSec is
that there is no straightforward way for a RADIUS application to that there is no straightforward way for a RADIUS application to
control or monitor the network security policies. That is, the control or monitor the network security policies. That is, the
requirement that the RADIUS traffic be encrypted and/or authenticated requirement that the RADIUS traffic be encrypted and/or authenticated
is implicit in the network configuration, and is not enforced by the is implicit in the network configuration, and is not enforced by the
RADIUS application. RADIUS application.
This specification takes a different approach. We define a method This specification takes a different approach. We define a method
for using DTLS [RFC4347] 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 UDP-based Another benefit is that RADIUS over DTLS continues to be a UDP-based
protocol. This continuity ensures that existing network-layer protocol. This continuity ensures that existing network-layer
infrastructure (firewall rules, etc.) does not need to be changed infrastructure (firewall rules, etc.) does not need to be changed
when RADIUS clients and servers are upgraded to support RADIUS over when RADIUS clients and servers are upgraded to support RADIUS over
DTLS. DTLS.
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 continues to have all of themselves. This specification therefore shares with traditional
the issues that RADIUS currently has with order, reliability, and RADIUS the issues of order, reliability, and fragmentation.
fragmentation.
1.1. Terminology 1.1. Terminology
This document uses the following terms: This document uses the following terms:
RADIUS/DTLS RADIUS/DTLS
This term is a short-hand for "RADIUS over DTLS". This term is a short-hand for "RADIUS over DTLS".
RADIUS/DTLS client RADIUS/DTLS client
This term refers both to RADIUS clients as defined in [RFC2865], This term refers both to RADIUS clients as defined in [RFC2865],
and to Dynamic Authorization clients as defined in [RFC5176], that and to Dynamic Authorization clients as defined in [RFC5176], that
implement RADIUS/DTLS. implement RADIUS/DTLS.
RADIUS/DTLS server RADIUS/DTLS server
This term refers both to RADIUS servers as defined in [RFC2865], This term refers both to RADIUS servers as defined in [RFC2865],
and to Dynamic Authorization servers as defined in [RFC5176], that and to Dynamic Authorization servers as defined in [RFC5176], that
implement RADIUS/DTLS. implement RADIUS/DTLS.
RADIUS/UDP
RADIUS over UDP, as defined in [RFC2865].
RADIUS/TLS
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. The implementation MAY provide the capability further processing. See Section X.Y for additional requirements on
of logging the error, including the contents of the silently packets being silently discarded.
discarded packet, and SHOULD record the event in a statistics
counter.
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", "MAY",
and "OPTIONAL" in this document are to be interpreted as described in and "OPTIONAL" in this document are to be interpreted as described in
[RFC2119]. [RFC2119].
2. Building on Existing Foundations 2. Building on Existing Foundations
Adding DTLS as a RADIUS transport protocol requires a number of Adding DTLS as a RADIUS transport protocol requires a number of
changes to systems implementing standard RADIUS. This section changes to systems implementing standard RADIUS. This section
outlines those changes, and defines new behaviors necessary to outlines those changes, and defines new behaviors necessary to
implement DTLS. implement DTLS.
2.1. Changes to RADIUS 2.1. Changes to RADIUS
The RADIUS packet format is unchanged from [RFC2865], [RFC2866], and The RADIUS packet format is unchanged from [RFC2865], [RFC2866], and
[RFC5176]. Specifically, all of the following portions of RADIUS [RFC5176]. Specifically, all of the following portions of RADIUS
MUST be unchanged when using RADIUS over DTLS: MUST be unchanged when using RADIUS/DTLS:
* Packet format * Packet format
* Permitted codes * Permitted codes
* Request Authenticator calculation * Request Authenticator calculation
* Response Authenticator calculation * Response Authenticator calculation
* Minimum packet length * Minimum packet length
* Maximum packet length * Maximum packet length
* Attribute format * Attribute format
* Vendor-Specific Attribute (VSA) format * Vendor-Specific Attribute (VSA) format
* Permitted data types * Permitted data types
* Calculations of dynamic attributes such as CHAP-Challenge, * Calculations of dynamic attributes such as CHAP-Challenge,
or Message-Authenticator. or Message-Authenticator.
* Calculation of "encrypted" attributes such as Tunnel-Password. * Calculation of "obfuscated" attributes such as User-Password
* UDP port numbering and usage and Tunnel-Password.
* UDP port numbering and relationship between code and port
The RADIUS packets are encapsulated in DTLS, which acts as a In short, the application creates a RADIUS packet as usual, and then
transport layer for it. The requirements above ensure the simplest instead of sending it over a UDP socket, sends the packet to a DTLS
possible implementation and widest interoperability of this layer for encapsulation. DTLS then acts as a transport layer for
RADIUS, hence the names "RADIUS/UDP" and "RADIUS/DTLS".
The requirement that RADIUS remain largely unchanged ensures the
simplest possible implementation and widest interoperability of this
specification. specification.
The only changes made to RADIUS in this specification are the We note that the DTLS encapsulation of RADIUS means that the minimum
and maximum UDP packet sizes increase by the DTLS overhead.
Implementations should be aware of this, and take it into account
when allocating buffers to read and write RADIUS/DTLS packets.
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 "radsec". checks and the attribute encryption MUST be "radius/dtls".
All other portions of RADIUS are unchanged. All other aspects of RADIUS are unchanged.
2.2. Changes from RADIUS over TLS (RADIUS/TLS) 2.2. Similarities with RADIUS/TLS
While this specification is largely RADIUS/TLS over UDP instead of While this specification can be thought of as RADIUS/TLS over UDP
TCP, there are some differences between the two methods. instead of TCP, there are some differences between the two methods.
The bulk of [RFC6614] applies to this specification, so we do not
repeat it here.
This section goes through the [RADIUS/TLS] document in detail, This section explains the differences between RADIUS/TLS and
explaining the differences between RADIUS/TLS and RADIUS/DTLS. As RADIUS/DTLS, as semantic "patches" to [RFC6614]. The changes are as
most of [RADIUS/TLS] also applies to RADIUS/DTLS, we highlight only follows:
the changes here, explaining how to interpret [RADIUS/TLS] for this
specification:
* We replace references to "TCP" with "UDP" * We replace references to "TCP" with "UDP"
* We replace references to "RADIUS/TLS" with "RADIUS/DTLS" * We replace references to "RADIUS/TLS" with "RADIUS/DTLS"
* We replace references to "TLS" with "DTLS" * We replace references to "TLS" with "DTLS"
Those changes are sufficient to cover the majority of the differences Those changes are sufficient to cover the majority of the differences
between the two specifications. The text below goes through some of between the two specifications. The next section reviews some more
the sections of [RADIUS/TLS], giving additional commentary only where detailed changes from [RFC6614], giving additional commentary only
necessary. where necessary.
2.2.1. Changes from RADIUS/TLS to RADIUS/DTLS 2.2.1. Changes from RADIUS/TLS to RADIUS/DTLS
Section 2.1 does not apply to RADIUS/DTLS. The relationship between Section 2.1 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.
Section 2.2 applies also to RADIUS/DTLS, except for the Section 2.2 applies also to RADIUS/DTLS, except for the
recommendation that implementations "SHOULD" support recommendation that implementations "SHOULD" support
TLS_RSA_WITH_RC4_128_SHA, which does not apply to RADIUS/DTLS. TLS_RSA_WITH_RC4_128_SHA. This recommendation is a historical
artifact of RADIUS/TLS, and does not apply to RADIUS/DTLS.
Section 2.3 applies also to RADIUS/TLS. Section 2.3 does not apply to RADIUS/DTLS.
Section 2.4 does not apply to RADIUS/DTLS. See the comments above on Section 2.4 does not apply to RADIUS/DTLS. The relationship between
Section 2.1. The relationship between RADIUS packet codes and UDP RADIUS packet codes and UDP ports in RADIUS/DTLS is unchanged from
ports in RADIUS/DTLS is unchanged from RADIUS/UDP. RADIUS/UDP.
Section 3.3 item (1) does not apply to RADIUS/DTLS. Each RADIUS Section 3.3 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.3 item (3) does not apply to RTDLS. The relationship Section 3.3 item (3) does not apply to RADIUS/TDLS. The relationship
between RADIUS packet codes and UDP ports in RADIUS/DTLS is unchanged between RADIUS packet codes and UDP ports in RADIUS/DTLS is unchanged
from RADIUS. from RADIUS.
Section 3.3 item (4) does not apply to RADIUS/DTLS. As RADIUS/DTLS Section 3.3 item (4) does not apply to RADIUS/DTLS. As RADIUS/DTLS
still uses UDP for a transport, the use of negative ICMP responses is still uses UDP for a transport, the use of negative ICMP responses is
unchanged from RADIUS. unchanged from RADIUS.
2.2.2. Reinforcement of RADIUS/TLS 2.2.2. Reinforcement of RADIUS/TLS
We wish to re-iterate that much of [RADIUS/TLS] applies to this We re-iterate that much of [RFC6614] applies to this document.
document. Specifically, Section 4 and Section 6 of that document are Specifically, Section 4 and Section 6 of that document are applicable
applicable in whole to RADIUS/DTLS. in their entirety to RADIUS/DTLS.
3. Reception of Packets 3. Reception of Packets
As this specification permits implementations to to accept both As this specification permits implementations to to accept both
traditional RADIUS and DTLS packets on the same port, we define a RADIUS/UDP and RADIUS/DTLS packets on the same port, we require a
method to disambiguate between packets for the two protocols. This method to disambiguate packets between the two protocols. This
method is applicable only to RADIUS servers. RADIUS/DTLS clients method is applicable only to RADIUS/DTLS servers. RADIUS/DTLS
SHOULD use connected sockets, as discussed in Section X.Y, below. clients SHOULD use connected sockets, as discussed in Section X.Y,
below.
RADIUS/DTLS servers MUST maintain a boolean flag for each RADIUS RADIUS/DTLS servers MUST maintain a boolean "DTLS Required" flag for
client that indicates whether or not it supports RADIUS/DTLS. The each client that indicates if it requires a client to use
interpretation of this flag is as follows. If the flag is "false", RADIUS/DTLS. The interpretation of this flag is as follows. If the
then the client may support RADIUS/DTLS. Packets from the client
need to be examined to see if they are RADIUS or RADIUS/DTLS. If the
flag is "true" then the client supports RADIUS/DTLS, and all packets flag is "true" then the client supports RADIUS/DTLS, and all packets
from that client MUST be processed as RADIUS/DTLS. from that client MUST be processed as RADIUS/DTLS. If the flag is
"false", then the client supports RADIUS/UDP, but may still support
Note that this last requirement can impose significant changes for RADIUS/DTLS. Packets from the client need to be examined to see if
RADIUS clients. Clients can no longer have multiple independent they are RADIUS/UDP or RADIUS/DTLS.
RADIUS implementations or processes that originate packets. We
RECOMMEND that RADIUS/DTLS clients implement a local RADIUS proxy
that arbitrates all RADIUS traffic.
This flag MUST be exposed to administrators of the RADIUS server. As
RADIUS clients are upgraded, administrators can then manually mark
them as supporting RADIUS/DTLS.
We recognize, however, the upgrade path from RADIUS to RADIUS/DTLS is
important. This path requires an RADIUS/DTLS server to accept
packets from a RADIUS client without knowing beforehand if they are
RADIUS or DTLS. The method to distinguish between the two is defined
in the next section.
Once an RADIUS/DTLS server has established a DTLS session with a
client that had the flag set to "false", it MUST set the flag to
"true". This change forces all subsequent traffic from that client
to use DTLS, and prevents bidding-down attacks. The server SHOULD
also notify the administrator that it has successfully established
the first DTLS session with that client.
3.1. Protocol Disambiguation
When a RADIUS client is not marked as supporting RADIUS/DTLS, packets
from that client may be, or may not be DTLS. In order to provide a
robust upgrade path, the RADIUS/DTLS server MUST examine the packet
to see if it is RADIUS or DTLS. In order to justify the examination
methods, we first examine the packet formats for the two protocols.
The DTLS record format ([RFC4347] Section 4.1) is shown below, in
pseudo-code:
struct {
uint8 type;
uint16 version;
uint16 epoch;
uint48 sequence_number;
uint16 length;
uint8 fragment[DTLSPlaintext.length];
} DTLSPlaintext;
The RADIUS record format ([RFC2865] Section 3) is shown below, in
pseudo-code, with AuthVector.length=16.
struct {
uint8 code;
uint8 id;
uint16 length;
uint8 vector[AuthVector.length];
uint8 data[RadiusPacket.length - 20];
} RadiusPacket;
We can see here that a number of fields overlap between the two
protocols. The low byte of the DTLS version and the high byte of the
DTLS epoch overlap with the RADIUS length field. The DTLS length
field overlaps with the RADIUS authentication vector. At first
glance, it may be difficult for an application to accept both
protocols on the same port. However, this is not the case.
For the initial packet of a DTLS connection, the type field has value The "DTLS Required" flag MUST be exposed to administrators of the
22 (handshake), and the epoch and sequence number fields are server. As clients are upgraded, administrators can then manually
initialized to zero. The RADIUS code value of 22 has been assigned mark them as using RADIUS/DTLS.
as Resource-Free-Response, but it is not in wide use. In addition,
that packet code is a response packet, and would not be sent by a
RADIUS client to a server.
As a result, protocol disambiguation is straightforward. If the Once a RADIUS/DTLS server has established a DTLS session with a
first byte of the packet has value 22, it is a DTLS packet, and is a client that previously had the flag set to "false", the server MUST
DTLS connection initiation request. Otherwise, it is a RADIUS set the "DTLS Required" flag to "true". This change requires all
packet. subsequent traffic from that client to use DTLS, and prevents
bidding-down attacks. The server SHOULD also notify the
administrator that it has successfully established the first DTLS
session with that client.
Once a DTLS session has been established, a separate tracking table Note that this last requirement on servers can impose significant
is used to disambiguate the protocols. The definition of this changes for clients. Clients can no longer have multiple independent
tracking table is given in the next section. RADIUS implementations or processes that originate RADIUS/UDP and
RADIUS/DTLS packets. Instead, they need to use only one transport
layer, either UDP or DTLS.
The full processing algorithm is given below, in Section X.Y. It is therefore RECOMMENDED that RADIUS/DTLS clients use a local
proxy which arbitrates all traffic between the client and any
servers. The proxy SHOULD accept traffic only from the authorized
subsystems on the client machine, and SHOULD proxy that traffic to
one or more known servers.
4. Connection Management 4. Connection Management
Where [RADIUS/TLS] can rely on the TCP state machine to perform Where [RFC6614] can rely on the TCP state machine to perform
connection tracking, this specification cannot. As a result, connection tracking, this specification cannot. As a result,
implementations of this specification will need to perform connection implementations of this specification will need to perform connection
management of the DTLS session in the application layer. management of the DTLS session in the application layer.
4.1. Server Connection Management 4.1. Server Connection Management
An RADIUS/DTLS server MUST maintain a table that tracks ongoing DTLS A RADIUS/DTLS server MUST maintain a table that tracks ongoing client
sessions based on a key composed of the following 4-tuple: connections based on a key composed of the following 4-tuple:
* source IP address * source IP address
* source port * source port
* destination IP address * destination IP address
* destination port * destination port
The contents of the tracking table are a implementation-specific Note that this table is independent of IP address version (IPv4 or
value that describes an active DTLS session. This connection IPv6).
tracking allows DTLS packets that have been received to be associated
with an active DTLS session.
RADIUS/DTLS servers SHOULD NOT use a "connect" API to manage DTLS Each table entry contains the following information:
connections, as a connected UDP socket will accept packets only from
one source IP address and port. This limitation would prevent the
server from engaging in the normal RADIUS practice of accepting
packets from multiple clients on the same port.
Note that [RFC5080] Section 2.2.2 defines a duplicate detection cache Protocol Type
which tracks packets by key similar to that defined above. A flag which is either "RADIUS/UDP" for old-style RADIUS traffic,
or "RADIUS/DTLS" for RADIUS/DTLS connections.
DTLS Data
An implementation-specific variable containing information about
the active DTLS connection. For non-DTLS connections, this
variable MUST be empty.
Last Packet
A variable containing a timestamp which indicates when the last
valid packet was received for this connection. Packets which are
"silently discarded" MUST NOT update this variable.
Each entry may contain other information, such as idle timeouts,
connection lifetimes, and other implementation-specific data.
RADIUS/DTLS servers SHOULD NOT use connected sockets to read DTLS
packets from a client. This recommendation is because a connected
UDP socket will accept packets only from one source IP address and
port. This limitation would prevent the server from accepting
packets from multiple clients on the same port.
4.1.1. Table Management 4.1.1. Table Management
This tracking table is subject to Denial of Service (DoS) attacks. This tracking table is subject to Denial of Service (DoS) attacks due
RADIUS/DTLS servers SHOULD use the stateless cookie tracking to the ability of an attacker to forge UDP traffic. RADIUS/DTLS
technique described in [RFC4347] Section 4.2.1. DTLS sessions SHOULD servers SHOULD use the stateless cookie tracking technique described
NOT be added to the tracking table until a ClientHello packet has in [RFC6347] Section 4.2.1. DTLS sessions SHOULD NOT be added to the
been received with an appropriate Cookie value. tracking table until a ClientHello packet has been received with an
appropriate Cookie value. The requirement to accept RADIUS/UDP and
RADIUS/DTLS on the same port makes this recommendation difficult to
implement in practice. Server implementation SHOULD therefore have a
way of tracking partially setup DTLS connections. Servers SHOULD
limit both the number and impact on resources of partial connections.
Entries in the tracking table MUST deleted when a TLS Closure Alert Entries in the tracking table MUST deleted when a TLS Closure Alert
([RFC5246] Section 7.2.1) or a TLS Error Alert ([RFC5246] Section ([RFC5246] Section 7.2.1) or a TLS Error Alert ([RFC5246] Section
7.2.2) is received. Where the RADIUS specifications require that a 7.2.2) is received. Where the specifications require that a packet
RADIUS packet received via the DTLS session is to be "silently received via a DTLS session be "silently discarded", the entry in the
discarded", the entry in the tracking table corresponding to that tracking table corresponding to that DTLS session MUST also be
DTLS session MUST also be deleted, the DTLS session MUST be closed, deleted, the DTLS session MUST be closed, and any TLS session
and any TLS session resumption parameters for that session MUST be resumption parameters for that session MUST be discarded. The
discarded. implementation MAY provide the capability of logging the error,
including the contents of the silently discarded packet, and SHOULD
record the event in a statistics counter.
As UDP does not offer guaranteed delivery of messages, RADIUS/DTLS As UDP does not guarantee delivery of messages, RADIUS/DTLS servers
servers MUST also maintain a timestamp per DTLS session. The MUST also maintain a "Last Packet" timestamp per DTLS session. The
timestamp SHOULD be updated on reception of a valid DTLS packet. The timestamp SHOULD be updated on reception of a valid DTLS packet. The
timestamp MUST NOT be updated in other situations. When a session timestamp MUST NOT be updated in other situations. When a session
has not been used for a period of time, the server SHOULD pro- has not received a packet for a period of time, it is labelled
actively close it, and delete the DTLS session from the tracking "idle". The server SHOULD delete idle DTLS session from the tracking
table. The server MAY cache the TLS session parameters, in order to table after an "idle timeout". The server MAY cache the TLS session
provide for fast session resumption. parameters, in order to provide for fast session resumption.
This session lifetime SHOULD be exposed as configurable setting. It This session "idle timeout" SHOULD be exposed to the administrator as
SHOULD NOT be set to less than 60 seconds, and SHOULD NOT be set to a configurable setting. It SHOULD NOT be set to less than 60
more than 600 seconds (10 minutes). The minimum value useful value seconds, and SHOULD NOT be set to more than 600 seconds (10 minutes).
for this timer is determined by the application-layer watchdog The minimum value useful value for this timer is determined by the
mechanism defined in the following section. application-layer watchdog mechanism defined in the following
section.
RADIUS/DTLS servers SHOULD also keep track of the total number of RADIUS/DTLS servers SHOULD also keep track of the total number of
sessions in the tracking table, and refuse to create new sessions sessions in the tracking table. They SHOULD stop the creating of new
when a large number are already being tracked. As system sessions when a large number are already being tracked. This
capabilities vary widely, we can only recommend that this number "maximum sessions" number SHOULD be exposed to administrators as a
SHOULD be exposed as a configurable setting. configurable setting.
4.2. Client Connection Management 4.1.2. Protocol Disambiguation
RADIUS/DTLS clients SHOULD use an operating system API to "connect" a When the "DTLS Required" flag for a client is set to "false", the
UDP socket. This "connected" socket will then rely on the operating client may, or may not be sending DTLS packets. For existing
system to perform connection tracking, and will be simpler than the connections, protocol disambiguation is simple, the "Protocol Type"
method described above for servers. RADIUS/DTLS clients SHOULD NOT field in the tracking table entry is examined. New connections must
use "unconnected" sockets, as it causes increased complexity in the still be disambiguated.
client application.
Once a DTLS session is established, an RADIUS/DTLS client SHOULD use In order to provide a robust upgrade path, the RADIUS/DTLS server
the application-layer watchdog algorithm defined in [RFC3539] to MUST examine the packet to see if it is RADIUS/UDP or RADIUS/DTLS.
determine server responsiveness. The Status-Server packet defined in This examination method is defined here.
[RFC5997] MUST be used as the "watchdog packet" in the watchdog
algorithm.
RADIUS/DTLS clients SHOULD pro-actively close sessions when they have We justify the examination methods by analysing the packet formats
been idle for a period of time. We RECOMMEND that a session be for the two protocols. We assume that the server has a buffer in
closed when no traffic over than watchdog packets and (possibly) which it has received a UDP packet matching no entry on the
responses have been sent for three watchdog timeouts. This behavior conneciton tracking table. It must then analyse this buffer to
ensures that clients do not waste resources on the server by causing determine which protocol is used to process the packet.
it to track idle sessions.
RADIUS/DTLS clients SHOULD NOT send both normal RADIUS and The DTLS record format ([RFC6347] Section 4.1) is shown below, in
RADIUS/DTLS packets from the same source socket. This practice pseudo-code:
causes increased complexity in the client application, and increases
the potential for security breaches due to implementation issues.
RADIUS/DTLS clients MUST NOT send both normal RADIUS and RADIUS/DTLS struct {
packets over the same key as defined in Section 4.1, abovre (source uint8 type;
IP, source port, destination IP, destination port). Doing so would uint16 version;
require that servers perform RADIUS and RADIUS/DTLS determination for uint16 epoch;
every packet that has been received. uint48 sequence_number;
uint16 length;
uint8 fragment[DTLSPlaintext.length];
} DTLSPlaintext;
RADIUS/DTLS clients SHOULD use TLS session resumption, where The RADIUS record format ([RFC2865] Section 3) is shown below, in
possible. This practice lowers the time and effort required to start pseudo-code, with AuthVector.length=16.
a DTLS session with a server, and increases network responsiveness.
5. Processing Algorithm struct {
uint8 code;
uint8 id;
uint16 length;
uint8 vector[AuthVector.length];
uint8 data[RadiusPacket.length - 20];
} RadiusPacket;
The following algorithm MUST be used by an implementation of this We can see here that a number of fields overlap between the two
protocol. This algorithm is used to route packets to the appropriate protocols. At first glance, it seems difficult for an application to
destination. We assume the following variables: accept both protocols on the same port. However, this is not the
case.
D - implementation-specific handle to an existing DTLS session The initial DTLS packet of a connection requires that the type field
(first octet) has value 22 (handshake). The first octet of a RADIUS
packet is the code field. The code value of 22 has been assigned as
Resource-Free-Response. That code is intended to be a response from
a server to a client, and will therefore never be sent by a client to
a server.
P - UDP packet received from the network. This packet MUST As a result, protocol disambiguation for new connections to a server
also contain information about source IP/port, and is straightforward. Only the first octet of the packet needs to be
destination IP/port. examined to disambiguate RADIUS/DTLS from RADIUS/UDP. If that octet
has value 22, then the packet is likely to be RADIUS/DTLS.
Otherwise, the packet is likely to be RADIUS/UDP.
R - a RADIUS packet 4.1.3. Processing Algorithm
T - a tracking table used to manage ongoing DTLS sessions When a RADIUS/DTLS server recieves a packet, it uses the following
algorithm to process that packet. As with RADIUS/UDP, packets from
unknown clients MUST be silently discarded.
We also presume the following functions or functionality exists: The "DTLS Required" flag for that client is examined. If it is set
to "true", then the packet MUST be processed as RADIUS/DTLS.
receive_packet_from_network() - a function that reads a packet If the "DTLS Required" flag is set to "false", the connection
from the network, and returns P as above. We presume also that tracking table is examined. Packets matching an existing entry MUST
this function performs the normal RADIUS client validation, and be processed as defined by the "Protocol Type" field of that entry.
does not return P if the packet is from an unknown client.
lookup_dtls_session() - a function that takes a packet P, a table If the "DTLS Required" flag is set to "false" and no entry exists in
T, and uses P to look up the corresponding DTLS session in T. It the connection tracking table, then the first octet of the packet is
returns either a session D, or a "null" indicator that no examined. If it has value 22, then the packet MUST be processed as
corresponding session exists. RADIUS/DTLS. Otherwise, the packet MUST be processed as RADIUS/UDP.
client_supports_rdtls() - a function that takes a packet P, and In all cases, the packet MUST be checked for correctness. For
returns a boolean value as to whether or not the client RADIUS/UDP, any packets which are silently discarded MUST NOT affect
originating the packet was marked as supporting RADIUS/DTLS. the state of any variable in the session tracking table. For
RADIUS/DTLS, any packets which are discarded by the DTLS layer MUST
NOT affect the state of any variable in the session tracking table.
For RADIUS/DTLS, any RADIUS packets which are subsequently silently
discarded MUST result in the removal of the associated entry from the
connection tracking table.
process_dtls_packet() - a function that takes a DTLS packet P, and When the packet matches an existing entry in the connection table,
a DTLS session D. It performs all necessary steps to use D to and is accepted for processing by the server, the "Last Packet"
setup a DTLS session, and to decode P (where possible) into a timestamp is updated. Where the packet does not match any entry in
RADIUS packet. This function is also expected to perform checks the connection table, a new connection is created using the 4-tuple
for TLS errors. On any fatal errors, it closes the session, and key defined above. The "Protocol Type" flag for that connection is
deletes D from the tracking table T. If a RADIUS packet is set to "RADIUS/DTLS", or "RADIUS/UDP", as determined by examining the
decoded from P, it is returned by the function as R, otherwise a first octet of the packet.
"null" indicator is returned.
process_dtls_clienthello() - a function that takes a DTLS packet When a server has the clients "DTLS Required" flag set to "false", it
P, and initiates a DTLS session. If P contains a valid DTLS MUST set the flag to "true" after establishing a DTLS session with
Cookie, a DTLS session D is created, and stored in the tracking that client. It MUST NOT set the flag to "true" until a DTLS session
table T. If P does not contain a DTLS Cookie, no session is has been fully established. Doing so would mean that attackers could
created, and instead a HelloVerifyRequest containing a cookie is perform a DoS attack by sending forged DTLS ClientHello packets to a
sent in response. Packets containing invalid cookies are server.
discarded.
process_radius_packet() - a function that takes a RADIUS packet P, 4.2. Client Connection Management
and processes it using the normal RADIUS methods.
The algorithm is as follows: Clients SHOULD use "connected" UDP sockets for RADIUS/DTLS traffic.
A connected socket will then rely on the operating system to perform
connection tracking. Clients SHOULD NOT use "unconnected" sockets
for RADIUS/DTLS traffic. Using unconnected sockets would require the
client to implement a connection tracking table, which is complex and
unnecessary.
P = receive_packet_from_network() Once a DTLS session is established, a RADIUS/DTLS client SHOULD use
D = lookup_dtls_session(T, P) the application-layer watchdog algorithm defined in [RFC3539] to
determine server responsiveness. The Status-Server packet defined in
[RFC5997] MUST be used as the "watchdog packet" in the watchdog
algorithm.
if (D || client_supports_rdtls(P)) { RADIUS/DTLS clients SHOULD pro-actively close sessions when they have
R = process_dtls_packet(D, P) been idle for a period of time. Clients SHOULD close a session when
if (R) { no traffic other than watchdog packets and (possibly) watchdog
process_radius_packet(R) responses have been sent for three watchdog timeouts. This behavior
} ensures that clients do not waste resources on the server by causing
it to track idle sessions.
} else if (first_octet_of_packet_is_22(P)) { RADIUS/DTLS clients MUST NOT send both RADIUS/UDP and RADIUS/DTLS
process_dtls_clienthello(P) packets over the same key of (source IP, source port, destination IP,
destination port) as defined in Section 4.1, above . Doing so would
make it impossible to correctly process either kind of packet.
} else { RADIUS/DTLS clients SHOULD NOT send both RADIUS/UDP and RADIUS/DTLS
process_radius_packet(P) packets to different servers from the same source socket. This
} practice causes increased complexity in the client application, and
increases the potential for security breaches due to implementation
issues.
For simplicity, the timers necessary to perform expiry of "old" RADIUS/DTLS clients SHOULD use TLS session resumption. This practice
sessions are not included in the above algorithm. This algorithm may lowers the time and effort required to start a DTLS session with a
also need to be modified if the RADIUS/DTLS server supports client server, and increases network responsiveness.
validation by methods other than source IP address.
6. Diameter Considerations 5. Diameter Considerations
This specification is for a transport layer specific to RADIUS. As a This specification defines a transport layer for RADIUS. It makes no
result, there are no Diameter considerations. other changes to the RADIUS protocol. As a result, there are no
Diameter considerations.
7. IANA Considerations 6. IANA Considerations
This specification does not create any new registries, nor does it This specification does not create any new registries, nor does it
require assignment of any protocol parameters. require assignment of any protocol parameters.
8. Security Considerations 7. Security Considerations
This entire specification is devoted to discussing security This entire 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, 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 [RADIUS/TLS] also apply TLS and RADIUS security issues discussed in [RFC6614] also apply to
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 only new portion of the specification that could have security The only new portion of the specification that could have security
implications is a servers ability to accept both RADIUS and DTLS implications is a servers ability to accept both RADIUS and DTLS
packets on the same port. The filter that disambiguates the two packets on the same port. The filter that disambiguates the two
protocols is simple, and is just a check for the value of one byte. 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 do not expect this check to have any security issues.
We also note that nothing prevents malicious clients from sending We also note that nothing prevents malicious clients from sending
DTLS packets to existing RADIUS implementations, or RADIUS packets to DTLS packets to existing RADIUS implementations, or RADIUS packets to
existing DTLS implementations. There should therefore be no issue existing DTLS implementations. There should therefore be no issue
with clients sending RADIUS/DTLS packets to legacy servers that do with clients sending RADIUS/DTLS packets to legacy servers that do
not support the protocol. not support the protocol. These packets will be silently ignored,
and will not change the security profile of the server.
8.1. Legacy RADIUS Security 7.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.
We RECOMMEND that all RADIUS clients and servers implement this It is RECOMMENDED that all RADIUS clients and servers implement this
specification as soon as possible. New attacks on MD5 have appeared specification. New attacks on MD5 have appeared over the past few
over the past few years, and there is a distinct possibility that MD5 years, and there is a distinct possibility that MD5 may be completely
may be completely broken in the near future. 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 that depends on RADIUS. Attackers could of all network security which depends on RADIUS. Attackers could
obtain user passwords, and possibly gain complete network access. It obtain user passwords, and possibly gain complete network access. We
is difficult to overstate the disastrous consequences of a successful cannot overstate the disastrous consequences of a successful attack
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
user interface otherwise unchanged. This practice MUST NOT be used. user interface otherwise unchanged. This practice MUST NOT be used.
The administrator MUST be given the option to use DTLS. Any shared The administrator MUST be given the option to use DTLS. Any shared
secret used for RADIUS MUST NOT be used for DTLS. Re-using a shared secret used for RADIUS/UDP MUST NOT be used for DTLS. Re-using a
secret between RADIUS and DTLS would negate all of the benefits found shared secret between RADIUS/UDP and RADIUS/DTLS would negate all of
by using DTLS. the benefits found by using DTLS.
When using PSK methods, RADIUS/DTLS clients MUST support keys (i.e.
shared secrets) that are at least 32 characters in length.
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. RADIUS/DTLS allows the administrator to choose the cipher suite. Where
client implementors SHOULD expose a configuration that allows an certificates are used, RADIUS/DTLS client implementors MUST expose a
administrator to configure all certificates necessary for configuration which allows an administrator to configure all
certificate-based authentication. These certificates include client, certificates necessary for certificate-based authentication. These
server, and root certificates. certificates include client, server, and root certificates.
When using PSK methods, RADIUS/DTLS servers MUST support keys (i.e. When using PSK methods, RADIUS/DTLS servers MUST support keys (i.e.
shared secrets) that are at least 32 characters in length. shared secrets) that are at least 32 characters in length. These
RADIUS/DTLS server administrators MUST use strong shared secrets for keys SHOULD be able to contain arbitrary binary data. RADIUS/DTLS
those PSK methods. We RECOMMEND using keys derived from a server administrators MUST use strong shared secrets for those PSK
cryptographically secure pseudo-random number generator (CSPRNG). methods. We RECOMMEND using keys derived from a cryptographically
For example, a reasonable key may be 32 characters of a SHA-256 hash secure pseudo-random number generator (CSPRNG). For example, a
of at least 64 bytes of data taken from a CSPRNG. If this method reasonable key may be 32 characters of a SHA-256 hash of at least 64
seems too complicated, a certificate-based TLS method SHOULD be used octetss of data taken from a CSPRNG. If this method seems too
instead. complicated, a certificate-based TLS method SHOULD be used instead.
The previous RADIUS practice of using shared secrets that are minor The previous RADIUS practice of using shared secrets that are minor
variations of words is NOT RECOMMENDED, as it would negate nearly all variations of words is NOT RECOMMENDED, as it would negate nearly all
of the security of DTLS. of the security of DTLS.
8.2. Network Address Translation 7.2. Resource Exhaustion
The use of DTLS allows DoS attacks, and resource exhaustion attacks
which were not possible in RADIUS/UDP. These attacks are the same as
described in [RFC6614] Section X.Y.
Use of the connection tracking table defined in Section X.Y can
result in resource exhaustion. Servers MUST therefore limit the
absolute number of entries in the table. Servers MUST limit the
number of partially open DTLS sessions. These limits SHOULD be
exposed to the administrator as configurable settings.
7.3. Network Address Translation
Network Address Translation (NAT) is fundamentally incompatible with Network Address Translation (NAT) is fundamentally incompatible with
RADIUS. RADIUS uses the source IP address to determine the shared RADIUS/UDP. RADIUS/UDP uses the source IP address to determine the
secret for the client, and NAT hides many clients behind one source shared secret for the client, and NAT hides many clients behind one
IP address. source IP address.
The migration flag described above in Section 3 is also tracked per The migration flag described above in Section 3 is also tracked per
source IP address. Using a NAT in front of many RADIUS clients source IP address. Using a NAT in front of many RADIUS clients
negates the function of the flag, making it impossible to migrate negates the function of the flag, making it impossible to migrate
clients in a secure fashion. multiple clients in a secure fashion.
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
capability were allowed, it would permit a downgrade attack to occur, behavior is allowed, it would permit a downgrade attack to occur, and
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. transport such as DTLS MUST be used. As discussed below, a method
for uniquely identifying each client MUST be used.
9. References 7.4. Wildcard Clients
9.1. Normative references Some RADIUS server implementations allow for "wildcard" clients.
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
RADIUS/UDP, as it means multiple clients use the same shared secret.
When a client is a "wildcard", then RADIUS/DTLS MUST be used.
Clients MUST be uniquely identified, and any certificate or PSK used
MUST be unique to each client.
8. References
8.1. Normative references
[RFC2865] [RFC2865]
Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote
Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000.
[RFC3539] [RFC3539]
Aboba, B. et al., "Authentication, Authorization and Accounting Aboba, B. et al., "Authentication, Authorization and Accounting
(AAA) Transport Profile", RFC 3539, June 2003. (AAA) Transport Profile", RFC 3539, June 2003.
[RFC4347]
Rescorla E., and Modadugu, N., "Datagram Transport Layer Security",
RFC 4347, April 2006.
[RFC5246] [RFC5246]
Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS)
Protocol Version 1.2", RFC 5246, August 2008. Protocol Version 1.2", RFC 5246, August 2008.
[RADIUS/TLS]
Winter. S, et. al., "TLS encryption for RADIUS over TCP", draft-
ietf-radext-radsec-06.txt, March 2010 (work in progress)
[RFC5997] [RFC5997]
DeKok, A., "Use of Status-Server Packets in the Remote DeKok, A., "Use of Status-Server Packets in the Remote
Authentication Dial In User Service (RADIUS) Protocol", RFC 5997, Authentication Dial In User Service (RADIUS) Protocol", RFC 5997,
August 2010. August 2010.
9.2. Informative references [RFC6347]
Rescorla E., and Modadugu, N., "Datagram Transport Layer Security",
RFC 6347, April 2006.
[RFC6614]
Winter. S, et. al., "TLS encryption for RADIUS over TCP", RFFC
6614, May 2012
8.2. Informative references
[RFC1321] [RFC1321]
Rivest, R. and S. Dusse, "The MD5 Message-Digest Algorithm", RFC Rivest, R. and S. Dusse, "The MD5 Message-Digest Algorithm", RFC
1321, April 1992. 1321, April 1992.
[RFC2119] [RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, March, 1997. Levels", RFC 2119, March, 1997.
[RFC2866] [RFC2866]
Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
[RFC5080]
Nelson, D. and DeKok, A, "Common Remote Authentication Dial In User
Service (RADIUS) Implementation Issues and Suggested Fixes", RFC
5080, December 2007.
[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.
[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
Parts of the text in Section 3 defining the Request and Response Parts of the text in Section 3 defining the Request and Response
Authenticators were taken with minor edits from [RFC2865] Section 3. Authenticators were taken with minor edits from [RFC2865] Section 3.
The author would like to thank Mike McCauley of Open Systems
Consultants for making a Radiator server available for inter-
operability testing.
Authors' Addresses Authors' Addresses
Alan DeKok Alan DeKok
The FreeRADIUS Server Project The FreeRADIUS Server Project
http://freeradius.org http://freeradius.org
Email: aland@freeradius.org Email: aland@freeradius.org
 End of changes. 99 change blocks. 
339 lines changed or deleted 364 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/