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

[Bernard Aboba <[e-mail]>]

Michael said:

"I'm also lost as to why mutual TLS authentication isn't enough.
Yes, if some unauthenticated keys are used, there might be concern, but that
just doesn't seem to make sense to me."

[BA] "mutual (D)TLS authentication and authorization" has to be well
defined.

RFC 7585 "Dynamic Peer Discovery" (published in 2017) establishes
authorization requirements that are quite different from those that apply
to RADIUS/UDP.   From Section 2.1.1.3:

"This document defines one mandatory-to-implement mechanism that allows
verification of whether the contacted host is authoritative for an NAI
realm or not."

Does "RADIUS over (D)TLS" authorization imply the RFC 7585 definition,
something closer to the RADIUS/UDP model or both??

This deserves some careful consideration.  As Alan has noted, dynamic
discovery opens up potential routing attacks that have not triggered much
concern in RADIUS/UDP "static routing" systems.

In 2024, many of the security assumptions that were commonplace in 2017 no
longer feel as rock solid.  Overall, the pace of change appears to be
accelerating, which implies that we need to look "further down the road"
than we have been used to doing.

Since 2017 we have seen depreciation of TLS 1.0/1.1, and exposure of
multiple weaknesses in TLS 1.2.  Along with explosive demand for "Quantum
as a Service", we have seen introduction of support for post-quantum
ciphersuites in TLS 1.3 (see:
https://aws.amazon.com/security/post-quantum-cryptography/ ).

At IETF 120 PQUIP WG, NIST gave an update on NIST PQC standards:
https://datatracker.ietf.org/meeting/120/materials/slides-120-pquip-nist-pqc-standards

Once NIST issues initial PQC standards, I am expecting there to be
considerable demand for support in TLS 1.3 libraries.  So we should not
just think of TLS 1.3 deployment as being motivated by issues with TLS 1.2.
PQC will also be a deployment motivator. Also, note the addition of
"pessimistic migration" in PQUIP "migration use cases":
https://datatracker.ietf.org/meeting/120/materials/slides-120-pquip-post-quantum-cryptography-migration-use-cases




















On Thu, Jul 25, 2024 at 9:59 AM Michael Richardson <[e-mail]>
wrote:

>
> Peter Deacon <[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.
>
>     > Since channel for per-hop RADIUS data is always mutually
> authenticated
>     > via client cert or shared key I don't see a need for additional
> per-hop
>     > security.
>
> I'm also lost as to why mutual TLS authentication isn't enough.
> Yes, if some unauthenticated keys are used, there might be concern, but
> that
> just doesn't seem to make sense to me.
>
> --
> Michael Richardson <[e-mail]>, Sandelman Software Works
>  -= IPv6 IoT consulting =-                      *I*LIKE*TRAINS*
>
>
>
> _______________________________________________
> radext mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>