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

This html diff was produced by rfcdiff 1.38. The latest version is available from http://tools.ietf.org/tools/rfcdiff/