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

[Bernard Aboba <[e-mail]>]

Margaret said:

"because we mandate the use of (D)TLS 1.2 or !.3 with either PSKs or
Certificates, and those protocols are well-enough protected against MITM
attacks already."

[BA] Does the WG really need to take a position on whether (D)TLS 1.2
provides adequate protection (currently or in the future)?

There are known security issues with TLS 1.2 that are mitigated in TLS 1.3,
and TLS 1.3 libraries are also more likely to support PQC ciphersuites to
mitigate future attacks.

The transition to RADIUS over (D)TLS is likely to be protracted. It would
be unfortunate for that transition to be initiated with (D)TLS 1.2 and then
for another transition to be required to (D)TLS 1.3.




On Fri, Jul 26, 2024 at 4:03 PM Margaret Cullen <[e-mail]>
wrote:

>
>
> > On Jul 25, 2024, at 2:47 AM, Fabian Mauchle <fabian.mauchle=
> [e-mail]> wrote:
> >
> > Trying to follow the discussion and understand the issue...
> >
> > On 24.07.2024 19:50, Margaret Cullen wrote:
> >> 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.
> >
> > If Z has no trust relationship with A, it can't be receiving traffic
> from A. As a MITM, Z would need to present a certificate (or other
> identity) to A that A accepts as trustworthy to establish the TLS
> connection A-Z, at which point the trust relationship between A and Z is
> established.
> >
> > As Alan already pointed out, RADIUS proxies are inherently MITM by
> design. That is why (in roaming scenarios where A,B and C belong to
> different parties) we use EAP as the actual AAA within RADIUS.
>
> Some RADIUS Authentications are single hop.  The way people are using
> Radsec in eduroam, an increasing number of them probably will be.
>
> Some RADIUS Authentications  involve several hops, but none of the RADIUS
> clients/proxies/servers along that path are MITM attackers.  They are
> typically mutually trusted systems that are either:  (1) operated by a
> single organization, or (2) operated by separate organizations in a
> consortium with mutual trust, agreed policies, and legal agreements.
>
> The question of whether we need crypto binding between the RADIUS and TLS
> layers for a single Client -> Server hop really has nothing to do with
> whether the packet will traverse other hops.  It has to do with whether
> there is a meaningful risk of a TLS MITM attack against a single hop that
> channel bindings could be used to detect or prevent.
>
> I am being told by TLS people that TLS 1.2 and 1.3 are secure against
> third-party MITM attacks, except in cases where the attacker has the PSK or
> Certificate for one side of the connection, in which case it would be
> easier for them to do a direct attack, rather than setting up a MITM
> attack.  I could argue that there are things one can do from a MITM
> position that you can’t do via a direct attack, especially if you have the
> server key and want to influence what the real Server does.  I am not sure
> anyone will agree or think that matters, though.
>
> So, I think we just need to say in the Security Considerations that we do
> not use channel binding in RADIUS/(D)TLS because we mandate the use of
> (D)TLS 1.2 or !.3 with either PSKs or Certificates, and those protocols are
> well-enough protected against MITM attacks already.
>
> Margaret
>
>
>
> >
> > --
> > Fabian Mauchle
> > Network
> > NOC:    [phone]
> > Direct: [phone]
> >
> > Switch
> > Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland
> >
> > _______________________________________________
> > radext mailing list -- [e-mail]
> > To unsubscribe send an email to [e-mail]
>
> _______________________________________________
> radext mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>