[radext] Re: Lack of Channel Bindings in RADIUS/(D)TLS

[Margaret Cullen <[e-mail]>]

> On Jul 25, 2024, at 2:47 AM, Fabian Mauchle <fabian.mauchle=[e-mail]> wrote:
> 
> Trying to follow the discussion and understand the issue...
> 
> On 24.07.2024 19:50, Margaret Cullen wrote:
>> When you have two peers A and C, with an authorized proxy, B, you have two RADIUS sessions A -> B and B -> C.  This only works if A has a shared secret with B and B has a shared secret with C.  So, B is part of the trusted set of peers.  Using RadSec, a MITM (Z) could have no trust relationship with A or B, but be receiving traffic from A on one TLS connection, and forwarding it to C on a second TLS connection, while both A and B think that they are directly connected to each other.  Z is not part of the trusted peer group, Z is a MITM attacker.  This is quite different than that forwarding through an authorized proxy.
> 
> If Z has no trust relationship with A, it can't be receiving traffic from A. As a MITM, Z would need to present a certificate (or other identity) to A that A accepts as trustworthy to establish the TLS connection A-Z, at which point the trust relationship between A and Z is established.
> 
> As Alan already pointed out, RADIUS proxies are inherently MITM by design. That is why (in roaming scenarios where A,B and C belong to different parties) we use EAP as the actual AAA within RADIUS.

Some RADIUS Authentications are single hop.  The way people are using Radsec in eduroam, an increasing number of them probably will be.

Some RADIUS Authentications  involve several hops, but none of the RADIUS clients/proxies/servers along that path are MITM attackers.  They are typically mutually trusted systems that are either:  (1) operated by a single organization, or (2) operated by separate organizations in a consortium with mutual trust, agreed policies, and legal agreements.

The question of whether we need crypto binding between the RADIUS and TLS layers for a single Client -> Server hop really has nothing to do with whether the packet will traverse other hops.  It has to do with whether there is a meaningful risk of a TLS MITM attack against a single hop that channel bindings could be used to detect or prevent.

I am being told by TLS people that TLS 1.2 and 1.3 are secure against third-party MITM attacks, except in cases where the attacker has the PSK or Certificate for one side of the connection, in which case it would be easier for them to do a direct attack, rather than setting up a MITM attack.  I could argue that there are things one can do from a MITM position that you can’t do via a direct attack, especially if you have the server key and want to influence what the real Server does.  I am not sure anyone will agree or think that matters, though.

So, I think we just need to say in the Security Considerations that we do not use channel binding in RADIUS/(D)TLS because we mandate the use of (D)TLS 1.2 or !.3 with either PSKs or Certificates, and those protocols are well-enough protected against MITM attacks already.

Margaret



> 
> -- 
> Fabian Mauchle
> Network
> NOC:    [phone]
> Direct: [phone]
> 
> Switch
> Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland
> 
> _______________________________________________
> radext mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]