draft-ietf-radext-dtls-08.txt   draft-ietf-radext-dtls-09.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-08.txt> <draft-ietf-radext-dtls-09.txt>
Expires: September 24, 2014 Expires: October 5, 2014
24 January 2014 5 February 2014
DTLS as a Transport Layer for RADIUS DTLS as a Transport Layer for RADIUS
draft-ietf-radext-dtls-08 draft-ietf-radext-dtls-09
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 September 24, 2014 This Internet-Draft will expire on October 5, 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 11 skipping to change at page 3, line 11
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
1.3. Document Status ..................................... 5 1.3. Document Status ..................................... 5
2. Building on Existing Foundations ......................... 6 2. Building on Existing Foundations ......................... 7
2.1. Changes to RADIUS ................................... 6 2.1. Changes to RADIUS ................................... 7
2.2. Similarities with RADIUS/TLS ........................ 7 2.2. Similarities with RADIUS/TLS ........................ 8
2.2.1. Changes from RADIUS/TLS to RADIUS/DTLS ......... 7 2.2.1. Changes from RADIUS/TLS to RADIUS/DTLS ......... 8
3. Interaction with RADIUS/UDP .............................. 8 3. Interaction with RADIUS/UDP .............................. 9
3.1. DTLS Port and Packet Types .......................... 9 3.1. DTLS Port and Packet Types .......................... 10
3.2. Server Behavior ..................................... 9 3.2. Server Behavior ..................................... 10
4. Client Behavior .......................................... 10 4. Client Behavior .......................................... 11
5. Session Management ....................................... 10 5. Session Management ....................................... 11
5.1. Server Session Management ........................... 11 5.1. Server Session Management ........................... 12
5.1.1. Session Opening and Closing .................... 11 5.1.1. Session Opening and Closing .................... 12
5.2. Client Session Management ........................... 13 5.2. Client Session Management ........................... 14
6. Implementation Guidelines ................................ 14 6. Implementation Guidelines ................................ 15
6.1. Client Implementations .............................. 15 6.1. Client Implementations .............................. 16
6.2. Server Implementations .............................. 16 6.2. Server Implementations .............................. 17
7. Implementation Experience ................................ 16 7. Implementation Experience ................................ 17
8. Diameter Considerations .................................. 16 8. Diameter Considerations .................................. 18
9. IANA Considerations ...................................... 17 9. IANA Considerations ...................................... 18
10. Security Considerations ................................. 17 10. Security Considerations ................................. 18
10.1. Legacy RADIUS Security ............................. 18 10.1. Legacy RADIUS Security ............................. 19
10.2. Resource Exhaustion ................................ 18 10.2. Resource Exhaustion ................................ 20
10.3. Client-Server Authentication with DTLS ............. 19 10.3. Client-Server Authentication with DTLS ............. 20
10.4. Network Address Translation ........................ 20 10.4. Network Address Translation ........................ 21
10.5. Wildcard Clients ................................... 21 10.5. Wildcard Clients ................................... 22
10.6. Session Closing .................................... 21 10.6. Session Closing .................................... 22
10.7. Client Subsystems .................................. 21 10.7. Client Subsystems .................................. 22
11. References .............................................. 22 11. References .............................................. 23
11.1. Normative references ............................... 22 11.1. Normative references ............................... 23
11.2. Informative references ............................. 23 11.2. Informative references ............................. 24
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.
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 an application to control or
control or monitor the network security policies. That is, the monitor the network security policies. That is, the requirement that
requirement that the RADIUS traffic be encrypted and/or authenticated the RADIUS traffic be encrypted and/or authenticated is implicit in
is implicit in the network configuration, and is not enforced by the the network configuration, and cannot be enforced by the RADIUS
RADIUS application. application.
This specification takes a different approach. We define a method This specification takes a different approach. We define a method
for using DTLS [RFC6347] as a RADIUS transport protocol. This for using DTLS [RFC6347] as a RADIUS transport protocol. This
approach has the benefit that the RADIUS application can directly approach has the benefit that the RADIUS application can directly
monitor and control the security policies associated with the traffic monitor and control the security policies associated with the traffic
that it processes. that it processes.
Another benefit is that RADIUS over DTLS continues to be a User Another benefit is that RADIUS over DTLS continues to be a User
Datagram Protocol (UDP) based protocol. 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
skipping to change at page 5, line 30 skipping to change at page 5, line 30
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].
1.3. Document Status 1.3. Document Status
This document is an Experimental RFC. Please see [RFC6614] Section This document is an Experimental RFC.
1.3 for a discussion of the issues surrounding the use of TLS with
RADIUS. It is one out of several approaches to address known cryptographic
weaknesses of the RADIUS protocol, such as [RFC6614]. This
specification does not fulfill all recommendations on a AAA transport
profile as per [RFC3539]; however unlike [RFC6614], it is based on
UDP, does not have head-of-line blocking issues.
If this specification is indeed selected for advancement to Standards
Track, certificate verification options ([RFC6614] Section 2.3, point
2) needs to be refined.
Another experimental characteristic of this specification is the
question of key management between RADIUS/DTLS peers. RADIUS/UDP
only allowed for manual key management, i.e., distribution of a
shared secret between a client and a server. RADIUS/DTLS allows
manual distribution of long-term proofs of peer identity as well (by
using TLS-PSK ciphersuites, or identifying clients by a certificate
fingerprint), but as a new feature enables use of X.509 certificates
in a PKIX infrastructure. It remains to be seen if one of these
methods will prevail or if both will find their place in real-life
deployments. The authors can imagine pre-shared keys (PSK) to be
popular in small-scale deployments (Small Office, Home Office (SOHO)
or isolated enterprise deployments) where scalability is not an issue
and the deployment of a Certification Authority (CA) is considered
too much of a hassle; however, the authors can also imagine large
roaming consortia to make use of PKIX. Readers of this specification
are encouraged to read the discussion of key management issues within
[RFC6421] as well as [RFC4107].
It has yet to be decided whether this approach is to be chosen for
Standards Track. One key aspect to judge whether the approach is
usable on a large scale is by observing the uptake, usability, and
operational behavior of the protocol in large-scale, real-life
deployments.
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
skipping to change at page 8, line 48 skipping to change at page 9, line 48
potentially subject to security downgrade attacks. It is not potentially subject to security downgrade attacks. It is not
sufficient to just disable RADIUS/UDP and enable RADIUS/DTLS. RADIUS sufficient to just disable RADIUS/UDP and enable RADIUS/DTLS. RADIUS
has no provisions for protocol negotiation, so simply disabling has no provisions for protocol negotiation, so simply disabling
RADIUS/UDP would result in timeouts, lost traffic, and network RADIUS/UDP would result in timeouts, lost traffic, and network
instabilities. instabilities.
The end result of this specification is that nearly all RADIUS/UDP The end result of this specification is that nearly all RADIUS/UDP
implementations should transition to using a secure alternative. In implementations should transition to using a secure alternative. In
some cases, RADIUS/UDP may remain where IPSec is used as a transport, some cases, RADIUS/UDP may remain where IPSec is used as a transport,
or where implementation and/or business reasons preclude a change. or where implementation and/or business reasons preclude a change.
However, long-term use of RADIUS/UDP is not recommended. However, we do not recommend long-term use of RADIUS/UDP outside of
isolated and secure networks.
This section describes how clients and servers should use This section describes how clients and servers should use
RADIUS/DTLS, and how it interacts with RADIUS/UDP. RADIUS/DTLS, and how it interacts with RADIUS/UDP.
3.1. DTLS Port and Packet Types 3.1. DTLS Port and Packet Types
The default destination port number for RADIUS/DTLS is UDP/2083. The default destination port number for RADIUS/DTLS is UDP/2083.
There are no separate ports for authentication, accounting, and There are no separate ports for authentication, accounting, and
dynamic authorization changes. The source port is arbitrary. The dynamic authorization changes. The source port is arbitrary. The
text above in [RFC6614] Section 3.4 describes issues surrounding the text above in [RFC6614] Section 3.4 describes issues surrounding the
skipping to change at page 10, line 22 skipping to change at page 11, line 25
DTLS transport. Instead, clients SHOULD use DTLS as a transport DTLS transport. Instead, clients SHOULD use DTLS as a transport
layer only when administratively configured. If a client is layer only when administratively configured. If a client is
configured to use DTLS and the server appears to be unresponsive, the configured to use DTLS and the server appears to be unresponsive, the
client MUST NOT fall back to using RADIUS/UDP. Instead, the client client MUST NOT fall back to using RADIUS/UDP. Instead, the client
should treat the server as being down. should treat the server as being down.
RADIUS clients often had multiple independent RADIUS implementations RADIUS clients often had multiple independent RADIUS implementations
and/or processes that originate packets. This practice was simple to and/or processes that originate packets. This practice was simple to
implement, but the result is that each independent subsystem must implement, but the result is that each independent subsystem must
independently discover network issues or server failures. It is independently discover network issues or server failures. It is
therefore RECOMMENDED that clients use a local proxy as described in therefore RECOMMENDED that clients with multiple internal RADIUS
Section 6.1, below. sources use a local proxy as described in Section 6.1, below.
Clients may implement "pools" of servers for fail-over or load- Clients may implement "pools" of servers for fail-over or load-
balancing. These pools SHOULD NOT mix RADIUS/UDP and RADIUS/DTLS balancing. These pools SHOULD NOT mix RADIUS/UDP and RADIUS/DTLS
servers. servers.
5. Session Management 5. Session Management
Where [RFC6614] can rely on the TCP state machine to perform session Where [RFC6614] can rely on the TCP state machine to perform session
tracking, this specification cannot. As a result, implementations of tracking, this specification cannot. As a result, implementations of
this specification may need to perform session management of the DTLS this specification may need to perform session management of the DTLS
skipping to change at page 12, line 10 skipping to change at page 13, line 10
Sessions MUST also be deleted when a RADIUS packet fails validation Sessions MUST also be deleted when a RADIUS packet fails validation
due to a packet being malformed, or when it has an invalid Message- due to a packet being malformed, or when it has an invalid Message-
Authenticator, or invalid Request Authenticator. There are other Authenticator, or invalid Request Authenticator. There are other
cases when the specifications require that a packet received via a cases when the specifications require that a packet received via a
DTLS session be "silently discarded". In those cases, DTLS session be "silently discarded". In those cases,
implementations MAY delete the underlying session as described above. implementations MAY delete the underlying session as described above.
There are few reasons to communicate with a NAS which is not There are few reasons to communicate with a NAS which is not
implementing RADIUS. implementing RADIUS.
The above paragraph can be rephrased more generically. A session A session MUST be deleted when non-RADIUS traffic is received over
MUST be deleted when non-RADIUS traffic is received over it. This it. This specification is for RADIUS, and there is no reason to
specification is for RADIUS, and there is no reason to allow non- allow non-RADIUS traffic over a RADIUS/DTLS session. A session MUST
RADIUS traffic over a RADIUS/DTLS session. A session MUST be deleted be deleted when RADIUS traffic fails to pass security checks. There
when RADIUS traffic fails to pass security checks. There is no is no reason to permit insecure networks. A session SHOULD NOT be
reason to permit insecure networks. A session SHOULD NOT be deleted deleted when a well-formed, but "unexpected" RADIUS packet is
when a well-formed, but "unexpected" RADIUS packet is received over received over it. Future specifications may extend RADIUS/DTLS, and
it. Future specifications may extend RADIUS/DTLS, and we do not want we do not want to forbid those specifications.
to forbid those specifications.
The goal of the above requirements is to ensure security, while
maintaining flexibility. Any security related issue causes the
connection to be closed. After the security restrictions have been
applied, any unexpected traffic may be safely ignored, as it cannot
cause a security issue. There is no need to close the session for
unexpected but valid traffic, and the session can safely remain open.
Once a DTLS session is established, a RADIUS/DTLS server SHOULD use Once a DTLS session is established, a RADIUS/DTLS server SHOULD use
DTLS Heartbeats [RFC6520] to determine connectivity between the two DTLS Heartbeats [RFC6520] to determine connectivity between the two
servers. A server SHOULD also use watchdog packets from the client servers. A server SHOULD also use watchdog packets from the client
to determine that the session is still active. to determine that the session is still active.
As UDP does not guarantee delivery of messages, RADIUS/DTLS servers As UDP does not guarantee delivery of messages, RADIUS/DTLS servers
which do not implement an application-layer watchdog MUST also which do not implement an application-layer watchdog MUST also
maintain a "Last Traffic" timestamp per DTLS session. The timestamp maintain a "Last Traffic" timestamp per DTLS session. The
SHOULD be updated on reception of a valid RADIUS/DTLS packet, or a granularity of this timestamp is not critical, and could be limited
DTLS heartbeat. The timestamp MUST NOT be updated in other to one second intervals. The timestamp SHOULD be updated on
situations. When a session has not received a packet for a period of reception of a valid RADIUS/DTLS packet, or a DTLS Heartbeat, but no
time, it is labelled "idle". The server SHOULD delete idle DTLS more than once per interval. The timestamp MUST NOT be updated in
sessions after an "idle timeout". The server MAY cache the TLS other situations.
session parameters, in order to provide for fast session resumption.
When a session has not received a packet for a period of time, it is
labelled "idle". The server SHOULD delete idle DTLS sessions after
an "idle timeout". The server MAY cache the TLS session parameters,
in order to provide for fast session resumption.
This session "idle timeout" SHOULD be exposed to the administrator as This session "idle timeout" SHOULD be exposed to the administrator as
a configurable setting. It SHOULD NOT be set to less than 60 a configurable setting. It SHOULD NOT be set to less than 60
seconds, and SHOULD NOT be set to more than 600 seconds (10 minutes). seconds, and SHOULD NOT be set to more than 600 seconds (10 minutes).
The minimum value useful value for this timer is determined by the The minimum value useful value for this timer is determined by the
application-layer watchdog mechanism defined in the following application-layer watchdog mechanism defined in the following
section. section.
RADIUS/DTLS servers SHOULD also monitor the total number of open RADIUS/DTLS servers SHOULD also monitor the total number of open
sessions. They SHOULD have a "maximum sessions" setting exposed to sessions. They SHOULD have a "maximum sessions" setting exposed to
skipping to change at page 18, line 4 skipping to change at page 19, line 14
The fixed shared secret given above in Section 2.2.1 is acceptible The fixed shared secret given above in Section 2.2.1 is acceptible
only when DTLS is used with an non-null encryption method. When a only when DTLS is used with an non-null encryption method. When a
DTLS session uses a null encryption method due to misconfiguration or DTLS session uses a null encryption method due to misconfiguration or
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. DTLS over the RADIUS/DTLS port. Where deep packet inspection is
possible, there should be further restrictions to allow only RADIUS
packets inside of the DTLS session.
10.1. Legacy RADIUS Security 10.1. Legacy RADIUS Security
We reiterate here the poor security of the legacy RADIUS protocol. protocol. We suggest that RADIUS clients and servers implement
It is RECOMMENDED that all RADIUS clients and servers implement this either this specification, or [RFC6614]. New attacks on MD5 have
specification, or [RFC6614]. New attacks on MD5 have appeared over appeared over the past few years, and there is a distinct possibility
the past few years, and there is a distinct possibility that MD5 may that MD5 may be completely broken in the near future. Such a break
be completely broken in the near future. 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 35 skipping to change at page 20, line 45
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 identies 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.5 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.
Since the client-server relationship is static, the authentication Since the client-server relationship is static, the authentication
credentials for that relationship should also be statically credentials for that relationship should also be statically
configured. That is, a client connecting to a DTLS server SHOULD be configured. That is, a client connecting to a DTLS server SHOULD be
skipping to change at page 23, line 26 skipping to change at page 24, line 35
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.
[RFC4107]
Bellovin, S. and R. Housley, "Guidelines for Cryptographic Key
Management", BCP 107, RFC 4107, June 2005.
[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.
 End of changes. 14 change blocks. 
68 lines changed or deleted 117 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/