The IESG has approved the following document: - 'RADIUS/1.1, Leveraging ALPN to remove MD5' (draft-ietf-radext-radiusv11-11.txt) as Experimental RFC
This document is the product of the RADIUS EXTensions Working Group. The IESG contact persons are Paul Wouters and Deb Cooley. A URL of this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-radext-radiusv11/ Technical Summary This document defines Application-Layer Protocol Negotiation Extensions for use with RADIUS/TLS and RADIUS/DTLS. These extensions permit the negotiation of an additional application protocol for RADIUS over (D)TLS. No changes are made to RADIUS/UDP or RADIUS/TCP. The extensions allow the negotiation of a transport profile where the RADIUS shared secret is no longer used, and all MD5-based packet signing and attribute obfuscation methods are removed. When this extension is used, the previous Authenticator field is repurposed to contain an explicit request / response identifier, called a Token. The Token also allows more than 256 packets to be outstanding on one connection. This extension can be seen as a transport profile for RADIUS, as it is not an entirely new protocol. It uses the existing RADIUS packet layout and attribute format without change. As such, it can carry all present and future RADIUS attributes. Implementation of this extension requires only minor changes to the protocol encoder and decoder functionality. The protocol defined by this extension is named "RADIUS version 1.1", or "RADIUS/1.1". This document updates RFC5176, RFC6614, and RFC 7360. Working Group Summary Broad consensus from the relatively small radius group. There was some controversy around the naming of the new specification. Ultimately it was decided to not name the document "RADIUS version 1.1", since it is not really a new RADIUS version, however, this name is still present in the ALPN label. Another point of controversy was around the specific language regarding FIPS-140 compliance, especially regarding the ability to be FIPS complient despite using cryptographic methods like MD5, if they are not used for security. Input from several individuals that have experience in this area should have resolved these issues, so that the document reflects a correct representation of the topic regarding FIPS-140 compliance. Document Quality There is one implementation (freeradius) and two other implementations have said they will implement it (radsecproxy and RADIATOR) Personnel The Document Shepherd for this document is Jan-Frederik Rieckers. The Responsible Area Director is Paul Wouters. _______________________________________________ IETF-Announce mailing list -- [email protected] To unsubscribe send an email to [email protected]
