draft-ietf-radext-tcp-transport-08.txt   draft-ietf-radext-tcp-transport-09.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-08.txt> <draft-ietf-radext-tcp-transport-09.txt>
Expires: February 20, 2011 Expires: April 12, 2011
1 July 2010 12 October 2010
RADIUS Over TCP RADIUS Over TCP
draft-ietf-radext-tcp-transport-08 draft-ietf-radext-tcp-transport-09
Abstract Abstract
The Remote Authentication Dial In User Server (RADIUS) Protocol has The Remote Authentication Dial In User Server (RADIUS) Protocol has
until now required the User Datagram Protocol (UDP) as the underlying until now required the User Datagram Protocol (UDP) as the underlying
transport layer. This document defines RADIUS over the Transmission transport layer. This document defines RADIUS over the Transmission
Control Protocol (RADIUS/TCP), in order to address handling issues Control Protocol (RADIUS/TCP), in order to address handling issues
related to RADIUS over Transport Layer Security (RADIUS/TLS). It related to RADIUS over Transport Layer Security (RADIUS/TLS). It
permits TCP to be used as a transport protocol for RADIUS only when a permits TCP to be used as a transport protocol for RADIUS only when a
transport layer such as TLS or IPsec provides confidentialy and transport layer such as TLS or IPsec provides confidentialy and
skipping to change at page 1, line 46 skipping to change at page 1, line 46
documents at any time. It is inappropriate to use Internet-Drafts documents at any time. It is inappropriate to use Internet-Drafts
as reference material or to cite them other than as "work in as reference material or to cite them other than as "work in
progress." 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 February 1, 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 carefully, as they describe your rights and restrictions with
skipping to change at page 4, line 39 skipping to change at page 4, line 39
request. request.
* Lack of congestion control. Clients can send arbitrary amounts * Lack of congestion control. Clients can send arbitrary amounts
of traffic with little or no feedback. This lack of feedback can of traffic with little or no feedback. This lack of feedback can
result in congestive collapse of the network. result in congestive collapse of the network.
RADIUS has been widely deployed for well over a decade, and continues RADIUS has been widely deployed for well over a decade, and continues
to be widely deployed. Experience shows that these issues have been to be widely deployed. Experience shows that these issues have been
minor in some use-cases, and problematic in others. For use-cases minor in some use-cases, and problematic in others. For use-cases
such as inter-server proxying, an alternative transport and security such as inter-server proxying, an alternative transport and security
model -- RADIUS/TLS or RADIUS/TLS, as defined in [RADIUS/TLS]. That model -- RADIUS/TLS, as defined in [RADIUS/TLS]. That document
document describes the transport implications of running RADIUS/TLS. describes the transport implications of running RADIUS/TLS.
The choice of TCP as a transport protocol is largely driven by the The choice of TCP as a transport protocol is largely driven by the
desire to improve the security of RADIUS by using RADIUS/TLS. For desire to improve the security of RADIUS by using RADIUS/TLS. For
practical reasons, the transport protocol (TCP) is defined separately practical reasons, the transport protocol (TCP) is defined separately
from the security mechanism (TLS). 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 "bare" TCP transport MUST NOT be used without TLS, IPsec, or result "bare" TCP transport MUST NOT be used without TLS, IPsec, or
skipping to change at page 7, line 33 skipping to change at page 7, line 33
A packet sent by a RADIUS server to a RADIUS client, in response to A packet sent by a RADIUS server to a RADIUS client, in response to
a RADIUS request packet. e.g. Access-Accept, Access-Reject, a RADIUS request packet. e.g. Access-Accept, Access-Reject,
Access-Challenge, Accounting-Response, CoA-ACK, etc. Access-Challenge, Accounting-Response, CoA-ACK, etc.
RADIUS/UDP RADIUS/UDP
RADIUS over UDP, as defined in [RFC2865]. RADIUS over UDP, as defined in [RFC2865].
RADIUS/TCP RADIUS/TCP
RADIUS over TCP, as defined in this document. RADIUS over TCP, as defined in this document.
RADIUS/UDP RADIUS/TLS
RADIUS over TLS,, as defined in [RADIUS/TLS]. RADIUS over TLS, as defined in [RADIUS/TLS].
1.3. Requirements Language 1.3. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
2. Changes to RADIUS 2. Changes to RADIUS
RADIUS/TCP involves sending RADIUS application messages over a TCP RADIUS/TCP involves sending RADIUS application messages over a TCP
skipping to change at page 8, line 40 skipping to change at page 8, line 40
Clients and servers MUST be able to store and manage shared secrets Clients and servers MUST be able to store and manage shared secrets
based on the key described above, of (IP address, port, transport based on the key described above, of (IP address, port, transport
protocol). protocol).
The changes to RADIUS implementations required to implement this The changes to RADIUS implementations required to implement this
specification are largely limited to the portions that send and specification are largely limited to the portions that send and
receive packets on the network. receive packets on the network.
2.2. Assigned Ports for RADIUS/TCP 2.2. Assigned Ports for RADIUS/TCP
IANA has already assigned TCP ports for RADIUS and RADIUS/TLS IANA has already assigned TCP ports for RADIUS transport, as outlined
transport, as outlined below: below:
* radius 1812/tcp * radius 1812/tcp
* radius-acct 1813/tcp * radius-acct 1813/tcp
* radius-dynauth 3799/tcp * radius-dynauth 3799/tcp
* radsec 2083/tcp
Since these ports are unused by existing RADIUS implementations, the Since these ports are unused by existing RADIUS implementations, the
assigned values MUST be used as the default ports for RADIUS over assigned values MUST be used as the default ports for RADIUS over
TCP. TCP.
The early deployment of RADIUS was done using UDP port number 1645, The early deployment of RADIUS was done using UDP port number 1645,
which conflicts with the "datametrics" service. Implementations which conflicts with the "datametrics" service. Implementations
using RADIUS/TCP MUST NOT use TCP ports 1645 or 1646 as the default using RADIUS/TCP MUST NOT use TCP ports 1645 or 1646 as the default
ports for this specification. ports for this specification.
skipping to change at page 10, line 49 skipping to change at page 10, line 48
the end-to-end behavior of a single TCP connection. This typically the end-to-end behavior of a single TCP connection. This typically
is not achievable with an application-layer RADIUS implementation, is not achievable with an application-layer RADIUS implementation,
regardless of transport. regardless of transport.
2.6. TCP Specific Issues 2.6. TCP Specific Issues
The guidelines defined in [RFC3539] for implementing a AAA protocol The guidelines defined in [RFC3539] for implementing a AAA protocol
over reliable transport are applicable to RADIUS/TLS. over reliable transport are applicable to RADIUS/TLS.
The Application Layer Watchdog defined in [RFC3539] Section 3.4 MUST The Application Layer Watchdog defined in [RFC3539] Section 3.4 MUST
be used. The Status-Server packet [STATUS] MUST be used as the be used. The Status-Server packet [RFC5997] MUST be used as the
application layer watchdog message. Implementations MUST reserve one application layer watchdog message. Implementations MUST reserve one
RADIUS ID per connection for the application layer watchdog message. RADIUS ID per connection for the application layer watchdog message.
This restriction is described further below in Section 2.6.4. This restriction is described further below in Section 2.6.4.
RADIUS/TLS Implementations MUST support receiving RADIUS packets over RADIUS/TLS Implementations MUST support receiving RADIUS packets over
both UDP and TLS transports originating from the same endpoint. both UDP and TLS transports originating from the same endpoint.
RADIUS packets received over UDP MUST be replied to over UDP; RADIUS RADIUS packets received over UDP MUST be replied to over UDP; RADIUS
packets received over TLS MUST be replied to over TLS. That is, packets received over TLS MUST be replied to over TLS. That is,
RADIUS clients and servers MUST be treated as unique based on a key RADIUS clients and servers MUST be treated as unique based on a key
of the three-tuple (IP address, port, transport protocol). of the three-tuple (IP address, port, transport protocol).
Implementations MUST permit different shared secrets to be used for Implementations MUST permit different shared secrets to be used for
UDP and TCP connections to the same destination IP address and UDP and TCP connections to the same destination IP address and
skipping to change at page 14, line 7 skipping to change at page 14, line 5
2.6.5. Limitations of the ID Field 2.6.5. Limitations of the ID Field
The RADIUS ID field is one octet in size. As a result, any one TCP The RADIUS ID field is one octet in size. As a result, any one TCP
connection can have only 256 "in flight" RADIUS packets at a time. connection can have only 256 "in flight" RADIUS packets at a time.
If more than 256 simultaneous "in flight" packets are required, If more than 256 simultaneous "in flight" packets are required,
additional TCP connections will need to be opened. This limitation additional TCP connections will need to be opened. This limitation
is also noted in [RFC3539] Section 2.4. is also noted in [RFC3539] Section 2.4.
An additional limit is the requirement to send a Status-Server packet An additional limit is the requirement to send a Status-Server packet
over the same TCP connection as is used for normal requests. As over the same TCP connection as is used for normal requests. As
noted in [STATUS], the response to a Status-Server packet is either noted in [RFC5997], the response to a Status-Server packet is either
an Access-Accept or an Accounting-Response. If all IDs were an Access-Accept or an Accounting-Response. If all IDs were
allocated to normal requests, then there would be no free ID to use allocated to normal requests, then there would be no free ID to use
for the Status-Server packet, and it could not be sent over the for the Status-Server packet, and it could not be sent over the
connection. connection.
Implementations SHOULD reserve ID zero (0) on each TCP connection for Implementations SHOULD reserve ID zero (0) on each TCP connection for
Status-Server packets. This value was picked arbitrarily, as there Status-Server packets. This value was picked arbitrarily, as there
is no reason to choose any one value over another for this use. is no reason to choose any one value over another for this use.
Implementors may be tempted to extend RADIUS to permit more than 256 Implementors may be tempted to extend RADIUS to permit more than 256
skipping to change at page 16, line 24 skipping to change at page 16, line 24
[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.
[RADIUS/TLS] [RADIUS/TLS]
Winter, S. et. al., "TLS encryption for RADIUS over TCP Winter, S. et. al., "TLS encryption for RADIUS over TCP
(RadSec)", draft-ietf-radext-radsec-06.txt, March 2010 (work (RadSec)", draft-ietf-radext-radsec-07.txt, July 2010 (work in
in progress). progress).
[RFC5997] DeKok, A., "Use of Status-Server Packets in the Remote
Authentication Dial In User Service (RADIUS) Protocol", RFC
5997, August, 2010.
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
skipping to change at page 17, line 22 skipping to change at page 17, line 25
[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) [RFC5246] Dierks, T., Rescorla, E., "The Transport Layer Security (TLS)
Protocol Version 1.2", RFC 5246, August 2008. 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-08.txt, May 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. 12 change blocks. 
21 lines changed or deleted 19 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/