[radext] Re: Selfie Attack on TLS-PSK

[Jan-Frederik Rieckers <[e-mail]>]

Hi Q,

unfortunately, usually we do have connections in both directions.
Taking DFN and Uni Bremen as an example:
DFN is a proxy, but since RADIUS is hop-by-hop, each hop has a RADIUS 
client and a RADIUS server, so I'll use those terms.

And the proxy acs as both client and server for connected institutions.

The Uni Bremen is an eduroam IdP, meaning that the DFN acs as RADIUS 
client (on behalf of the actual RADIUS client, i.e. the APs at IETF).
But it also acs as a RADIUS server for the Uni Bremen on behalf of every 
other IdP if users from different institutions are visiting Uni Bremen.

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.

I have to check it carefully, but I can think of some other potentially 
harmful scenarios, which could lead to a DoS. I'll write a mail again 
once I confirmed the existence of this flaw.

Cheers,
Janfred

On 30.07.24 09:54, Q Misell wrote:
> 
> 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] 
> <mailto:[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] <mailto:[e-mail]>
>     To unsubscribe send an email to [e-mail]
>     <mailto:[e-mail]>
> 
> 
> _______________________________________________
> radext mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]

-- 
Herr Jan-Frederik Rieckers
Security, Trust & Identity Services

E-Mail: [e-mail] | Fon: [phone] | Fax: [phone]
Pronomen: er/sein | Pronouns: he/him
__________________________________________________________________________________

DFN - Deutsches Forschungsnetz | German National Research and Education 
Network
Verein zur Förderung eines Deutschen Forschungsnetzes e.V.
Alexanderplatz 1 | 10178 Berlin
https://www.dfn.de

Vorstand: Prof. Dr.-Ing. Stefan Wesner | Prof. Dr. Helmut Reiser | 
Christian Zens
Geschäftsführung: Dr. Christian Grimm | Jochem Pattloch
VR AG Charlottenburg 7729B | USt.-ID. DE 136623822