Re: [radext] BoF request for IETF 115

I support holding this BOF at IETF 115, and I agree that work in this area is important for the continued success of RADIUS.  

Margaret

> From: radext <radext-bounces@ietf.org> on behalf of Alan DeKok <aland@deployingradius.com>
> Sent: Tuesday, 6 September 2022, 21:30
> To: radext@ietf.org <radext@ietf.org>
> Subject: [radext] BoF request for IETF 115
> 
>   I've submitted a BoF request to recharter RADEXT for IETF 115.  The request is at: https://datatracker.ietf.org/doc/bofreq-dekok-bofreq-dekok-radius-extensions-and-security-00/ <https://datatracker.ietf.org/doc/bofreq-dekok-bofreq-dekok-radius-extensions-and-security-00/>
> 
>   It includes a proposed charter.
> 
>   Depending on the opinion of the IESG, the request might be rejected, we might have a BoF, or RADEXT might just be rechartered as WG.
> 
>   The preliminary charter has been shared with the ADs.  It would be good to hear if other people have opinions on (a) the proposal to restart RADEXT, or (b) the charter and work items.
> 
>   The high-level summary was to why we need RADEXT is included here, too.  The link above has more information.
> 
> ---
> There is increasing conflict between the security practices defined in RADIUS and modern cryptographic requirements. The move to RADIUS over TLS / DTLS has helped to secure the base protocol. However, the use of MD4 / MD5 is still "baked into" RADIUS. The use of these digest algorithms makes it impossible to use RADIUS in a FIPS-140 compliant system.
> 
> The WG will define a new SRADIUS which drops all use of MD4 / MD5, and will be suitable for use in a FIPS environment. This work is expected to require only minor changes to existing implementations.
> 
> As part of this effort, the IETF will formally deprecate the use of RADIUS over UDP. There are still many cloud providers sending bare RADIUS packets over the Internet. This practice is insecure, and should be forbidden.
> 
> RADIUS over TLS / DTLS are in wide-spread use. They should be updated to use TLS 1.3, to require Server Name Indication (which helps with sites hosting multiple authoritative servers), and to move the documents to standards track.
> 
> In order to address the 8-bit ID limitation, we also propose to allow for more than 256 packets "in flight" on one connection between client and server. This change will permit higher throughput connections. Some vendors have already implemented their own versions of this work, which has proven to be successful in practice. This behavior should be documented and standardized.
> ---
> 
>   Alan DeKok.
> 
> _______________________________________________
> radext mailing list
> radext@ietf.org
> https://www.ietf.org/mailman/listinfo/radext <https://www.ietf.org/mailman/listinfo/radext>
> 