draft-ietf-radext-dtls-12.txt   draft-ietf-radext-dtls-13.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-12.txt> <draft-ietf-radext-dtls-13.txt>
Expires: November 8, 2014 Expires: January 4, 2015
8 May 2014 3 July 2014
DTLS as a Transport Layer for RADIUS DTLS as a Transport Layer for RADIUS
draft-ietf-radext-dtls-12 draft-ietf-radext-dtls-13
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 3, line 19 skipping to change at page 3, line 19
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 ......................... 7 2. Building on Existing Foundations ......................... 7
2.1. Changes to RADIUS ................................... 7 2.1. Changes to RADIUS ................................... 7
2.2. Similarities with RADIUS/TLS ........................ 8 2.2. Similarities with RADIUS/TLS ........................ 8
2.2.1. Changes from RADIUS/TLS to RADIUS/DTLS ......... 8 2.2.1. Changes from RADIUS/TLS to RADIUS/DTLS ......... 8
3. Interaction with RADIUS/UDP .............................. 9 3. Interaction with RADIUS/UDP .............................. 9
3.1. DTLS Port and Packet Types .......................... 10 3.1. DTLS Port and Packet Types .......................... 10
3.2. Server Behavior ..................................... 10 3.2. Server Behavior ..................................... 10
4. Client Behavior .......................................... 11 4. Client Behavior .......................................... 11
5. Session Management ....................................... 11 5. Session Management ....................................... 12
5.1. Server Session Management ........................... 12 5.1. Server Session Management ........................... 12
5.1.1. Session Opening and Closing .................... 12 5.1.1. Session Opening and Closing .................... 13
5.2. Client Session Management ........................... 14 5.2. Client Session Management ........................... 15
6. Implementation Guidelines ................................ 15 6. Implementation Guidelines ................................ 16
6.1. Client Implementations .............................. 16 6.1. Client Implementations .............................. 16
6.2. Server Implementations .............................. 17 6.2. Server Implementations .............................. 17
7. Diameter Considerations .................................. 17 7. Diameter Considerations .................................. 18
8. IANA Considerations ...................................... 17 8. IANA Considerations ...................................... 18
9. Implementation Status .................................... 18 9. Implementation Status .................................... 18
9.1. Radsecproxy ......................................... 18 9.1. Radsecproxy ......................................... 18
9.2. jradius ............................................. 18 9.2. jradius ............................................. 19
10. Security Considerations ................................. 19 10. Security Considerations ................................. 19
10.1. Crypto-Agility ..................................... 19 10.1. Crypto-Agility ..................................... 20
10.2. Legacy RADIUS Security ............................. 20 10.2. Legacy RADIUS Security ............................. 20
10.3. Resource Exhaustion ................................ 21 10.3. Resource Exhaustion ................................ 21
10.4. Client-Server Authentication with DTLS ............. 21 10.4. Client-Server Authentication with DTLS ............. 22
10.5. Network Address Translation ........................ 23 10.5. Network Address Translation ........................ 23
10.6. Wildcard Clients ................................... 23 10.6. Wildcard Clients ................................... 24
10.7. Session Closing .................................... 24 10.7. Session Closing .................................... 24
10.8. Client Subsystems .................................. 24 10.8. Client Subsystems .................................. 24
11. References .............................................. 25 11. References .............................................. 25
11.1. Normative references ............................... 25 11.1. Normative references ............................... 25
11.2. Informative references ............................. 26 11.2. Informative references ............................. 26
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
skipping to change at page 4, line 30 skipping to change at page 4, line 30
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 to add DTLS support, and make any necessary related
remain UDP based, without changing to a TCP architecture. changes to RADIUS. This allows implementations to remain UDP based,
without changing to a TCP architecture.
This specification does not, however, solve all of the problems This specification does not, however, solve all of the problems
associated with RADIUS/UDP. The DTLS protocol does not add reliable associated with RADIUS/UDP. The DTLS protocol does not add reliable
or in-order transport to RADIUS. DTLS also does not support or in-order transport to RADIUS. DTLS also does not support
fragmentation of application-layer messages, or of the DTLS messages fragmentation of application-layer messages, or of the DTLS messages
themselves. This specification therefore shares with traditional themselves. This specification therefore shares with traditional
RADIUS the issues of order, reliability, and fragmentation. These RADIUS the issues of order, reliability, and fragmentation. These
issues are dealt with in RADIUS/TCP [RFC6613] and RADIUS/TLS issues are dealt with in RADIUS/TCP [RFC6613] and RADIUS/TLS
[RFC6614]. [RFC6614].
skipping to change at page 5, line 46 skipping to change at page 5, line 47
UDP, does not have head-of-line blocking issues. UDP, does not have head-of-line blocking issues.
If this specification is indeed selected for advancement to Standards If this specification is indeed selected for advancement to Standards
Track, certificate verification options ([RFC6614] Section 2.3, point Track, certificate verification options ([RFC6614] Section 2.3, point
2) needs to be refined. 2) needs to be refined.
Another experimental characteristic of this specification is the Another experimental characteristic of this specification is the
question of key management between RADIUS/DTLS peers. RADIUS/UDP question of key management between RADIUS/DTLS peers. RADIUS/UDP
only allowed for manual key management, i.e., distribution of a only allowed for manual key management, i.e., distribution of a
shared secret between a client and a server. RADIUS/DTLS allows shared secret between a client and a server. RADIUS/DTLS allows
manual distribution of long-term proofs of peer identity as well (by manual distribution of long-term proofs of peer identity, by using
using TLS-PSK ciphersuites, or identifying clients by a certificate TLS-PSK ciphersuites. RADIUS/DTLS also allows the use of X.509
fingerprint), but as a new feature enables use of X.509 certificates certificates in a PKIX infrastructure. It remains to be seen if one
in a PKIX infrastructure. It remains to be seen if one of these of these methods will prevail or if both will find their place in
methods will prevail or if both will find their place in real-life real-life deployments. The authors can imagine pre-shared keys (PSK)
deployments. The authors can imagine pre-shared keys (PSK) to be to be popular in small-scale deployments (Small Office, Home Office
popular in small-scale deployments (Small Office, Home Office (SOHO) (SOHO) or isolated enterprise deployments) where scalability is not
or isolated enterprise deployments) where scalability is not an issue an issue and the deployment of a Certification Authority (CA) is
and the deployment of a Certification Authority (CA) is considered considered too much of a hassle; however, the authors can also
too much of a hassle; however, the authors can also imagine large imagine large roaming consortia to make use of PKIX. Readers of this
roaming consortia to make use of PKIX. Readers of this specification specification are encouraged to read the discussion of key management
are encouraged to read the discussion of key management issues within issues within [RFC6421] as well as [RFC4107].
[RFC6421] as well as [RFC4107].
It has yet to be decided whether this approach is to be chosen for 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 Standards Track. One key aspect to judge whether the approach is
usable on a large scale is by observing the uptake, usability, and usable on a large scale is by observing the uptake, usability, and
operational behavior of the protocol in large-scale, real-life operational behavior of the protocol in large-scale, real-life
deployments. 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
skipping to change at page 10, line 13 skipping to change at page 10, line 13
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
use of one port for multiple packet types. We recognize that use of one port for multiple packet types. We recognize that
implementations may allow the the use of RADIUS/DTLS over non- implementations may allow the use of RADIUS/DTLS over non-standard
standard ports. In that case, the references to UDP/2083 in this ports. In that case, the references to UDP/2083 in this document
document should be read as applying to any port used for transport of should be read as applying to any port used for transport of
RADIUS/DTLS traffic. RADIUS/DTLS traffic.
3.2. Server Behavior 3.2. Server Behavior
When a server receives packets on UDP/2083, all packets MUST be When a server receives packets on UDP/2083, all packets MUST be
treated as being DTLS. RADIUS/UDP packets MUST NOT be accepted on treated as being DTLS. RADIUS/UDP packets MUST NOT be accepted on
this port. this port.
Servers MUST NOT accept DTLS packets on the old RADIUS/UDP ports. Servers MUST NOT accept DTLS packets on the old RADIUS/UDP ports.
Early drafts of this specification permitted this behavior. It is Early drafts of this specification permitted this behavior. It is
forbidden here, as it depended on behavior in DTLS which may change forbidden here, as it depended on behavior in DTLS which may change
without notice. without notice.
Servers MUST authenticate clients. RADIUS is designed to be used by
mutually trusted systems. Allowing anonymous clients would ensure
privacy for RADIUS/DTLS traffic, but would negate all other security
aspects of the protocol.
As RADIUS has no provisions for capability signalling, there is no As RADIUS has no provisions for capability signalling, there is no
way for a RADIUS server to indicate to a client that it should way for a server to indicate to a client that it should transition to
transition to using DTLS. This action has to be taken by the using DTLS. This action has to be taken by the administrators of the
administrators of the two systems, using a method other than RADIUS. two systems, using a method other than RADIUS. This method will
This method will likely be out of band, or manual configuration. likely be out of band, or manual configuration.
Some servers maintain a list of allowed clients per destination port. Some servers maintain a list of allowed clients per destination port.
Others maintain a global list of clients, which are permitted to send Others maintain a global list of clients, which are permitted to send
packets to any port. Where a client can send packets to multiple packets to any port. Where a client can send packets to multiple
ports, the server MUST maintain a "DTLS Required" flag per client. ports, the server MUST maintain a "DTLS Required" flag per client.
This flag indicates whether or not the client is required to use This flag indicates whether or not the client is required to use
DTLS. When set, the flag indicates that the only traffic accepted DTLS. When set, the flag indicates that the only traffic accepted
from the client is over UDP/2083. When packets are received from a from the client is over UDP/2083. When packets are received from a
client on non-DTLS ports, for which DTLS is required, the server MUST client on non-DTLS ports, for which DTLS is required, the server MUST
silently discard these packets, as there is no RADIUS/UDP shared silently discard these packets, as there is no RADIUS/UDP shared
secret available. secret available.
This flag will often be set by an administrator. However, if a This flag will often be set by an administrator. However, if a
server receives DTLS traffic from a client, it SHOULD notify the server receives DTLS traffic from a client, it SHOULD notify the
administrator that DTLS is available for that client. It MAY mark administrator that DTLS is available for that client. It MAY mark
the client as "DTLS Required". the client as "DTLS Required".
It is RECOMMENDED that servers support the following perfect forward
secrecy (PFS) cipher suites:
o TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
o TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
Allowing RADIUS/UDP and RADIUS/DTLS from the same client exposes the Allowing RADIUS/UDP and RADIUS/DTLS from the same client exposes the
traffic to downbidding attacks, and is NOT RECOMMENDED. traffic to downbidding attacks, and is NOT RECOMMENDED.
4. Client Behavior 4. Client Behavior
When a client sends packets to the assigned RADIUS/DTLS port, all When a client sends packets to the assigned RADIUS/DTLS port, all
packets MUST be DTLS. RADIUS/UDP packets MUST NOT be sent to this packets MUST be DTLS. RADIUS/UDP packets MUST NOT be sent to this
port. port.
Clients MUST authenticate themselves to servers, via credentials
which are unique to each client.
It is RECOMMENDED that clients support the following PFS cipher
suites:
o TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
o TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
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. 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
skipping to change at page 16, line 14 skipping to change at page 16, line 34
Where a TLS pre-shared key (PSK) method is used, implementations MUST Where a TLS pre-shared key (PSK) method is used, implementations MUST
support keys of at least 16 octets in length. Implementations SHOULD support keys of at least 16 octets in length. Implementations SHOULD
support key lengths of 32 octets, and SHOULD allow for longer keys. support key lengths of 32 octets, and SHOULD allow for longer keys.
The key data MUST be capable of being any value (0 through 255, The key data MUST be capable of being any value (0 through 255,
inclusive). Implementations MUST NOT limit themselves to using inclusive). Implementations MUST NOT limit themselves to using
textual keys. It is RECOMMENDED that the administration interface textual keys. It is RECOMMENDED that the administration interface
allows for the keys to be entered as humanly readable strings in hex allows for the keys to be entered as humanly readable strings in hex
format. format.
When creating keys, it is RECOMMENDED that keys be derived from a When creating keys for use with PSK cipher suites, it is RECOMMENDED
cryptographically secure pseudo-random number generator (CSPRNG) that keys be derived from a cryptographically secure pseudo-random
instead of administrators inventing keys on their own. If managing number generator (CSPRNG) instead of administrators inventing keys on
keys is too complicated, a certificate-based TLS method SHOULD be their own. If managing keys is too complicated, a certificate-based
used instead. TLS method SHOULD be used 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 manage sessions, so that the client subsystem does not need to manage
multiple sessions on one socket. multiple sessions on one socket.
RADIUS/DTLS clients should use a single source (IP + port) when RADIUS/DTLS clients should use a single source (IP + port) when
sending packets to a particular RADIUS/DTLS server. Doing so sending packets to a particular RADIUS/DTLS server. Doing so
skipping to change at page 17, line 48 skipping to change at page 18, line 21
8. IANA Considerations 8. IANA Considerations
No new RADIUS attributes or packet codes are defined. IANA is No new RADIUS attributes or packet codes are defined. IANA is
requested to update the "Service Name and Transport Protocol Port requested to update the "Service Name and Transport Protocol Port
Number Registry". The entry corresponding to port service name Number Registry". The entry corresponding to port service name
"radsec", port number "2083", and transport protocol "UDP" should be "radsec", port number "2083", and transport protocol "UDP" should be
updated as follows: updated as follows:
o Assignee: change "Mike McCauley" to "IESG". o Assignee: change "Mike McCauley" to "IESG".
o Contact: change ""Mike McCauley" to "IETF Chair" o Contact: change "Mike McCauley" to "IETF Chair"
o Reference: Add this document as a reference o Reference: Add this document as a reference
o Assignment Notes: add the text "The UDP port 2083 was already o Assignment Notes: add the text "The UDP port 2083 was already
previously assigned by IANA for "RadSec", an early implementation previously assigned by IANA for "RadSec", an early implementation
of RADIUS/TLS, prior to issuance of this RFC." of RADIUS/TLS, prior to issuance of this RFC."
9. Implementation Status 9. Implementation Status
This section records the status of known implementations of This section records the status of known implementations of
RADIUS/DTLS at the time of posting of this Internet- Draft, and is RADIUS/DTLS at the time of posting of this Internet- Draft, and is
based on a proposal described in [RFC6982]. based on a proposal described in [RFC6982].
skipping to change at page 19, line 43 skipping to change at page 20, line 15
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. Where deep packet inspection is DTLS over the RADIUS/DTLS port.
possible, there should be further restrictions to allow only RADIUS
packets inside of the DTLS session.
10.1. Crypto-Agility 10.1. Crypto-Agility
Section 4.2 of [RFC6421] makes a number of recommendations about Section 4.2 of [RFC6421] makes a number of recommendations about
security properties of new RADIUS proposals. All of those security properties of new RADIUS proposals. All of those
recommendations are satisfied by using DTLS as the transport layer. recommendations are satisfied by using DTLS as the transport layer.
Section 4.3 of [RFC6421] makes a number of recommendations about Section 4.3 of [RFC6421] makes a number of recommendations about
backwards compatibility with RADIUS. Section 3, above, addresses backwards compatibility with RADIUS. Section 3, above, addresses
these concerns in detail. these concerns in detail.
skipping to change at page 22, line 35 skipping to change at page 23, line 6
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 must also be statically configured. credentials for that relationship must also be statically configured.
That is, a client connecting to a DTLS server SHOULD be pre- That is, a client connecting to a DTLS server SHOULD be pre-
configured with the servers credentials (e.g. PSK or certificate). configured with the servers credentials (e.g. PSK or certificate).
If the server fails to present the correct credentials, the DTLS If the server fails to present the correct credentials, the DTLS
session MUST be closed. Each server SHOULD be preconfigured with session MUST be closed. Each server SHOULD be preconfigured with
sufficient information to authenticate connecting clients. sufficient information to authenticate connecting clients.
The above requirements can be met by using a private Certificate The requirement for clients to be individually configured with a
unique certificate can be met by using a private Certificate
Authority (CA) for certificates used in RADIUS/DTLS environments. If Authority (CA) for certificates used in RADIUS/DTLS environments. If
a client were configured to use a public CA, then it could accept as a client were configured to use a public CA, then it could accept as
valid any server which has a certificate signed by that CA. While valid any server which has a certificate signed by that CA. While
the traffic would be secure from third-party observers, the server the traffic would be secure from third-party observers, the server
would, howrver, have unrestricted access to all of the RADIUS would, howrver, have unrestricted access to all of the RADIUS
traffic, including all user credentials and passwords. traffic, including all user credentials and passwords.
Therefore, clients SHOULD NOT be pre-configured with a list of known Therefore, clients SHOULD NOT be pre-configured with a list of known
public CAs by the vendor or manufacturer. Instead, the clients public CAs by the vendor or manufacturer. Instead, the clients
SHOULD start off with an empty CA list. The addition of a CA SHOULD SHOULD start off with an empty CA list. The addition of a CA SHOULD
skipping to change at page 23, line 21 skipping to change at page 23, line 41
on the client, and associated with that hostname. This requirement on the client, and associated with that hostname. This requirement
does suggest that in the absence of a specification for dynamic does suggest that in the absence of a specification for dynamic
discovery, clients SHOULD use only those servers which have been discovery, clients SHOULD use only those servers which have been
manually configured by an administrator. manually configured by an administrator.
10.5. Network Address Translation 10.5. Network Address Translation
Network Address Translation (NAT) is fundamentally incompatible with Network Address Translation (NAT) is fundamentally incompatible with
RADIUS/UDP. RADIUS/UDP uses the source IP address to determine the RADIUS/UDP. RADIUS/UDP uses the source IP address to determine the
shared secret for the client, and NAT hides many clients behind one shared secret for the client, and NAT hides many clients behind one
source IP address. source IP address. As a result, RADIUS/UDP clients can not be
located behind a NAT gateway.
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 one source 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 source IP/port combination. If this
behavior is allowed, then the client would have an inconsistent behavior is allowed, then the server would have an inconsistent view
security profile, allowing an attacker to choose the most insecure of the clients security profile, allowing an attacker to choose the
method. most insecure method.
As a result, RADIUS/UDP clients SHOULD NOT be located behind a NAT If more than one client is located behind a NAT gateway, then every
gateway. If clients are located behind a NAT gateway, then a secure client behind the NAT MUST use a secure transport such as TLS or
transport such as DTLS MUST be used. As discussed below, a method DTLS. As discussed below, a method for uniquely identifying each
for uniquely identifying each client MUST be used. client MUST be used.
10.6. Wildcard Clients 10.6. Wildcard Clients
Some RADIUS server implementations allow for "wildcard" clients. Some RADIUS server implementations allow for "wildcard" clients.
That is, clients with an IPv4 netmask of other than 32, or an IPv6 That is, clients with an IPv4 netmask of other than 32, or an IPv6
netmask of other than 128. That practice is not recommended for netmask of other than 128. That practice is not recommended for
RADIUS/UDP, as it means multiple clients use the same shared secret. RADIUS/UDP, as it means multiple clients will use the same shared
secret.
The use of RADIUS/DTLS can allow for the safe usage of wildcards. The use of RADIUS/DTLS can allow for the safe usage of wildcards.
When RADIUS/DTLS is used with wildcards, clients MUST be uniquely When RADIUS/DTLS is used with wildcards, clients MUST be uniquely
identified using TLS parameters, and any certificate or PSK used MUST identified using TLS parameters, and any certificate or PSK used MUST
be unique to each client. be unique to each client.
10.7. Session Closing 10.7. Session Closing
Section 5.1.1, above, requires that DTLS sessions be closed when the Section 5.1.1, above, requires that DTLS sessions be closed when the
transported RADIUS packets are malformed, or fail the authenticator transported RADIUS packets are malformed, or fail the authenticator
 End of changes. 25 change blocks. 
57 lines changed or deleted 79 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/