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

Alan said:

"Due to TLS version issues, a TLS-PSK MUST NOT be used across different
versions of TLS."

[BA] What are the implications of this?  Does an operator need to configure
distinct TLS-PSKs for TLS 1.2 and TLS 1.3??

On Fri, Oct 28, 2022 at 6:19 AM Alan DeKok <aland@deployingradius.com>
wrote:

> On Oct 28, 2022, at 4:47 AM, Jan-Frederik Rieckers <rieckers@dfn.de>
> 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.
>
> _______________________________________________
> radext mailing list
> radext@ietf.org
> https://www.ietf.org/mailman/listinfo/radext
>