Re: [radext] BoF request for IETF 115

RADIUS cryptography was considered "marginal" at the time RFC 2058 was
published in 1997.  RFC 6421, which was published in 2011, laid out a
process that was intended to result in deprecation of RADIUS and widespread
deployment of a secure replacement within a decade.

It is now 2022. Given the Personally Identifiable Information (PII) carried
by RADIUS (such as location), I'd argue that allowing RADIUS to transit in
the clear not only violates privacy regulations but should be considered a
risk to public safety.

On Tue, Sep 6, 2022 at 1:30 PM Alan DeKok <aland@deployingradius.com> wrote:

>   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/
>
>   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
>