--- 1/draft-ietf-radext-tcp-transport-06.txt 2010-05-20 23:12:29.000000000 +0200 +++ 2/draft-ietf-radext-tcp-transport-07.txt 2010-05-20 23:12:29.000000000 +0200 @@ -1,20 +1,20 @@ Network Working Group A. DeKok INTERNET-DRAFT FreeRADIUS Category: Experimental - -Expires: November 27, 2010 -27 April 2010 + +Expires: November 20, 2010 +20 May 2010 RADIUS Over TCP - draft-ietf-radext-tcp-transport-06 + draft-ietf-radext-tcp-transport-07 Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. @@ -23,21 +23,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 November 27, 2010 + This Internet-Draft will expire on November 20, 2010 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 @@ -47,49 +47,49 @@ the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Abstract The Remote Authentication Dial In User Server (RADIUS) Protocol has traditionally used the User Datagram Protocol (UDP) as its underlying transport layer. This document defines RADIUS over the Transmission Control Protocol (TCP), in order to address handling issues related to RADIUS over Transport Layer Security [RTLS]. It is not intended - to define TCP as a transport protocol for RADIUS in the absence of - TLS. + to define TCP as a transport protocol for RADIUS in the absence of a + secure transport layer. Table of Contents 1. Introduction ............................................. 4 1.1. Applicability of Reliable Transport ................. 5 - 1.2. Terminology ......................................... 6 + 1.2. Terminology ......................................... 7 1.3. Requirements Language ............................... 7 2. Changes to RADIUS ........................................ 7 2.1. Packet Format ....................................... 7 2.2. Assigned Ports for RADIUS Over TCP .................. 8 - 2.3. Management Information Base (MIB) ................... 8 + 2.3. Management Information Base (MIB) ................... 9 2.4. Detecting Live Servers .............................. 9 - 2.5. Congestion Control Issues ........................... 9 + 2.5. Congestion Control Issues ........................... 10 2.6. TCP Specific Issues ................................. 10 2.6.1. Duplicates and Retransmissions ................. 11 2.6.2. Head of Line Blocking .......................... 12 2.6.3. Shared Secrets ................................. 12 2.6.4. Malformed Packets and Unknown Clients .......... 12 2.6.5. Limitations of the ID Field .................... 13 2.6.6. EAP Sessions ................................... 14 2.6.7. TCP Applications are not UDP Applications ...... 14 3. Diameter Considerations .................................. 15 4. IANA Considerations ...................................... 15 5. Security Considerations .................................. 15 6. References ............................................... 15 6.1. Normative References ................................ 15 - 6.2. Informative References .............................. 15 + 6.2. Informative References .............................. 16 1. Introduction The RADIUS Protocol has been defined in [RFC2865] as using the User Datagram Protocol (UDP) for the underlying transport layer. While there are a number of benefits to using UDP as outlined in [RFC2865] Section 2.4, there are also some limitations: * Unreliable transport. As a result, systems using RADIUS have to implement application-layer timers and re-transmissions, as @@ -103,57 +103,64 @@ poorly tested code path on network devices. Some devices appear to be incapable of transporting fragmented UDP packets, making it difficult to deploy RADIUS in a network where those devices are deployed. * Connectionless transport. Neither clients nor servers receive positive statements that a "connection" is down. This information has to be deduced instead from the absence of a reply to a request. + * Lack of congestion control. Clients can send arbitrary amounts + of traffic with little or no feedback. This lack of feedback can + result in congestive collapse of the network. + As RADIUS is widely deployed, and has been widely deployed for well over a decade, these issues have been minor in some use-cases, and problematic in others. For use-cases such as inter-server proxying, [RTLS] suggests an alternative transport and security model -- RADIUS over TLS. That document describes the transport implications of running RADIUS over TLS. + The choice of TCP as a transport protocol is largely driven by the + desire to improve the security of RADIUS by using RADIUS over TLS. + For practical reasons, the transport protocol (TCP) is defined + separately from the security mechanism (TLS). + Since "bare" TCP does not provide for confidentiality or enable negotiation of credible ciphersuites, its use is not appropriate for inter-server communications where strong security is required. As a - result the use of "bare" TCP transport (i.e., without additional - confidentiality and security) is NOT RECOMMENDED, as there has been - little or no operational experience with it. + result "bare" TCP transport MUST NOT be used without TLS, IPsec, or + other secure upper layer. "Bare" TCP transport MAY, however, be used when another method such as IPSec [RFC4301] is used to provide additional confidentiality and security. Should experience show that such deployments are useful, this specification could be moved to standards track. 1.1. Applicability of Reliable Transport The intent of this document is to address transport issues related to RADIUS over TLS [RTLS] in inter-server communications scenarios, such as inter-domain communication between proxies. These situations benefit from the confidentiality and ciphersuite negotiation that can be provided by TLS. Since TLS is already widely available within the operating systems used by proxies, implementation barriers are low. - In scenarios where RADIUS proxies exchange a large volume of packets - (10+ packets per second), it is likely that there will be sufficient - traffic to enable the congestion window to be widened beyond the - minimum value on a long-term basis, enabling ACK piggy-backing. - Through use of an application-layer watchdog as described in - [RFC3539], it is possible to address the objections to reliable - transport described in [RFC2865] Section 2.4 without substantial - watchdog traffic, since regular traffic is expected in both - directions. + In scenarios where RADIUS proxies exchange a large volume of packets, + it is likely that there will be sufficient traffic to enable the + congestion window to be widened beyond the minimum value on a long- + term basis, enabling ACK piggy-backing. Through use of an + application-layer watchdog as described in [RFC3539], it is possible + to address the objections to reliable transport described in + [RFC2865] Section 2.4 without substantial watchdog traffic, since + regular traffic is expected in both directions. In addition, use of RADIUS over TLS has been found to improve operational performance when used with multi-round trip authentication mechanisms such as RADIUS over EAP [RFC3579]. In such exchanges, it is typical for EAP fragmentation to increase the number of round-trips required. For example, where EAP-TLS authentication [RFC5216] is attempted and both the EAP peer and server utilize certificate chains of 8KB, as many as 15 round-trips can be required if RADIUS packets are restricted to the common Ethernet MTU (1500 octets) for EAP over LAN (EAPoL) use-cases. Fragmentation of RADIUS @@ -162,21 +169,22 @@ routers, firewalls and NATs. However, since RADIUS over UDP implementations typically do not support MTU discovery, fragmentation can occur even when the maximum RADIUS over UDP packet size is restricted to 1500 octets. These problems disappear if a 4096 application-layer payload can be used alongside RADIUS over TLS. Since most TCP implementations support MTU discovery, the TCP MSS is automatically adjusted to account for the MTU, and the larger congestion window supported by TCP may allow multiple TCP segments to be sent within a single - window. + window. Even those few TCP stacks which do not perform path MTU + discovery can already support arbitrary payloads. Where the MTU for EAP packets is large, RADIUS/EAP traffic required for an EAP-TLS authentication with 8KB certificate chains may be reduced to 7 round-trips or less, resulting in substantially reduced authentication times. In addition, experience indicates that EAP sessions transported over RTLS are less likely to abort unsuccessfully. Historically, RADIUS over UDP implementations have exhibited poor retransmission behavior. Some implementations retransmit packets, others do not, and others @@ -450,41 +459,40 @@ supposed to be sent by the proxy back over that connection to the client. Since the client connection is closed, those responses from the home server to the proxy server SHOULD be silently discarded by the proxy. Despite the above discussion, RADIUS servers SHOULD still perform duplicate detection on received packets, as described in [RFC5080] Section 2.2.2. This detection can prevent duplicate processing of packets from non-conformant clients. - As noted previously, RADIUS packets SHOULD NOT be re-transmitted to - the same destination IP and numerical port, but over a different - transport layer. There is no guarantee in RADIUS that the two ports - are in any way related. This requirement does not, however, forbid - the practice of putting multiple servers into a fail-over or load- - balancing pool. In that situation, RADIUS request MAY be - retransmitted to another server that known to be part of the same - pool. + RADIUS packets SHOULD NOT be re-transmitted to the same destination + IP and numerical port, but over a different transport protocol. + There is no guarantee in RADIUS that the two ports are in any way + related. This requirement does not, however, forbid the practice of + putting multiple servers into a fail-over or load-balancing pool. In + that situation, RADIUS request MAY be retransmitted to another server + that known to be part of the same pool. 2.6.2. Head of Line Blocking When using UDP as a transport for RADIUS, there is no ordering of packets. If a packet sent by a client is lost, that loss has no effect on subsequent packets sent by that client. - Unlike UDP, TLS is subject to issues related to Head of Line (HoL) - blocking. This occurs when when a TLS segment is lost and a - subsequent TLS segment arrives out of order. While the RADIUS server - can process RADIUS packets out of order, the semantics of TLS makes + Unlike UDP, TCP is subject to issues related to Head of Line (HoL) + blocking. This occurs when when a TCP segment is lost and a + subsequent TCP segment arrives out of order. While the RADIUS server + can process RADIUS packets out of order, the semantics of TCP makes this impossible. This limitation can lower the maximum packet - processing rate of RADIUS over TLS. + processing rate of RADIUS over TCP. 2.6.3. Shared Secrets The use of TLS transport does not change the calculation of security- related fields (such as the Response-Authenticator) in RADIUS [RFC2865] or RADIUS Dynamic Authorization [RFC5176]. Calculation of attributes such as User-Password [RFC2865] or Message-Authenticator [RFC3579] also does not change. Clients and servers MUST be able to store and manage shared secrets @@ -623,37 +630,51 @@ As the RADIUS packet format, signing, and client verification are unchanged from prior specifications, all of the security issues outlined in previous specifications for RADIUS over UDP are also applicable here. As noted above, clients and servers SHOULD support configurable connection limits. Allowing an unlimited number of connections may result in resource exhaustion. + Implementors should consult [RTLS] for issues related the security of + RADIUS over TLS, and [RFC5246] for issues related to the security of + the TLS protocol. + + Since "bare" TCP does not provide for confidentiality or enable + negotiation of credible ciphersuites, its use is not appropriate for + inter-server communications where strong security is required. As a + result "bare" TCP transport MUST NOT be used without TLS, IPsec, or + other secure upper layer. + There are no (at this time) other known security issues for RADIUS over TCP transport. 6. References 6.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [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 (AAA) Transport Profile", RFC 3539, June 2003. +[RTLS] Winter, S. et. al., "TLS encryption for RADIUS over TCP + (RadSec)", draft-ietf-radext-radsec-06.txt, March 2010 (work + in progress). + 6.2. Informative References [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial In User Service) Support For Extensible Authentication Protocol (EAP)", RFC 3579, September 2003. [RFC4301] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 4301, December, 2005. @@ -680,28 +701,26 @@ User Service (RADIUS) Implementation Issues and Suggested Fixes", RFC 5080, December 2007. [RFC5176] Chiba, M. et al., "Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS)", RFC 5176, January 2008. [RFC5216] Simon, D., etc al., "The EAP-TLS Authentication Protocol", RFC 5216, March 2008. +[RFC5246] Dierks, T., Rescorla, E., "The Transport Layer Security (TLS) + Protocol Version 1.2", RFC 5246, August 2008. + [STATUS] DeKok, A., "Use of Status-Server Packets in the Remote Authentication Dial In User Service (RADIUS) Protocol", draft- - ietf-radext-status-server-07.txt, April 2010 (work in - progress). - -[RTLS] Winter, S. et. al., "TLS encryption for RADIUS over TCP - (RadSec)", draft-ietf-radext-radsec-06.txt, March 2010 (work - in progress). + ietf-radext-status-server-08.txt, May 2010 (work in progress). Acknowledgments None at this time. Authors' Addresses Alan DeKok The FreeRADIUS Server Project http://freeradius.org/