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

[Alexander Clouter <[e-mail]>]

Hello,

On Wed, 23 Nov 2022, at 16:02, Peter Deacon wrote:
>
> Setting shared secret to "radsec" is an unambiguous declaration security 
> of all secret dependencies (PAP, tunnel passwords, MPPE, 
> message-sig/authenticators) are a nullity.  They persist entirely for 
> compatibility and are made redundant by TLS.

To avoid vendors having to include negotiation or rewrite chunks of their implementation, I suspect the authors at the time needed to pick something. Stating "do not use a shared secret" ten years ago would have opened the can of worms on what to do about Message-Authenticator and to do about User-Password.

Add to this a mixed environments and an unknown at the time what impact this may have had on the administration of such a deployment, it looks like it was a good choice.

Maybe at the time, getting TLS out there in a way others could experiment with was seen as more important; how far can you get with not much more than 's/(connect|accept|...)/SSL_&/g' across your codebase.

> If there is no actual technical requirement I believe it would be better 
> to resolve outstanding confusion with additional text in standards track 
> RADIUS TLS than having two incompatible standards.

RadSec exists and is widely in use today even though the RFC is marked experimental. I would probably be of benefit to have the operational knowledge of the past ten years turning it into a non-experimental RFC; I think it was suggested it could be RFC6614bis or something.

> Personally don't care if RadSec or SRADIUS approach is selected.  I see 
> nothing good coming from two different options that accomplish the same 
> thing.

Whatever is specified, needs to get through a FIPS tick boxing exercise. Not a technical problem but something that is probably outside of everyone's control.

I do not know how much effort it would be to get TLS-PSK into RadSec or removing MD5, but then more importantly making sure there is backwards compatibility with the large federated existing RFC6614 deployments.

This is starting to sound like a new protocol.

I see RFC6614bis as a way to capture the operational knowledge already out there, particularly from the eduroam community. I then see SRADIUS as a way for us to do "given it is 2022, what would we do today differently?".

Regards

Alex