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

Ruslan N. Marchenko me at ruff.mobi
Mon Jul 6 14:40:44 UTC 2020


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.
X509 based TLS is Server Auth. VERIFY_PEER requests CLient Auth - both
together are mutual x509 TLS Auth.
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 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.
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20200706/033f931a/attachment.html>


More information about the Standards mailing list