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

[Alan DeKok <[e-mail]>]

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.