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

[Alan DeKok <[e-mail]>]

On Jul 24, 2024, at 9:43 AM, Margaret Cullen <[e-mail]> wrote:
> While working through the RADIUS (D)TLS document last night, I realized that RADIUS/(D)TLS does not include support for TLS channel binding.  In other words, there is nothing in the RADIUS/(D)TLS layer that ensures that both ends of a single RADIUS hop are using the same unique (D)TLS session.  Without channel binding, RADIUS running over (D)TLS may be open to MITM attacks including:  blocking valid traffic, spoofing Access-Accepts or Rejects, viewing sensitive data, replay attacks, redirection, DoS, etc.

  If the client and server validate each others identity, does that matter?  We already know that RADIUS proxies can see peoples passwords, block traffic, change accepts to rejects, etc.  We already know that the client might be a proxy, so the client doesn't (in fact) own or even understand the data it's forwarding.

  RADIUS proxies are designed to be MITM, with full MITM capabilities.  So channel binding here just proves what we already known: this proxy is trusted to mangle packets.

> It is up to the WG to decide what to do about this.  As a WG chair, I will insist that, at the very least, we need to update the Security Considerations section in the RADIUS/(D)TLS document to point out this properly of the RADIUS/(D)TLS protocol and its implications.  
> 
> Speaking as an individual, it is my opinion that we should add channel bindings to RADIUS/(D)TLS. 

  Just to clarify the difference between channel binding (RFC 6677) from cryptographic binding.

 Channel bindings prevent the "lying NAS" problem, where a pretend NAS forwards traffic to the "real" system.  This is only needed for EAP, because the supplicant doesn't have a trust relationship with the NAS, only with the RADIUS server.

  i.e. We have communication Suppliant -> NAS -> RADIUS (A, B, and C for simplicity).  A && C share trust (server cert, user credentials).  B & C share trust (RADIUS shared secret).  But A doesn't trust B.

  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.

> Currently, RADIUS/UDP is (albeit poorly) protected against MITM attacks by the use of pre-shared secrets and MD5.  Unfortunately, MD5 is fairly easy to crack these days.  In contrast, RADIUS/(D)TLS is not protected by RADIUS pre-shared secrets, because of the use of well-known “secrets” (radsec or radsec/dtls) instead.  In the absence of any other way to verify that RADIUS traffic is being sent to/from the intended peer, RADIUS/(D)TLS is even less well-protected against MITM attacks than RADIUS/UDP.

  Any MITM attack on RADIUS/TLS would involve breaking TLS.  Or, require that one / both ends fail to validate the others credentials.

  RFC 5056 discusses these issues.  In short, if the channel is (a) authenticated, and (b) integrity checked, and (c) private / encrypted, channel bindings are much less useful.

  The main use of channel bindings is when there are multiple protocols and/or multiple parties involved.  The different protocols are bound together to form one logical shared communications session.

  But with RADUS/TLS, there are no multiple protocols, and there are no multiple parties.  One client sends packets to one server.  Both ends authenticate each other.  We rely on TLS to do authentication, integrity checks, and privacy checks.

> Channel binding with (D)TLS is a well-trodden path in the IETF, and I think it would be best for us to add channel binding to the RADIUS/(D)TLS specification before we move it to the Standards Track.  We are already making non-backwards compatible changes to RADIUS/(D)TLS in the new document (such as requiring servers to implement DTLS, as well as TLS), so I think this would be our best opportunity to correct this omission and standardize a sound specification.  Channel binding in RADIUS/(D)TLS could likely be accomplished by adding an attribute that securely verifies that both ends are using the same TLS session, and exchanging that attribute in RADIUS packets before any sensitive data is transmitted.  For those of you who aren’t familiar with TLS, TLS provides a unique session token that can be used for this purpose.

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

  We already know that the "next" server is forwarding packets elsewhere.  The next server is already a MITM, and is already known to be mangling packets.

> There are, of course, other benefits to transporting RADIUS over (D)TLS vs. UDP that make it highly desirable to deprecate RADIUS/UDP in favor of  RADIUS?(D)TLS, such as encrypting RADIUS packets so they cannot be seen in plain text in transit.  I am definitely _not_ suggesting that we stay with UDP instead of moving to (D)TLS — I’m suggesting that we fix RADIUS/(D)TLS, so that we do not expose RADIUS to new MITM attacks.
> 
> I would, as an individual, and as a WG chair, like to hear other people’s opinions about what (if anything) we should do to resolve this issue.

  I'm not sure what benefits channel binding would add.  I can't think of a concrete case where a MITM attack could occur, and where channel bindings would catch it.

  Alan DeKok.