Re: [radext] New draft: RFC6614bis (RADIUS/TLS)

[Peter Deacon <[e-mail]>]

On Fri, 28 Oct 2022, Jan-Frederik Rieckers wrote:

>> Think it might be worth considering a slight change to "radsec" static 
>> secrets.  There has been feedback on operational costs with deploying PKI 
>> that can lead to PSK/PAKE being preferred.

> I don't see exactly why this would be a bad thing. A PSK/PAKE with a strong 
> password should be enough to secure the connection in the same way as 
> certificates do.

>> For some likely to be little practical value in requiring overhead of 
>> managing client certificates for every RADIUS client.

>> Typical solution for adding TLS to existing protocols is clients 
>> authenticate servers via PKI while clients continue supporting existing 
>> client authentication mechanisms over TLS.  Think it would be useful for 
>> this to also be possible with RADIUS.

> It definitely is an intriguing proposal, but it carries the problem, that 
> certificate validation logic needs to be implemented in the clients either 
> way.

Hi Janfred,

The value is from operators not being required to provision and manage 
client certificates for every client.  Clients would still be required to 
authenticate servers and have a database of trust anchors.

> And speaking from personal experience, if there is the possibility to click 
> "Ignore certificate errors", people will do it, because they say "We have the 
> security via the shared secret, we don't need this stupid SSL, it always 
> breaks things" (using the term SSL with full intent here)

I believe cert validation should be mandatory where PKI is used.

>> Static "radsec" would be maintained for mutually authenticated TLS (client 
>> certs, PSK/PAKE..etc) yet for TLS where only server is authenticated a 
>> shared secret and message authenticator would be mandatory in order for 
>> server to authenticate client.

> I feel that with the possibility to use PSK, we have a good way to secure the 
> transport and either way we would have to manage the PSKs (or shared secrets 
> in your proposal) on the server, so adding server authentication via TLS just 
> adds more configuration to the server side.

>From past experience with operator selection of secrets recommend keeping 
secrets and PSK separate.  However bad RADIUS crypto is tradition of poor 
quality secrets still likely to be the weakest link.

regards,
Peter