RADIUS over TCP
Draft of message to be sent after approval:
From: The IESG
To: IETF-Announce Cc: Internet Architecture Board , RFC Editor , radext mailing list , radext chair Subject: Document Action: 'RADIUS Over TCP' to Experimental RFC (draft-ietf-radext-tcp-transport-09.txt) The IESG has approved the following document: - 'RADIUS Over TCP' (draft-ietf-radext-tcp-transport-09.txt) as an Experimental RFC This document is the product of the RADIUS EXTensions Working Group. The IESG contact persons are Dan Romascanu and Ron Bonica. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-radext-tcp-transport/
Technical Summary RADIUS has traditionally used UDP as its underlying transport layer, for reasons described in RFC 2865 Section 2.4. This document defines RADIUS over TCP, in order to address handling issues related to RADIUS over TLS (RTLS). It is not intended to define TCP as a transport protocol for RADIUS in the absence of TLS. Working Group Summary This document is part of a set (including the Status-Server and RTLS specifications) which together define RADIUS over TLS (RTLS). This document has completed RADEXT WG last call, with the primary areas of discussion relating to liveness detection and congestion control. Document Quality The document has been reviewed by IETF RADEXT WG members. RADIUS over TCP/TLS has been implemented by multiple vendors, including RADIATOR and FreeRADIUS. The protocol is currently deployed by EDUROAM, an educational roaming consortium supporting more than one million users worldwide. As a result, the document reflects operational experience. Personnel Bernard Aboba is the document shepherd for this document. Dan Romascanu was the first responsible Area Director. Benoit Claise is the current responsible Area Director. RFC Editor Note In the Security COnsiderations section, please insert the following text between the second and the third paragraph: '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. 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.'