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

[Peter Deacon <[e-mail]>]

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