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

[Q Misell <[e-mail]>]

> 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 1.3 with either PSKs or Certificates, and those protocols are
well-enough protected against MITM attacks already.

Agreed. The hop-by-hop nature of RADIUS and the common practice of
modifying messages at hops makes channel binding a moot point.
------------------------------

Any statements contained in this email are personal to the author and are
not necessarily the statements of the company unless specifically stated.
AS207960 Cyfyngedig, having a registered office at 13 Pen-y-lan Terrace,
Caerdydd, Cymru, CF23 9EU, trading as Glauca Digital, is a company
registered in Wales under № 12417574
<https://find-and-update.company-information.service.gov.uk/company/12417574>,
LEI 875500FXNCJPAPF3PD10. ICO register №: ZA782876
<https://ico.org.uk/ESDWebPages/Entry/ZA782876>. UK VAT №: GB378323867. EU
VAT №: EU372013983. Turkish VAT №: 0861333524. South Korean VAT №:
522-80-03080. AS207960 Ewrop OÜ, having a registered office at Lääne-Viru
maakond, Tapa vald, Porkuni küla, Lossi tn 1, 46001, trading as Glauca
Digital, is a company registered in Estonia under № 16755226. Estonian VAT
№: EE102625532. Glauca Digital and the Glauca logo are registered
trademarks in the UK, under № UK00003718474 and № UK00003718468,
respectively.


On Sat, 27 Jul 2024 at 01:03, 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]
>