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

[Bernard Aboba <[e-mail]>]

Alan said:

"Please read the SRADIUS draft.  It explains all of these issues very
clearly.  There are very good reasons for removing MD5 from RADIUS.  There
are very good reasons for not calling the resulting protocol "RADIUS"."

[BA] I have read the SRADIUS draft. There are some good ideas in there.

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.

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 process set out by RFC 6421 was designed to only advance a small set of
deployed, interoperable specifications to Proposed Standard.

It will be hard enough to get one specification per transport widely
deployed. Getting that done will require testing and certification programs
along the lines of what was done for IEEE 802.11 security.

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.

There was a time when the IETF took pride in producing concise, "Simple"
interoperable specifications with as few options as possible and no
"profiles".  That still seems like a worthy goal for this effort.











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.





On Tue, Nov 22, 2022 at 7:36 AM Alan DeKok <[e-mail]>
wrote:

> On Nov 22, 2022, at 9:49 AM, Peter Deacon <[e-mail]> wrote:
> > What I'm not clear on is where in any applicable security standards are
> such algorithms prohibited in applications for reasons other than security?
>
>   NIS SP 800-140Cr1 lists the allowed digest algorithms in FIPS-140-3:
> https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-140Cr1.pdf.
> MD5 isn't on the list
>
>   i.e. they list the allowed ciphers, digests, etc.  Everything else is
> explicitly forbidden.
>
>   So you can't use MD5 for *any* purpose and be FIPS compliant.
>
> > I am concerned with the idea of multiple seemingly identical
> incompatible versions of RADIUS.  SRADIUS naming in particular is likely to
> be a source of avoidable operator confusion.
>
>   SRADIUS is a transport profile for RADIUS.   We've already added TCP,
> TLS, and DTLS to the original UDP-only RADIUS.  The potential for confusion
> is relatively small.
>
> > Hey isn't RADIUS over TLS S(ecure)RADIUS?
>
>   It's true that TLS allows for transport-layer security.  But if names
> are a problem, why are we using RadSec or RADIUS/TLS?  Why not just RADIUS
> for everything?
>
>   For me, the point of choosing a new name is to highlight the differences
> between this transport and normal RADIUS transport.  Names matter, and
> names have meaning.
>
> >  It connects ok but why does the connection keep dropping as soon as I
> send an authentication request? Presumably some operators wouldn't even
> have a choice to select non-SRADIUS and interopability would be impossible.
>
>   Why wouldn't people have a choice with interoperability?  You're making
> assumptions without explaining why those assumptions are true.
>
>   You're also assuming that operators and administrators have no tools
> with which to debug network connections.  I don't see that as true.
>
> > I would prefer there be only one RADIUS over TLS standard not multiple
> incompatible ones.
>
>     Please read the SRADIUS draft.  It explains all of these issues very
> clearly.  There are very good reasons for removing MD5 from RADIUS.  There
> are very good reasons for not calling the resulting protocol "RADIUS".
>
>    Alan DeKok.
>
>