[radext] Re: Selfie Attack on TLS-PSK

[Alan DeKok <[e-mail]>]

On Jul 25, 2024, at 2:19 AM, Fabian Mauchle <fabian.mauchle=[e-mail]> wrote:
> So what we want to avoid is for servers accepting connections from clients that 'impersonate' the servers identity (it would itself use for outgoing connections).
> 
> Maybe we should add something to section 4.3. 'PSK and PSK Identity Sharing' like:
> 
> "Nodes that act both as client and server at the same time MUST NOT share or reuse PSK identities between incoming and outgoing connections."

  I'll add this text to the TLS-PSK draft, and reference the Selfie attack.

> This might also have implications on radiusdtls-bis, since current proposals allow skipping the identity check and authorize e.g. based on policy OID. Such a scenario might also be susceptible to to Selfie.

  Yes.

  I think it's also worth updating the "deprecating insecure practices" document with some additional text.  I have some more topics to add, too:

* Access-Reject should be delayed, to prevent dictionary attacks

  Many RADIUS servers do this already.  But it's not written down anywhere.

  Note that Access-Request packets should only be delayed on the home server.  Proxies shouldn't delay them.

  This is relevant even when Access-Request packets contain Message-Authenticator.  Access-Request packets are triggered by user logins, and those can happen at any time.


* any comparison of digests, passwords, etc. should be constant-time.

  Many RADIUS servers do this already.  But it's not written down anywhere.

  Doing this will prevent certain classes of attack.  While these attacks are not known to be exploitable today, it's good practice to take preventative steps.

  Many other protocols have been subject to timing attacks.  I suspect the reason this hasn't been publicized for RADIUS is that no one bothered to try it.


* The routing issue should also be discussed, as it's applicable to all of RADIUS, independent of the transport protocol

  The document can note that there is no RADIUS routing protocol, and each system must be configured to pass only valid / expected traffic, and filter unexpected traffic.

  The big question here is "what to do with the bad traffic?"  Access-Request packets can get responses of Access-Reject.  Accounting-Request packets just get dropped?

  And can proxies engage in such filtering?  My point would be "yes".  Traffic which fails to satisfy local policy rules shouldn't be forwarded.

  Alan DeKok.