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

[Margaret Cullen <[e-mail]>]

Hi Alan,

Thank you very much for your careful explanation.  However, it doesn’t entirely address my concern…. Let me take one comment out-of-context, with the goal of brevity, not of trying to misrepresent what you said...

> On Jul 24, 2024, at 1:20 PM, Alan DeKok <[e-mail]> wrote:
>  Channel bindings are a statement by C to A that "you can trust this particular B".
> 
>  But for RADIUS/TLS, we don't have multiple parties.  There's just client and server.  Either they trust each other, or they don't.
> 
>  In contrast, cryptographic bindings ensure that any derived challenges / keys are associated with the TLS connection.  So that a MITM can't force the use of a particular challenge, and this break authentication protocols.
> 
>  But for RADIUS/TLS, we don't have any challenges, etc. which are sent between client and server.  The client and server are effectively routing AAA traffic which they don't understand, control, or even originate.
> 
>  So I don't see how either cryptographic binding or channel binding helps here.

For RADIUS/UDP, though, we _do_ have a challenge that ensures that the client is authorized to send a message to the server, and that the server is authorized to receive a message from the client — based on pre-shared keys and MD5.  We also have a mechanism to ensure that if a RADIUS request reaches the wrong server (e,g. an attacker) the most sensitive parts of the RADIUS message cannot be seen in clear text — also based on pre-shared keys and MD5.

Those mechanisms have been removed in RADIUS/(D)TLS, and they have not really been replaced by anything.

>  But we've already authenticated the server via TLS.  How does it help to tie the application data to the TLS session? 

This is only true if we know that the system on the other end of the TLS session is an authorized peer.  How do we know that?  

Without checking that the TLS session token is the same on both ends of a TLS session, it is possible that the TLS session is being terminated by a MITM who has a second TLS session with the intended peer, and is shuttling data between those sessions while viewing the data, and potentially modifying parts of it that are not protected at the application layer, etc.

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.

Is there some way that TLS protects from a MITM attack these days that removes the need for channel binding to avoid this possibility?  In previous work I’ve done involving (D)TLS, albeit quite a few years ago, the application layer had to do a cryptographic exchange to ensure that both ends were using the same TLS session.

Margaret