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

[Alan DeKok <[e-mail]>]

On Oct 24, 2022, at 11:27 AM, Jan-Frederik Rieckers <[e-mail]> wrote
>>  This is wrong.  The RADIUS shared secret does not "encrypt RADIUS traffic" when TLS is being used.  I suggest just reverting to the RFC6614 abstract.
> 
> I tried to refer to TLS-PSK here, not to the radius encryption.
> I'll reword it.

  Thanks.  Using "shared secret" in the context of RADIUS *always& means the RADIUS shared secret.

> I wasn't sure if TLSv1.3 is "new enough" to mandate its usage, I have no problem with mandating it.

  It's been around for years.  This specification will be used for years.  So we might as well mandate TLS 1.3 now.

>>   You're banning TLS compression.  Why?
> 
> TLSv1.3 does not have compression, RFC7525 discourages compression if there is a possibility for compression-related attacks.
> So my counter-question would be: Why should we need it?

  I was questioning why the change was made.  It would be good to explain that TLS compression is optional for TLS 1.2 and smaller, and not supported by TLS 1.3.

  i.e. the use of compression (or not) is a property of the TLS transport.  It is not a property of RADIUS/TLS.  As such, this document should defer to TLS for TLS functionality.

>>   Removing the Diameter Compatibility section is fine.
>>   A lot of other text has changed, and it's not clear why.  Security information and recommendations have been removed.
>>   It would be good to add text describing operational experience with RADIUS/TLS.  The purpose of the experiment was to see what worked.  So... what were the results?
> 
> Definitely. I'm only aware of the RADIUS/TLS deployment in eduroam, if there are other persons willing to share more operational experience, please feel free to speak up :)

  I hope so.  But We might be waiting a while.  :(

  Alan DeKok.