--- 1/draft-ietf-radext-dtls-00.txt 2010-10-12 17:16:18.000000000 +0200 +++ 2/draft-ietf-radext-dtls-01.txt 2010-10-12 17:16:18.000000000 +0200 @@ -1,20 +1,20 @@ Network Working Group Alan DeKok INTERNET-DRAFT FreeRADIUS Category: Informational - -Expires: April 8, 2011 -8 October 2010 + +Expires: April 12, 2011 +12 October 2010 DTLS as a Transport Layer for RADIUS - draft-ietf-radext-dtls-00 + draft-ietf-radext-dtls-01 Abstract The RADIUS protocol [RFC2865] has limited support for authentication and encryption of RADIUS packets. The protocol transports data "in the clear", although some parts of the packets can have "hidden" content. Packets may be replayed verbatim by an attacker, and client-server authentication is based on fixed shared secrets. This document specifies how the Datagram Transport Layer Security (DTLS) protocol may be used as a fix for these problems. It also describes @@ -35,21 +35,21 @@ and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at 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 (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info/) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect @@ -72,23 +72,24 @@ 3.1. Protocol Disambiguation ............................. 9 4. Connection Management .................................... 10 4.1. Server Connection Management ........................ 10 4.1.1. Table Management ............................... 10 4.2. Client Connection Management ........................ 11 5. Processing Algorithm ..................................... 12 6. Diameter Considerations .................................. 14 7. IANA Considerations ...................................... 14 8. Security Considerations .................................. 14 8.1. Legacy RADIUS Security .............................. 14 -9. References ............................................... 15 - 9.1. Normative references ................................ 15 - 9.2. Informative references .............................. 16 + 8.2. Network Address Translation ......................... 15 +9. References ............................................... 16 + 9.1. Normative references ................................ 16 + 9.2. Informative references .............................. 17 1. Introduction The RADIUS protocol as described in [RFC2865], [RFC2866], and [RFC5176] has traditionally used methods based on MD5 [RFC1321] for per-packet authentication and integrity checks. However, the MD5 algorithm has known weaknesses such as [MD5Attack] and [MD5Break]. As a result, previous specifications such as [RFC5176] have recommended using IPSec to secure RADIUS traffic. @@ -614,20 +615,44 @@ cryptographically secure pseudo-random number generator (CSPRNG). 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 seems too complicated, a certificate-based TLS method SHOULD be used instead. The previous RADIUS practice of using shared secrets that are minor variations of words is NOT RECOMMENDED, as it would negate nearly all 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.1. Normative references [RFC2865] Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. [RFC3539] Aboba, B. et al., "Authentication, Authorization and Accounting