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

[Bernard Aboba <[e-mail]>]

Peter Deacon said:

"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."

[BA] Exactly. For RFC 3579's definition of RADIUS over IPsec, it was not
necessary to create a new version of RADIUS so it should not be required
here either.

"Hey isn't RADIUS over TLS S(ecure)RADIUS?  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.

I would prefer there be only one RADIUS over TLS standard not multiple
incompatible ones."

[BA] That's my take as well.  RADIUS over (D)TLS won't need MD5 in the
authenticator anyway, so why not specify how to avoid this usage within the
specs?  Why is it necessary to define an entirely new protocol??

On Tue, Nov 22, 2022 at 6:48 AM Peter Deacon <[e-mail]>
wrote:

> On Tue, 22 Nov 2022, Paul Wouters wrote:
>
> >>  In order for RADIUS to work in a FIPS -140 environment, the RADIUS
> >>  protocol has to be purged of dependencies on MD5.
>
> > Indeed, there is a special exemption for radius when I was involved with
> > FIPS certifications at redhat because there is no way to do radius
> > without md5. Fixing this is one of the main reasons for doing the radius
> > work. This is not about transport security, which can be configured to
> > be FIPS compliant.
>
> It is understandable for security standards to specify allowed algorithms.
>
> Also understandable for security stacks to not make unallowed algorithms
> available to applications.
>
> What I'm not clear on is where in any applicable security standards are
> such algorithms prohibited in applications for reasons other than
> security?
>
>
> 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.
>
> Hey isn't RADIUS over TLS S(ecure)RADIUS?  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.
>
> I would prefer there be only one RADIUS over TLS standard not multiple
> incompatible ones.
>
> regards,
> Peter
>