[radext] Re: Selfie Attack on TLS-PSK

[Q Misell <[e-mail]>]

Moin,

Having read the Selfie paper here's my thoughts on what RADIUS should do
about it.

> "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 believe this wording is sufficient to protect against the attack.

I also think there should be a note about a node only ever acting as server
or only ever acting as a client (i.e. only ever making outgoing
connections, or only ever accepting incoming connections) being sufficient
to protect against Selfie.
The concept of a server and client is new to RADIUS, but say in the case of
eduroam there's a clear relationship where say JISC (UK NREN) would only
ever accept incoming connections from member IdPs, and member IdPs would
only ever make outgoing connections to JISC.
Can anyone think of a scenario where this wouldn't be the case?
------------------------------

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 Fri, 26 Jul 2024 at 12:14, <[e-mail]> wrote:

> Margaret wrote:
> > Speaking as an individual…
> >
> > I am not talking about trying to establish any sort of cryptographic
> end-to-end
> > trust in a multi-hop RADIUS fabric.  I agree that we don’t have that
> today, and
> > it is not our goal to change that.  I am talking about the security
> properties of a
> > single RADIUS hop. I am also talking about how those properties feed
> into the
> > security models of multi-hop deployments.
>
> Ah, ok, sorry for the misrepresentation...
>
> > As Stefan points out, copying of a RADIUS/TLS-transmitted RADIUS message
> > on to a local network is different (and less secure) than dumb copying
> of a
> > message that was transmitted via RADIUS/UDP, because sensitive data in
> the
> > message transmitted via UDP will still be protected (to some degree) by
> the
> > RADIUS secret and MD5, while the packet coming from RADIUS/TLS would use
> > a well-known RADIUS secret, “radsec”, essentially equivalent to sending
> the
> > sensitive parts of the packet in clear text.
>
> The entity doing Stefan's "copying" is not a classic RADIUS entity. It
> sounds like a proxy that operates purely at the transport layer (and not
> the application layer). A RADIUS proxy translating TLS to UDP must mint a
> new request using the secret shared with the downstream server.
>
> There is a problem if Stefan's entity existed, but it isn't a mode of
> operation supported the RFCs and I don't know of any products doing this.
>
> > My point is that we should make sure that moving away from the solution
> we
> > are deprecating (RADIUS/UDP) and moving to any if the solutions we are
> > recommending (any one of the RadSec variants) does not result in security
> > regressions, and that any security model changes are well-documented.
>
> +1
>
> Josh
>
> _______________________________________________
> radext mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>