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/ |