Re: [radext] Proposed charter text based on IETF-115 BoF

[Bernard Aboba <[e-mail]>]

Alan said:

"  But the issue of variants is a problem.  It would be ideal to just
re-use RADIUS/TLS port 2083, and then do some kind of negotiation.  Since
RADIUS doesn't include per-hop negotiation, that's difficult to do."

[BA] I'm wondering why negotiation is needed. Installations know whether
they want to conform to FIPS or not. If they do, then failure of MD5
operations is not a bug, it's the desired outcome.

For backwards compatibility, servers probably need to support RADIUS and
the existing RADIUS over (D)TLS anyway.  So really we're talking about an
"SRADIUS" configuration flag.  If a site requires FIPS, why can't it flip
the SRADIUS flag and run its SRADIUS server on port 2083?  If some devices
can't connect to an SRADIUS-configured server, then those devices don't
support SRADIUS and presumably the site wants to point them at another
server (one without the SRADIUS flag set), and eventually replace them with
devices that support SRADIUS.

On Thu, Nov 24, 2022 at 6:15 AM Alan DeKok <[e-mail]>
wrote:

> On Nov 23, 2022, at 6:58 PM, Bernard Aboba <[e-mail]>
> wrote:
> > If the intent is to integrate those portions of the draft that garner WG
> consensus into the RADIUS over (D)TLS specifications, then the document
> represents a useful contribution.
>
>   OK.
>
> > But if the end result is a specification for each transport in addition
> to a separate SRADIUS specification, then this seems problematic to me,
> because you'd effectively have 4+ protocol variants (2 transports + SRADIUS
> on or off), each of which could declare itself a "Proposed Standard".
>
>   The goal of the draft is to define a (D)TLS transport profile for
> RADIUS.  Everything else is 100% RADIUS.
>
>   But the issue of variants is a problem.  It would be ideal to just
> re-use RADIUS/TLS port 2083, and then do some kind of negotiation.  Since
> RADIUS doesn't include per-hop negotiation, that's difficult to do.
>
> > Since protocol variants and "options" greatly expand the test matrix and
> certification cost, if the WG produces 4+ variants of "secure RADIUS" there
> will be a temptation for industry consortia to produce their own "profiles"
> of SRADIUS + (D)TLS in order to reduce the complexity.
>
>   I'm not sure I see how that will happen.  The only profiles available
> for customization are TLS parameters.  Everything else is mandated by the
> RADIUS specifications.
>
> > But there is also an awful lot of "amateur lawyering" in the document,
> including statements relating to the implications of FIPS-140 requirements
> that differ very substantially from NIST documentation and official
> guidance.
>
>   That text can be updated, of course.
>
>   Until there's an official statement from NIST, we're largely left with
> amateur lawyering.  What would be ideal is for NIST to publish an explicit
> statement about RADIUS and it's use of MD5.
>
>   When people point at NIST specifications and make claims, it is very
> difficult to counter those claims with logical arguments.  After all, I'm
> just a random internet commenter, and NIST is an official organization.
>
>   Why would anyone believe me?  I have a hard enough time convincing
> people to believe the documentation I write about the software I've
> written.  It's essentially impossible to convince people that I somehow
> know more / better than their reading of NIST specifications.
>
>   The only practical way to counter NIST documentation saying "MD5 is not
> allowed" is another bit of NIST documentation saying "It's OK for RADIUS to
> use MD5 with (D)TLS".
>
>   Alan DeKok.
>
>