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

Dave Cridland dave at cridland.net
Tue Jul 7 09:55:00 UTC 2020


On Mon, 6 Jul 2020 at 15:41, Ruslan N. Marchenko <me at ruff.mobi> wrote:

> Am Montag, den 06.07.2020, 16:20 +0200 schrieb Ruslan N. Marchenko:
>
> 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.
>
>
> Also. Server authentication + client authentication = Mutual
> Authentication.
>
>
Normally, "mutual authentication" means both sides have assured that the
other is authenticated *and* has authenticated them. For example, SCRAM and
DIGEST both have the server provide proof that the server also knows the
secret used by the client. That's not the case with TLS's use of X.509 -
each authentication is unidirectional and independent.

Client authentication can occur with, or without, server authentication.
Client authentication can occur with SASL EXTERNAL. Or it can occur without
it. Or SASL EXTERNAL can - in rare cases - be offered where TLS client
authentication hasn't occurred at all. In other words, the offering of
EXTERNAL - while it should only be offered when the server expects the
client will be able to successfully use EXTERNAL - doesn't mean anything in
security terms, and nor does the client using (or not) EXTERNAL.

VERIFY_PEER will verify the certificate (establish whether it has a trusted
path), but you could also verify it as the same certificate used in
previous sessions, or as a method to increase security of dialback if you
wanted. Depending on your views of how secure CAs are, this might be
preferable.


> X509 based TLS is Server Auth. VERIFY_PEER requests Client Auth - both
> together are mutual x509 TLS Auth.
>
>
But - ignoring whether VERIFY_PEER actually authenticates or not - that's
not really the case, since Alice might ignore Bob's certificate and connect
anyway (because, perhaps, DNSSEC is in play and IP spoofing with
unauthenticated TLS is hard, or perhaps Alice is just stupid), and Bob will
never know what authentication has occured. This doesn't matter, broadly,
because Bob can authenticate Alice and ensure there's no MITM, etc.

In C2S auth, where we typically have no certificate on the client side,
things are different - Bob cannot authenticate the safety of the channel
without something else (and that something else is Channel Binding).


> XMPP over TLS uses x509 TLS and thus Server Auth. SASL EXTERNAL requests
> Client x509 cert and thus Client Auth. Both together achieve Mutual Auth.
> It does not tell how you validate or verify certificate validity (which is
> your *policy*) only how to request Client auth and how to obtain
> authenticated client's and server's identity from the wire protocol.
>

You keep using that term. I do not think it means what you think it means.


>
>
> 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.
>
>
Not convinced that this follows.

If Alice connects and authenticates Bob via some means, and Bob
authenticates Alice by some means, what does it matter to Alice how Bob
authenticates Alice, or vice-versa?

Your statement is that there is a potential downgrade attack here; my
assertion is that there is not.

Could you please describe:

a) What the attacker gains.
b) How the attacker carries out the attack.


> 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.
>
>
Can you show me where the list of trust anchors is mandated?

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


More information about the Standards mailing list