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

Dave Cridland dave at cridland.net
Mon Jul 6 09:46:30 UTC 2020


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:
>
>
>
> On Wed, 1 Jul 2020 at 17:31, Ruslan N. Marchenko <me at ruff.mobi> wrote:
>
>
> 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.
>
>
> Now this is nit picking. STARTTLS is not a TLS but is a way to secure
> connection with TLS encryption, EXTERNAL is not an authentication but is a
> way to execute mutual TLS x509 authentication.
>
>
>
> The former would be nitpicking; the latter is not.
>
> In S2S, there are two independent authentications going on, and by the
> time the initiator (Alice) issues EXTERNAL, it should have already
> completed its authentication of Bob (and Bob should have at least decided
> to trust the certificate before offering EXTERNAL, with just name matching
> to go).
>
> If Bob rejects EXTERNAL but continues, Alice still knows Bob is the
> correct server. Just that Bob hasn't accepted the certificate.
>
> The only reason for Bob to then close the session is if Bob *only* accepts
> TLS authentication, and moreover cannot handle XEP-0344§2.4. The former is
> perfectly acceptable, of course, and might even be desirable - but it's not
> something I feel needs mandating by inference here.
>
>
>
>
> 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).


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

Dave.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20200706/35dd58ad/attachment-0001.html>


More information about the Standards mailing list