draft-ietf-radext-dtls-03.txt   draft-ietf-radext-dtls-04.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-03.txt> <draft-ietf-radext-dtls-04.txt>
Expires: July 28, 2013 Expires: October 2, 2013
28 January 2013 2 April 2013
DTLS as a Transport Layer for RADIUS DTLS as a Transport Layer for RADIUS
draft-ietf-radext-dtls-03 draft-ietf-radext-dtls-04
Abstract Abstract
The RADIUS protocol [RFC2865] has limited support for authentication The RADIUS protocol [RFC2865] has limited support for authentication
and encryption of RADIUS packets. The protocol transports data "in and encryption of RADIUS packets. The protocol transports data "in
the clear", although some parts of the packets can have "obfuscated" the clear", although some parts of the packets can have "obfuscated"
content. Packets may be replayed verbatim by an attacker, and content. Packets may be replayed verbatim by an attacker, and
client-server authentication is based on fixed shared secrets. This client-server authentication is based on fixed shared secrets. This
document specifies how the Datagram Transport Layer Security (DTLS) document specifies how the Datagram Transport Layer Security (DTLS)
protocol may be used as a fix for these problems. It also describes protocol may be used as a fix for these problems. It also describes
skipping to change at page 3, line 19 skipping to change at page 3, line 19
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. Similarities with RADIUS/TLS ........................ 7 2.2. Similarities with RADIUS/TLS ........................ 7
2.2.1. Changes from RADIUS/TLS to RADIUS/DTLS ......... 7 2.2.1. Changes from RADIUS/TLS to RADIUS/DTLS ......... 7
2.2.2. Reinforcement of RADIUS/TLS .................... 8 2.2.2. Reinforcement of RADIUS/TLS .................... 8
3. Transition Path .......................................... 8 3. Transition Path .......................................... 8
3.1. Server Transition to DTLS ........................... 8 3.1. Server Transition to DTLS ........................... 8
4. Client Transition ........................................ 9 4. Client Transition ........................................ 9
5. Connection Management .................................... 10 5. Connection Management .................................... 10
5.1. Server Connection Management ........................ 10 5.1. Server Connection Management ........................ 11
5.1.1. Session Management ............................. 11 5.1.1. Session Management ............................. 11
5.1.2. Protocol Disambiguation ........................ 12 5.1.2. Protocol Disambiguation ........................ 13
5.1.3. Processing Algorithm ........................... 13 5.1.3. Processing Algorithm ........................... 14
5.2. Client Connection Management ........................ 15 5.2. Client Connection Management ........................ 15
6. Implementation Guidelines ................................ 16 6. Implementation Guidelines ................................ 16
6.1. Client Implementations .............................. 16 6.1. Client Implementations .............................. 17
6.2. Server Implementations .............................. 17 6.2. Server Implementations .............................. 17
7. Implementation Experience ................................ 17 7. Implementation Experience ................................ 18
8. Diameter Considerations .................................. 17 8. Diameter Considerations .................................. 18
9. IANA Considerations ...................................... 18 9. IANA Considerations ...................................... 18
10. Security Considerations ................................. 18 10. Security Considerations ................................. 18
10.1. Legacy RADIUS Security ............................. 18 10.1. Legacy RADIUS Security ............................. 19
10.2. Resource Exhaustion ................................ 19 10.2. Resource Exhaustion ................................ 20
10.3. Network Address Translation ........................ 19 10.3. Network Address Translation ........................ 20
10.4. Wildcard Clients ................................... 20 10.4. Wildcard Clients ................................... 21
10.5. Session Closing .................................... 20 10.5. Session Closing .................................... 21
10.6. Clients Subsystems ................................. 21 10.6. Clients Subsystems ................................. 22
11. References .............................................. 21 11. References .............................................. 22
11.1. Normative references ............................... 21 11.1. Normative references ............................... 22
11.2. Informative references ............................. 22 11.2. Informative references ............................. 23
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 6, line 43 skipping to change at page 6, line 43
In short, the application creates a RADIUS packet via the usual In short, the application creates a RADIUS packet via the usual
methods, and then instead of sending it over a UDP socket, sends the methods, and then instead of sending it over a UDP socket, sends the
packet to a DTLS layer for encapsulation. DTLS then acts as a packet to a DTLS layer for encapsulation. DTLS then acts as a
transport layer for RADIUS, hence the names "RADIUS/UDP" and transport layer for RADIUS, hence the names "RADIUS/UDP" and
"RADIUS/DTLS". "RADIUS/DTLS".
The requirement that RADIUS remain largely unchanged ensures the The requirement that RADIUS remain largely unchanged ensures the
simplest possible implementation and widest interoperability of this simplest possible implementation and widest interoperability of this
specification. specification.
We note that the DTLS encapsulation of RADIUS means that the minimum We note that the DTLS encapsulation of RADIUS means that RADIUS
and maximum UDP packet sizes increase by the DTLS overhead. packets have an additional overhead due to DTLS. Implementations
Implementations should be aware of this, and take it into account MUST support DTLS packets totalling 4096 octets in length, with a
when allocating buffers to read and write RADIUS/DTLS packets. corrsponding decrease in the maximum size of the encapsulated
packets. Implementations SHOULD support encapsulated RADIUS packets
of 4096 in length, with a corresponding increase in the maximum size
of the encapsulated DTLS packets.
The only changes made from RADIUS/UDP to RADIUS/DTLS are the The only changes made from RADIUS/UDP to RADIUS/DTLS are the
following two items: following two items:
(1) The Length checks defined in [RFC2865] Section 3 MUST use the (1) The Length checks defined in [RFC2865] Section 3 MUST use the
length of the decrypted DTLS data instead of the UDP packet length of the decrypted DTLS data instead of the UDP packet
length. length.
(2) The shared secret secret used to compute the MD5 integrity (2) The shared secret secret used to compute the MD5 integrity
checks and the attribute encryption MUST be "radius/dtls". checks and the attribute encryption MUST be "radius/dtls".
skipping to change at page 9, line 17 skipping to change at page 9, line 19
RADIUS/DTLS. The interpretation of this flag is as follows. If the RADIUS/DTLS. The interpretation of this flag is as follows. 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. If the flag is from that client MUST be processed as RADIUS/DTLS. If the flag is
"false", then the client supports RADIUS/UDP, but may still support "false", then the client supports RADIUS/UDP, but may still support
RADIUS/DTLS. Packets from the client need to be examined to see if RADIUS/DTLS. Packets from the client need to be examined to see if
they are RADIUS/UDP or RADIUS/DTLS. they are RADIUS/UDP or RADIUS/DTLS.
The "DTLS Required" flag MUST be exposed to administrators of the The "DTLS Required" flag MUST be exposed to administrators of the
server. As clients are upgraded, administrators can then manually server. As clients are upgraded, administrators can then manually
mark them as using RADIUS/DTLS. The default value for the flag mark them as using RADIUS/DTLS. The default value for the flag
SHOULD be "false". SHOULD be "false". DTLS configuration parameters (e.g. certificates,
pre-shared keys, etc.) SHOULD be exposed to the administrator, even
if the "DTLS Required" flag is set to "false". Adding these
parameters means that the client may use DTLS, though it is not
required.
It is RECOMMENDED that the default value for the "DTLS Required" flag It is RECOMMENDED that the default value for the "DTLS Required" flag
be set to "true" when this specification has acheived wide-spread be set to "true" when this specification has acheived wide-spread
adoption. adoption.
Once a RADIUS/DTLS server has established a DTLS session with a Once a RADIUS/DTLS server has established a DTLS session with a
client that previously had the flag set to "false", the server MUST client that previously had the flag set to "false", the server MUST
set the "DTLS Required" flag to "true". This change requires all set the "DTLS Required" flag to "true". This change requires all
subsequent traffic from that client to use DTLS, and prevents subsequent traffic from that client to use DTLS, and prevents
bidding-down attacks. The server SHOULD also notify the bidding-down attacks. The server SHOULD also notify the
skipping to change at page 10, line 4 skipping to change at page 10, line 11
each server that indicates if that server requires it to use each server that indicates if that server requires it to use
RADIUS/DTLS. The interpretation of this flag is as follows. If the RADIUS/DTLS. The interpretation of this flag is as follows. If the
flag is "true" then the server supports RADIUS/DTLS, and all packets flag is "true" then the server supports RADIUS/DTLS, and all packets
sent to that server MUST be RADIUS/DTLS. If the flag is "false", sent to that server MUST be RADIUS/DTLS. If the flag is "false",
then the server supports RADIUS/UDP, but may still support then the server supports RADIUS/UDP, but may still support
RADIUS/DTLS. Packets sent to that server MUST be RADIUS/UDP. RADIUS/DTLS. Packets sent to that server MUST be RADIUS/UDP.
The "DTLS Required" flag MUST be exposed to administrators of the The "DTLS Required" flag MUST be exposed to administrators of the
client. As servers are upgraded, administrators can then manually client. As servers are upgraded, administrators can then manually
mark them as using RADIUS/DTLS. The default value for the flag mark them as using RADIUS/DTLS. The default value for the flag
SHOULD be "false". SHOULD be "false". DTLS configuration parameters (e.g. certificates,
pre-shared keys, etc.) SHOULD be exposed to the administrator, even
if the "DTLS Required" flag is set to "false". Adding these
parameters means that the client MUST start using DTLS to the server
for all new requests. The client MUST, however, accept RADIUS/UDP
responses to any outstanding requests.
It is RECOMMENDED that the default value for the "DTLS Required" flag It is RECOMMENDED that the default value for the "DTLS Required" flag
be set to "true" when this specification has acheived wide-spread be set to "true" when this specification has acheived wide-spread
adoption. adoption.
RADIUS/DTLS clients SHOULD NOT probe servers to see if they support RADIUS/DTLS clients SHOULD NOT probe servers to see if they support
DTLS transport. Doing so would cause servers to immediately require DTLS transport. Doing so would cause servers to immediately require
that all new packets from the client use DTLS. This requirement may that all new packets from the client use DTLS. This requirement may
be difficult for a client to satisfy. Instead, clients SHOULD use be difficult for a client to satisfy. Instead, clients SHOULD use
DTLS as a transport layer only when administratively configured. DTLS as a transport layer only when administratively configured.
The requirements of this specification mean that RADIUS/DTLS clients The requirements of this specification mean that RADIUS/DTLS clients
can no longer have multiple independent RADIUS implementations, or can no longer have multiple independent RADIUS implementations, or
processes that originate RADIUS/UDP and RADIUS/DTLS packets. processes that originate RADIUS/UDP and RADIUS/DTLS packets.
Instead, clients MUST use only one transport layer to communicate Instead, clients MUST use only one transport layer to communicate
with a specific server. It is RECOMMENDED that clients use a local with a specific server. It is RECOMMENDED that clients use a local
proxy as described in Section 6.1, above. proxy as described in Section 6.1, below.
5. Connection Management 5. Connection Management
Where [RFC6614] 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 may need to perform connection implementations of this specification may need to perform connection
management of the DTLS session in the application layer. This management of the DTLS session in the application layer. This
section describes logically how this tracking is done. section describes logically how this tracking is done.
Implementations may choose to use the method described here, or Implementations may choose to use the method described here, or
another, equivalent method. another, equivalent method.
We note that [RFC5080] Section 2.2.2 already mandates a duplicate
detection cache. The connection tracking described below can be seen
as an extension of that cache, where entries contain DTLS sessions
instead of RADIUS/UDP packets.
5.1. Server Connection Management 5.1. Server Connection Management
A RADIUS/DTLS server MUST track ongoing client connections based on a A RADIUS/DTLS server MUST track ongoing client connections based on a
key composed of the following 4-tuple: 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
skipping to change at page 11, line 47 skipping to change at page 12, line 17
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
MUST be deleted when non-RADIUS traffic is received over it. This
specification is for RADIUS, and there is no reason to allow non-
RADIUS traffic over a RADIUS/DTLS connection. A session MUST be
deleted when RADIUS traffic fails to pass security checks. There is
no reason to permit insecure networks. A session SHOULD NOT be
deleted when a well-formed, but "unexpected" RADIUS packet is
received over it. Future specifications may extend RADIUS/DTLS, and
we do not want to forbid those specifications.
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 may also use watchdog packets from the client to servers. A server may also use watchdog packets from the client to
determine that the connection is still active. determine that the connection 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
MUST also maintain a "Last Packet" 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 RADIUS/DTLS timestamp SHOULD be updated on reception of a valid RADIUS/DTLS
packet. The timestamp MUST NOT be updated in other situations. When packet. The timestamp MUST NOT be updated in other situations. When
a session has not received a packet for a period of time, it is a session has not received a packet for a period of time, it is
skipping to change at page 14, line 47 skipping to change at page 15, line 28
must keep the old session active until it has received secure must keep the old session active until it has received secure
notification from the client that the session is closed. Or, when notification from the client that the session is closed. Or, when
the server has decided for itself that the session is closed. Taking the server has decided for itself that the session is closed. Taking
any other action would permit unauthenticated clients to perform a any other action would permit unauthenticated clients to perform a
DoS attack, by closing active DTLS session. DoS attack, by closing active DTLS session.
As a result, servers MUST ignore any attempts to re-use an existing As a result, servers MUST ignore any attempts to re-use an existing
4-tuple from an active session. This requirement can likely be 4-tuple from an active session. This requirement can likely be
reached by simply processing the packet through the existing session, reached by simply processing the packet through the existing session,
as with any other packet received via that 4-tuple. Non-compliant, as with any other packet received via that 4-tuple. Non-compliant,
or unexpected packets will be ignored by the SSL layer. or unexpected packets will be ignored by the DTLS layer.
The above requirement is mitigated by the suggestion in Section 6.1, The above requirement is mitigated by the suggestion in Section 6.1,
below, that the client use a local proxy for all RADIUS traffic. below, that the client use a local proxy for all RADIUS traffic.
That proxy can then track the ports which it uses, and ensure that That proxy can then track the ports which it uses, and ensure that
re-use of 4-tuples is avoided. The exact process by which this re-use of 4-tuples is avoided. The exact process by which this
tracking is done is outside of the scope of this document. tracking is done is outside of the scope of this document.
5.2. Client Connection Management 5.2. Client Connection Management
Clients SHOULD use Path MTU (PMTU) discovery [RFC6520] to determine Clients SHOULD use Path MTU (PMTU) discovery [RFC6520] to determine
skipping to change at page 16, line 18 skipping to change at page 16, line 44
additional implementation guidelines. These guidelines are not part additional implementation guidelines. These guidelines are not part
of the protocol, but may help implementors create simple, secure, and of the protocol, but may help implementors create simple, secure, and
inter-operable implementations. inter-operable implementations.
Where a TLS pre-shared key (PSK) method is used, implementations MUST Where a TLS pre-shared key (PSK) method is used, implementations MUST
support keys of at least 16 octets in length. Implementations SHOULD support keys of at least 16 octets in length. Implementations SHOULD
support key lengths of 32 octets, and SHOULD allow for longer keys. support key lengths of 32 octets, and SHOULD allow for longer keys.
The key data MUST be capable of being any value (0 through 255, The key data MUST be capable of being any value (0 through 255,
inclusive). Implementations MUST NOT limit themselves to using inclusive). Implementations MUST NOT limit themselves to using
textual keys. It is RECOMMENDED that the administration interface textual keys. It is RECOMMENDED that the administration interface
allos for the keys to be entered as hex strings. allows for the keys to be entered as hex strings.
It is RECOMMENDED that keys be derived from a cryptographically It is RECOMMENDED that keys be derived from a cryptographically
secure pseudo-random number generator (CSPRNG). If managing keys is secure pseudo-random number generator (CSPRNG). If managing keys is
too complicated, a certificate-based TLS method SHOULD be used too complicated, a certificate-based TLS method SHOULD be used
instead. instead.
6.1. Client Implementations 6.1. Client Implementations
RADIUS/DTLS clients SHOULD use connected sockets where possible. Use RADIUS/DTLS clients SHOULD use connected sockets where possible. Use
of connected sockets means that the underlying kernel tracks the of connected sockets means that the underlying kernel tracks the
sessions, so that the client subsystem does not need to. It is a sessions, so that the client subsystem does not need to. It is a
good idea to leverage existing functionality. good idea to leverage existing functionality.
RADIUS/DTLS clients SHOULD use a local proxy which arbitrates all RADIUS/DTLS clients SHOULD use one source when sending packets to a
RADIUS traffic between the client and all servers. The proxy SHOULD particular RADIUS/DTLS server. Doing so minimizes the number of DTLS
accept traffic only from the authorized subsystems on the client session setups. It also ensures that information about the home
machine, and SHOULD proxy that traffic to known servers. Each server state is discovered only once.
authorized subsystem SHOULD include an attribute which uniquely
identifies that subsystem to the proxy, so that the proxy can apply In practive, this means that RADIUS/DTLS clients SHOULD use a local
origin-specific proxy rules and security policies. We suggest using proxy which arbitrates all RADIUS traffic between the client and all
NAS-Identifier for this purpose. servers. The proxy SHOULD accept traffic only from the authorized
subsystems on the client machine, and SHOULD proxy that traffic to
known servers. Each authorized subsystem SHOULD include an attribute
which uniquely identifies that subsystem to the proxy, so that the
proxy can apply origin-specific proxy rules and security policies.
We suggest using NAS-Identifier for this purpose.
The local proxy SHOULD be able to interact with multiple servers at
the same time. There is no requirement that each server have its own
unique proxy on the client, as that would be inefficient.
Each client subsystem can include a subsystem-specific NAS-Identifier Each client subsystem can include a subsystem-specific NAS-Identifier
in each request. The format of this attribute is implementation- in each request. The format of this attribute is implementation-
specific. The proxy SHOULD verify that the request originated from specific. The proxy SHOULD verify that the request originated from
the local system, ideally via a loopback address. The proxy MUST the local system, ideally via a loopback address. The proxy MUST
then re-write any subsystem-specific NAS-Identifier to a NAS- then re-write any subsystem-specific NAS-Identifier to a NAS-
Identifier which identifies the client as a whole. Or, remove NAS- Identifier which identifies the client as a whole. Or, remove NAS-
Identifier entirely and replace it with NAS-IP-Address or NAS- Identifier entirely and replace it with NAS-IP-Address or NAS-
IPv6-Address. IPv6-Address.
skipping to change at page 18, line 30 skipping to change at page 19, line 19
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 main 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 octet. 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. These packets will be silently discarded, not support the protocol. These packets will be silently discarded,
and will not change the security profile of the server. and will not change the security profile of the server.
This specification also suggests that implementations use a
connection tracking table. This table is an extension of the
duplicate detection cache mandated in [RFC5080] Section 2.2.2. The
changes given here are that DTLS-specific information is tracked for
each table entry. Section 5.1.1, above, describes steps to mitigate
any DoS issues which result from tracking additional information.
10.1. Legacy RADIUS Security 10.1. Legacy RADIUS Security
We reiterate here the poor security of the legacy RADIUS protocol. We reiterate here the poor security of the legacy RADIUS protocol.
It is RECOMMENDED that all RADIUS clients and servers implement this It is RECOMMENDED that all RADIUS clients and servers implement this
specification. New attacks on MD5 have appeared over the past few specification. New attacks on MD5 have appeared over the past few
years, and there is a distinct possibility that MD5 may be completely years, and there is a distinct possibility that MD5 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 which depends on RADIUS. Attackers could of all network security which depends on RADIUS. Attackers could
skipping to change at page 21, line 50 skipping to change at page 22, line 50
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.
[RFC5077] [RFC5077]
Salowey, J, et al., "Transport Layer Security (TLS) Session Salowey, J, et al., "Transport Layer Security (TLS) Session
Resumption without Server-Side State", RFC 5077, January 2008 Resumption without Server-Side State", RFC 5077, January 2008
[RFC5080]
Nelson, D. and DeKok, A, "Common Remote Authentication Dial In User
Service (RADIUS) Implementation Issues and Suggested Fixes", RFC
5080, December 2007.
[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.
[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.
[RFC6347] [RFC6347]
 End of changes. 19 change blocks. 
37 lines changed or deleted 85 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/