[radext] Re: Selfie Attack on TLS-PSK

[Q Misell <[e-mail]>]

> For the "connections in both directions" use-case, it may be possible to
allow Access-Request packets to flow both ways.

Personally I quite like this idea. It would also allow one of the RADIUS
servers to function when it is behind a NAT/firewall.
BGP has the concept of passive connections. Normally in a BGP session both
ends try to open the TCP session, but it can be configured such that only
one end will actively open and the other merely listens, the same could be
done with RADIUS.
------------------------------

Any statements contained in this email are personal to the author and are
not necessarily the statements of the company unless specifically stated.
AS207960 Cyfyngedig, having a registered office at 13 Pen-y-lan Terrace,
Caerdydd, Cymru, CF23 9EU, trading as Glauca Digital, is a company
registered in Wales under № 12417574
<https://find-and-update.company-information.service.gov.uk/company/12417574>,
LEI 875500FXNCJPAPF3PD10. ICO register №: ZA782876
<https://ico.org.uk/ESDWebPages/Entry/ZA782876>. UK VAT №: GB378323867. EU
VAT №: EU372013983. Turkish VAT №: 0861333524. South Korean VAT №:
522-80-03080. AS207960 Ewrop OÜ, having a registered office at Lääne-Viru
maakond, Tapa vald, Porkuni küla, Lossi tn 1, 46001, trading as Glauca
Digital, is a company registered in Estonia under № 16755226. Estonian VAT
№: EE102625532. Glauca Digital and the Glauca logo are registered
trademarks in the UK, under № UK00003718474 and № UK00003718468,
respectively.


On Tue, 30 Jul 2024 at 13:26, Alan DeKok <[e-mail]> wrote:

> On Jul 30, 2024, at 7:18 AM, Jan-Frederik Rieckers <[e-mail]>
> wrote:
> > unfortunately, usually we do have connections in both directions.
>
>   I think that's a separate issue from which identity is used for a
> connection.  The protection from Selfie is just to use different identities.
>
>   On a related note, Margaret and I had discussions in Vancouver about
> two-way TLS connections.  While we have a "reverse CoA" draft, there's also
> nothing preventing other kinds of packets going down a TLS connection.  For
> the "connections in both directions" use-case, it may be possible to allow
> Access-Request packets to flow both ways.
>
> > I never thought of it before reading about the selfie attack, but I
> think most eduroam services would be susceptible for this kind of attack,
> even on RADIUS/UDP, since people probably didn't use different shared
> secrets in the different directions.
>
>   The shared secret is also tied to an IP address.  So a client which has
> the shared secret can't pretend to be the server, because it doesn't have
> the servers IP address.
>
>   Alan DeKok.
>
> _______________________________________________
> radext mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>