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

Ruslan N. Marchenko me at ruff.mobi
Mon Jul 6 11:43:59 UTC 2020


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:
> > > > > 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).
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.
>  
> > 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. 
> 
No, external is not a downgrade. Just to make (ab)use of external
dowgraded to dialback you need level of interception which makes
dowgrade by the PR in scope redundant as you can achieve the same
outcome (dialback) regardless of whether the external behaves as in
current XEP0178 edition or as in proposed modified one.

--rr
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20200706/8853d206/attachment.html>


More information about the Standards mailing list