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

[Jan-Frederik Rieckers <[e-mail]>]

Hi Peter, hi all,

(replying on-list to an off-list mail)

this is definitely an interesting idea, I'm not sure if there is an 
actual benefit.
If others have an opinion: Please feel free to tell me where and why I'm 
wrong ;)

See inline comments below.

Cheers,
Janfred

On 27.10.22 18:35, Peter Deacon wrote:
> On Mon, 24 Oct 2022, Jan-Frederik Rieckers wrote:
> 
>> Hi to all,
> 
>> I have submitted a draft to re-specify RADIUS/TLS, as intended by the 
>> proposed radextra charter. (Moving RADIUS/TLS from experimental to 
>> proposed standard)
> 
>> For now, I have only put myself in the author section as editor, if 
>> any of the original RFC6614 authors are interested in helping, please 
>> let me know. (I have already spoken with Stefan Winter and he wanted 
>> to contribute text)
> 
>> Feedback welcome.
> 
> Hi Janfred,
> 
> 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.

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)

This of course is something, we can't control even with full mutual 
authentication with certificates, but it probably is harder, since you 
are more or less forced to exchange the certificate details with the 
admins of the peers, so they can configure their Radsec-Servers accordingly.
If you allow only server authentication, people will likely accept any 
server certificate, which would lead to possibility to 
middle-person-attacks and we would fall back to the "security" of RADIUS.

> 
> 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.
> 
> Security of RADIUS crypto does not matter in this case as TLS is used. 
> Secret need only have sufficient entropy to guard against online 
> guessing from IP authorized clients.
> 
> This has advantage of simplifying deployments using PKI especially when 
> matched with "reverse" connections for dynamic authorization.
> 
> Compatibility is improved as it more naturally fits existing client 
> configuration and allows clients to upgrade to TLS without additional 
> configuration such as assigning new keys or certificates to clients.
> 
> If interested I can send over some text.


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.

Having said that, I would like to add this:
I have an opinion, but no strong opinion (yet), so if there is feedback 
from the community with good arguments that this should be included, I 
would be open to adding it.



-- 
E-Mail: [e-mail] | Fon: [phone] | Fax: [phone]
Pronomen: er/sein | Pronouns: he/him
__________________________________________________________________________________

DFN - Deutsches Forschungsnetz | German National Research and Education 
Network
Verein zur Förderung eines Deutschen Forschungsnetzes e.V.
Alexanderplatz 1 | 10178 Berlin
www.dfn.de

Vorstand: Prof. Dr. Odej Kao (Vorsitzender) | Dr. Rainer Bockholt | 
Christian Zens
Geschäftsführung: Dr. Christian Grimm | Jochem Pattloch
VR AG Charlottenburg 7729B | USt.-ID. DE 1366/23822