Re: [saag] RADIUS is deprecating MD5

Alan said:

"  We know that MD5 is insecure.  We know that many Access-Request packets
lack all integrity checks.  I've been trying to fix this issue since 2005
or so.

  Why can't we just say "yes, 1993-era protocols are bad.  Wrap them in
TLS.  Move on".

  I am more than a bit surprised that there is any resistance to this
effort."

[BA]  The effort to upgrade RADIUS security is now more than a decades. The
effort kicked off in 2011 with the publication of RFC 6421, which laid out
the requirements as well as the thinking on how a transition would work.
The RADEXT WG, which I chaired, then solicited and published as
Experimental RFCs solutions which were based on RADIUS over (D)TLS.  The
protocols were subsequently implemented, and drafts are incorporating
clarifications and updates.

To be sure, the deployment barriers are significant, but the transition
model has been thought through.  For example, it is possible to run a
mixture of secure and insecure RADIUS clients along with servers supporting
both existing and secure RADIUS so as to allow for legacy devices
implementing only classic RADIUS to continue to operate alongside new
devices implementing secure RADIUS.  When all the legacy devices have been
replaced, the server can be reconfigured to accept only secure RADIUS
requests.

The initial RADIUS over (D)TLS RFCs didn't have to say much about MD5
because the approach was to encrypt and authenticate RADIUS packets using
TLS cyphersuites. This approach worked and can continue to be used with the
new specifications under development.  The problem occurred in FIPS-140
environments where calls to MD5 primitives *fail*.  The original
specifications were not crystal clear on the desired behavior in such a
situation, and there were hints that some very bad bugs could arise (e.g.
secrets sent in the clear over the network).

Alan and others took the initiative to come up with recommendations
covering not only RADIUS servers, but also RADIUS clients and even
FIPS-configured clients not running RADIUS at all.  Those experienced with
operating FIPS-140 compliant services may be particularly interested in
understanding how the recommendations would apply to their situations.

On Sun, Mar 31, 2024 at 8:56 AM Alan DeKok <aland@deployingradius.com>
wrote:

> On Mar 31, 2024, at 11:37 AM, Viktor Dukhovni <ietf-dane@dukhovni.org>
> wrote:
> > This does not sound like an MD5 issue, rather this is about metadata
> > leakage from RADIUS/UDP, and MD5 is mostly just collateral damage or
> > a distraction from the core issue?
>
>   We know that MD5 is insecure.  We know that many Access-Request packets
> lack all integrity checks.  I've been trying to fix this issue since 2005
> or so.
>
>   Why can't we just say "yes, 1993-era protocols are bad.  Wrap them in
> TLS.  Move on".
>
>   I am more than a bit surprised that there is any resistance to this
> effort.
>
>   Alan DeKok.
>
> _______________________________________________
> saag mailing list
> saag@ietf.org
> https://www.ietf.org/mailman/listinfo/saag
>