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

Dave Cridland dave at cridland.net
Wed Jul 1 09:37:01 UTC 2020


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.

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.

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.


> Now, if we want to loosen the failure scenario, we need to explicitly
> call out that this is only acceptable without loss of security controls
> (validation) - eg just a misconfiguration.
>
> Now again EXTERNAL misconfiguration is kind of obvious - connection is
> lost if integrity/confidentiality is not achievable. Dialback does not
> put anything like that in place to ensure that.
>
> Regards,
> Ruslan
>
> _______________________________________________
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: Standards-unsubscribe at xmpp.org
> _______________________________________________
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20200701/bb98b4a5/attachment-0001.html>


More information about the Standards mailing list