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

[Alan DeKok <[e-mail]>]

On Oct 28, 2022, at 4:47 AM, Jan-Frederik Rieckers <[e-mail]> 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.

  I think we have to clearly distinguish RADIUS shared secrets from TLS pre-shared keys (PSK).

  RADIUS/TLS allows for TLS-PSK, and requires that the RADIUS shared secret using inside of the TLS tunnel is "radsec".

  I don't see much value in doing any checks on the RADIUS shared secret.  I do see value in using TLS-PSK, and doing checks on TLS-PSK Identities.

  Also, implementations MUST NOT use the RADIUS shared secret as the TLS-PSK.  Due to TLS version issues, a TLS-PSK MUST NOT be used across different versions of TLS.

> 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.

  I think this is true.

  From a quick check of RFC 6614, it looks like there is no prohibition against bypassing server validation checks.  i.e. Section 2.3 says things like:

          +  Certificate validation MUST include the verification rules
             as per [RFC5280].

  Which implementors can read as "IF you do certificate validation, it MUST ..."

  Experience shows that unless utter idiocies are forbidden, they will be implemented.  And then deployed to millions of devices.

  There is text in RFC2865 which forbids the use of zero-length shared secrets, as that would remove all security from the MD5 packet signing.  The text was added because I ran into NAS equipment which did RADIUS, but which wouldn't let admins enter a shared secret: it was always zero-length!

> 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.

  For the "deprecating RADIUS" and "SRADIUS" documents, the text mandates the use of TLS-PSK, and mandates the use of TLS 1.3 or later for TLS-PSK.

  I think there is a lot of utility in using TLS-PSK.  But I also think it's best to avoid any further discussion of shared secrets.  They're terrible, and need to go away ASAP.

  Alan DeKok.