[Standards] XEP-0178: Clarify SASL-EXTERNAL specification when s2s auth fails

Ruslan N. Marchenko me at ruff.mobi
Mon Jul 6 14:20:07 UTC 2020


Am Montag, den 06.07.2020, 13:19 +0100 schrieb Dave Cridland:
> On Mon, 6 Jul 2020 at 12:44, Ruslan N. Marchenko <me at ruff.mobi>
> wrote:
> > Am Montag, den 06.07.2020, 10:46 +0100 schrieb Dave Cridland:
> > > On Sun, 5 Jul 2020 at 22:13, Ruslan N. Marchenko <me at ruff.mobi>
> > > wrote:
> > > > Am Samstag, den 04.07.2020, 19:47 +0100 schrieb Dave Cridland:
> > > > > On Thu, 2 Jul 2020 at 06:58, Ruslan N. Marchenko <
> > > > > me at ruff.mobi> wrote:
> > > > > > Am Mittwoch, den 01.07.2020, 22:53 +0100 schrieb Dave
> > > > > > Cridland:
> > > > > > > >  it cannot establish partially where one side trusts
> > > > > > > > (authenticates) and other does not.
> > > > > > > 
> > > > > > > You can very much establish a TLS session where one side
> > > > > > > authenticates by the certificate presented but the other
> > > > > > > side does not.
> > > > > > Not if you mandate mutual TLS auth (request cert)
> > > > > 
> > > > > "Mutual authentication" means both sides authenticating the
> > > > > other in the same action. Here, both sides can authenticate
> > > > > the other, but need not. Either side is entirely free to
> > > > > ignore the certificate for any number of reasons. (The
> > > > > confusion arises because all SASL mechanisms that support
> > > > > server authentication are by definition mutual
> > > > > authentication).
> > > > Yes, this is exactly the point. But not only that, by mandating
> > > > SASL external over TLS you also mandate TLS mutual
> > > > authentication (which happens within the same protected
> > > > channel).
> > > > 
> > > > 
> > > 
> > > Ah, no. Because SASL EXTERNAL isn't an authentication at all,
> > > there's no implication of mutual authentication (and often isn't
> > > any bidirectional either).
> > Maybe I'm not aware of other uses of EXTERNAL auth but when I
> > wanted to implement EXTERNAL support in XMPP to advertise it in
> > mechanisms and expect interoperability with other client/servers I
> > need to request client certificate (set_verify_mode VERIFY_PEER)
> > and then validate received certificate. If that is not mutual TLS
> > auth then I'm not sure what that is.
> 
> It's client authentication.
> 
> You can do this whether you have a certificate or not yourself -
> though it's fair to say if you don't have a certificate, then very
> few clients or initiating servers will talk to you at all.
> 
> But you absolutely can do this with a self-signed certificate.
> Whether anyone connects to you at *that* point is a matter of their
> policy, not yours.
>  
Sorry I don't follow you here. _How_ you trust the certificate is your
*policy* . The fact that a party *must* have a certificated trusted by
your policy is authentication.
If I am Bob and I trust Alice's certificate, but Alice doesn't trust
mine - could be a policy thing of course. Because Alice may only
accepted certificates issued by hereself or signed by her boyfriend.
It's her decision. But it's a closed system. In open system TLS
validation [policy] is pretty much written down and fixed in 13.7.2 (eg
13.7.2.2.1) and if I follow this *policy* while connecting to open
system and that opens system doesn't trust myself I have two
conclusions - either it is misconfigured or it doesn't actually see
*my* certificate but rather someone else's. Especially this is valid if
we are part of closed system and my certificate was signed by Alice's
boyfriend.
> > >  
> > > > Nevertheless I just realized the whole mechanism proposal part
> > > > is not protected by the SASL so any ill-minded adversary can
> > > > easily suppress EXTERNAL and enjoy dialback-only. So based on
> > > > that I recall my downgrade statement - the attack vector
> > > > requires level of exposure (TLS airgap with trusted
> > > > certificate) which invalidates the whole mechanism and thus any
> > > > imposed by it identity/confedentiality protection.
> > > 
> > > So you now think that SASL EXTERNAL as a whole is subject to some
> > > kind of downgrade attack?
> > > 
> > > Could you please explain this, because it sounds entirely wrong
> > > to me. 
> > > 
> > No, external is not a downgrade. Just to make (ab)use of external
> > dowgraded to dialback you need level of interception which makes
> > dowgrade by the PR in scope redundant as you can achieve the same
> > outcome (dialback) regardless of whether the external behaves as in
> > current XEP0178 edition or as in proposed modified one.
> 
> Ah, OK. Still not a downgrade, as Alice can still authenticate Bob in
> exactly the same way, and to suppress EXTERNAL you'd need an
> integrity attack against the session, which'd currently be heavily
> mitigated by Alice having authenticated Bob's certificate.
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20200706/22d7a4b4/attachment-0001.html>


More information about the Standards mailing list