draft-ietf-radext-dtls-00.txt | draft-ietf-radext-dtls-01.txt | |||
---|---|---|---|---|
Network Working Group Alan DeKok | Network Working Group Alan DeKok | |||
INTERNET-DRAFT FreeRADIUS | INTERNET-DRAFT FreeRADIUS | |||
Category: Informational | Category: Informational | |||
<draft-ietf-radext-dtls-00.txt> | <draft-ietf-radext-dtls-01.txt> | |||
Expires: April 8, 2011 | Expires: April 12, 2011 | |||
8 October 2010 | 12 October 2010 | |||
DTLS as a Transport Layer for RADIUS | DTLS as a Transport Layer for RADIUS | |||
draft-ietf-radext-dtls-00 | draft-ietf-radext-dtls-01 | |||
Abstract | Abstract | |||
The RADIUS protocol [RFC2865] has limited support for authentication | The RADIUS protocol [RFC2865] has limited support for authentication | |||
and encryption of RADIUS packets. The protocol transports data "in | and encryption of RADIUS packets. The protocol transports data "in | |||
the clear", although some parts of the packets can have "hidden" | the clear", although some parts of the packets can have "hidden" | |||
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 1, line 46 | skipping to change at page 1, line 46 | |||
and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
The list of current Internet-Drafts can be accessed at | The list of current Internet-Drafts can be accessed at | |||
http://www.ietf.org/ietf/1id-abstracts.txt. | http://www.ietf.org/ietf/1id-abstracts.txt. | |||
The list of Internet-Draft Shadow Directories can be accessed at | The list of Internet-Draft Shadow Directories can be accessed at | |||
http://www.ietf.org/shadow.html. | http://www.ietf.org/shadow.html. | |||
This Internet-Draft will expire on April 8, 2011 | This Internet-Draft will expire on April 12, 2011 | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2010 IETF Trust and the persons identified as the | Copyright (c) 2010 IETF Trust and the persons identified as the | |||
document authors. All rights reserved. | document authors. All rights reserved. | |||
This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
Provisions Relating to IETF Documents | Provisions Relating to IETF Documents | |||
(http://trustee.ietf.org/license-info/) in effect on the date of | (http://trustee.ietf.org/license-info/) in effect on the date of | |||
publication of this document. Please review these documents | publication of this document. Please review these documents | |||
carefully, as they describe your rights and restrictions with respect | carefully, as they describe your rights and restrictions with respect | |||
skipping to change at page 3, line 26 | skipping to change at page 3, line 26 | |||
3.1. Protocol Disambiguation ............................. 9 | 3.1. Protocol Disambiguation ............................. 9 | |||
4. Connection Management .................................... 10 | 4. Connection Management .................................... 10 | |||
4.1. Server Connection Management ........................ 10 | 4.1. Server Connection Management ........................ 10 | |||
4.1.1. Table Management ............................... 10 | 4.1.1. Table Management ............................... 10 | |||
4.2. Client Connection Management ........................ 11 | 4.2. Client Connection Management ........................ 11 | |||
5. Processing Algorithm ..................................... 12 | 5. Processing Algorithm ..................................... 12 | |||
6. Diameter Considerations .................................. 14 | 6. Diameter Considerations .................................. 14 | |||
7. IANA Considerations ...................................... 14 | 7. IANA Considerations ...................................... 14 | |||
8. Security Considerations .................................. 14 | 8. Security Considerations .................................. 14 | |||
8.1. Legacy RADIUS Security .............................. 14 | 8.1. Legacy RADIUS Security .............................. 14 | |||
9. References ............................................... 15 | 8.2. Network Address Translation ......................... 15 | |||
9.1. Normative references ................................ 15 | 9. References ............................................... 16 | |||
9.2. Informative references .............................. 16 | 9.1. Normative references ................................ 16 | |||
9.2. Informative references .............................. 17 | ||||
1. Introduction | 1. Introduction | |||
The RADIUS protocol as described in [RFC2865], [RFC2866], and | The RADIUS protocol as described in [RFC2865], [RFC2866], and | |||
[RFC5176] has traditionally used methods based on MD5 [RFC1321] for | [RFC5176] has traditionally used methods based on MD5 [RFC1321] for | |||
per-packet authentication and integrity checks. However, the MD5 | per-packet authentication and integrity checks. However, the MD5 | |||
algorithm has known weaknesses such as [MD5Attack] and [MD5Break]. | algorithm has known weaknesses such as [MD5Attack] and [MD5Break]. | |||
As a result, previous specifications such as [RFC5176] have | As a result, previous specifications such as [RFC5176] have | |||
recommended using IPSec to secure RADIUS traffic. | recommended using IPSec to secure RADIUS traffic. | |||
skipping to change at page 15, line 45 | skipping to change at page 15, line 45 | |||
cryptographically secure pseudo-random number generator (CSPRNG). | cryptographically secure pseudo-random number generator (CSPRNG). | |||
For example, a reasonable key may be 32 characters of a SHA-256 hash | For example, a reasonable key may be 32 characters of a SHA-256 hash | |||
of at least 64 bytes of data taken from a CSPRNG. If this method | of at least 64 bytes of data taken from a CSPRNG. If this method | |||
seems too complicated, a certificate-based TLS method SHOULD be used | seems too complicated, a certificate-based TLS method SHOULD be used | |||
instead. | instead. | |||
The previous RADIUS practice of using shared secrets that are minor | The previous RADIUS practice of using shared secrets that are minor | |||
variations of words is NOT RECOMMENDED, as it would negate nearly all | variations of words is NOT RECOMMENDED, as it would negate nearly all | |||
of the security of DTLS. | of the security of DTLS. | |||
8.2. Network Address Translation | ||||
Network Address Translation (NAT) is fundamentally incompatible with | ||||
RADIUS. RADIUS uses the source IP address to determine the shared | ||||
secret for the client, and NAT hides many clients behind one source | ||||
IP address. | ||||
The migration flag described above in Section 3 is also tracked per | ||||
source IP address. Using a NAT in front of many RADIUS clients | ||||
negates the function of the flag, making it impossible to migrate | ||||
clients in a secure fashion. | ||||
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 | ||||
NAT. That is, a RADIUS server may receive a RADIUS/DTLS packet from | ||||
a client IP/port combination, followed by the reception of a | ||||
RADIUS/UDP packet from that same client IP/port combination. If this | ||||
capability were allowed, it would permit a downgrade attack to occur, | ||||
and would negate all of the security added by RADIUS/DTLS. | ||||
As a result, RADIUS clients SHOULD NOT be located behind a NAT | ||||
gateway. If clients are located behind a NAT gateway, then a secure | ||||
transport such as DTLS MUST be used. | ||||
9. References | 9. References | |||
9.1. Normative references | 9.1. Normative references | |||
[RFC2865] | [RFC2865] | |||
Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote | Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote | |||
Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. | Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. | |||
[RFC3539] | [RFC3539] | |||
Aboba, B. et al., "Authentication, Authorization and Accounting | Aboba, B. et al., "Authentication, Authorization and Accounting | |||
End of changes. 5 change blocks. | ||||
8 lines changed or deleted | 33 lines changed or added | |||
This html diff was produced by rfcdiff 1.40. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |