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

[Margaret Cullen <[e-mail]>]

Hi radext folks,

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.

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. 

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.

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.

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.

Margaret