Approval announcement
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:
  (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:

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.


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.'