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

Dave Cridland dave at cridland.net
Wed Jul 1 21:53:18 UTC 2020

On Wed, 1 Jul 2020 at 17:31, Ruslan N. Marchenko <me at ruff.mobi> wrote:

> Am Mittwoch, den 01.07.2020, 10:37 +0100 schrieb Dave Cridland:
> On Tue, 30 Jun 2020 at 17:59, Ruslan N. Marchenko <me at ruff.mobi> wrote:
> Am Dienstag, den 30.06.2020, 17:59 +0200 schrieb Jonas Schäfer:
> > Hi list,
> >
> > (Editor hat on)
> >
> > On behalf of the Council, I’d like to bring this pull request to the
> > attention
> > of the community:
> >
> > https://github.com/xsf/xeps/pull/963
> >
> > Input from server operators specifically would be welcomed to see if
> > this
> > change is in fact desirable or if you can see any issues with that.
> > At least
> > one member of the community has already expressed [1] that they think
> > this may
> > lead to downgrade attacks.
> >
> Let me rephrase/expand a bit my statement.
> The SASL EXTERNAL mandates use of TLS and certificate validation (XEP-
> 0220 does not). In theory you can achieve exactly the same level of
> security with Dialback as with EXTERNAL - eg. both sides still auth
> each others' certificates during dialback, and similarly one can put
> additional measures such as DANE + DNSEC.
> See also XEP-0344.
> Note that SASL EXTERNAL absolutely does *not* mandate the use of either
> TLS or X.509 authentication - that is simply (by far) the most common use.
> In SASL (4422) no, in XMPP (6120 13.8.4 and the XEP in discussion) it
> does.
13.8.4 says that TLS+X.509 Auth requires EXTERNAL, not the other way around.

> There are two parties involved, and while EXTERNAL is nearly exclusively
> offered by the Responder when TLS is in use *and* it has validated the
> certificates of the Initiator *and* the supplied or inferred authorization
> identifier matches, it says absolutely nothing about the Initiator's use of
> TLS, X.509, etc - whether or not the Initiator decides to use the mechanism
> offered.
> Now if EXTERNAL fails - that means there's something wrong with the
> certificates. And proposal to fail back to dialback means we want to
> tolerate certificate validation errors. Which is a downgrade.
> Suggesting there is a downgrade attack here raises two important questions:
> By whom?
> Upon whom?
> Let's assume that Alice.example is connecting to Bob.example. Alice may,
> or may not, have decided to trust Bob's certificate. Bob might have decided
> to trust Alice's, or might not. These are completely independent choices on
> the part of the servers.
> In this scenario Bob offers EXTERNAL but then, when that is taken by
> Alice, it fails. There are few cases where this is sensible - one is where
> Alice does not provide a "from" on the stream (technically a violation) and
> the authorization identifier in EXTERNAL is either not present or doesn't
> match, one is where Alice provides a "from", but then uses a different
> authorization identifier in EXTERNAL (or at least one that doesn't match
> the certificate). Neither strike me as good behaviour by Alice, but still.
> At this point, if Bob is willing to let Alice use Dialback (either pure
> XEP-0220, or some form of XEP-0344), why shouldn't it leave the session
> going and allow it? In other words, the downgrade "attack" is by Bob, on
> Bob.
> Because Alice's authentication fails on this particualr conneciton? So it
> may be not Alice after all speaking, despite what 'from' tells (or does
> not). From Bob's perspective someone tries to spoof Alice's server over
> this connection.

The question isn't whether it's a bad decision by Bob or not, but whether
it's an active downgrade. Metre, FWIW, ditches you if you try to provide an
authzid that differs from the stream "from", but it will, I think, allow
you to continue if you provide no stream "from" and are using, for example,
a wildcard cert, so there is no implicit authzid available to it.

> Alice, on the other hand, has already either decided to trust Bob's
> certificate or not. Nothing Bob does at this point affects that decision in
> the slightest, nor alters the security outcome of the decision already
> made. So there is no downgrade attack on Alice here.
> The EXTERNAL TLS  is mutual authentication,

EXTERNAL, with or without TLS, is absolutely not in any way mutual
authentication. EXTERNAL isn't authentication at all, actually.

> 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.

> By disrupting the authentication in whatever way (just to make it fail -
> eg strip from field) you will then expect the peers will follow new
> (amended) standard and retry dialback. The fact that other side doesn't
> trust our certificate (when we know it is ok) may mean there's broken
> integrity on this connection so we should also assume the worst and drop
> the connection.

What? Why? If Alice finds Bob doesn't trust their certificate, but Alice
does trust Bob's, why would Alice worry? Alice's trust requirements are
still met either way, and Alice can prove there is no MITM attack on the
session to Bob.

Indeed, Alice cannot tell if Bob blindly trusts anything at all and always
offers, and accepts, EXTERNAL. Why only be concerned about some kinds of

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20200701/084f64d7/attachment-0001.html>

More information about the Standards mailing list