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

[Alan DeKok <[e-mail]>]

On Jul 24, 2024, at 10:50 AM, Margaret Cullen <[e-mail]> wrote:
>> 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?  

  By authenticating both ends.

  EAP-TTLS and PEAP need channel binding, because the TLS connection is authenticated at only one end.   EAP-TLS doesn't do channel binding, because both ends are authenticated.

  With RADIUS/TLS, both ends are authenticated, just as with EAP-TLS.

  This is covered in RFC 8446:

https://datatracker.ietf.org/doc/html/rfc8446#appendix-C.5

  i.e. unauthenticated systems need channel binding.

> 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.

  From my understanding, that's true only if there isn't mutual authentication.

> 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.

  A TLS intermediary works only if both

> 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.

  From my understanding, mutual authentication means that isn't necessary.

  Alan DeKok.