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

Ruslan N. Marchenko me at ruff.mobi
Thu Jul 9 11:28:46 UTC 2020


Am Donnerstag, den 09.07.2020, 11:27 +0100 schrieb Dave Cridland:
> On Wed, 8 Jul 2020 at 12:44, Ruslan N. Marchenko <me at ruff.mobi>
> wrote:
> > Am Dienstag, den 07.07.2020, 10:55 +0100 schrieb Dave Cridland:
> > > 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.
> > a) full control over XMPP stream
> > b) If Alice's key is compromised (forged or stolen) and Alice's
> > server is fronted by MitM proxy - then Bob's certificate becomes
> > the only mean to protect the integrity/confidentiality of the Bob-
> > to-Alice communication - since Bob's key is still protected,
> > Alice's refusal to accept it causes attacker to achieve nothing.
> > But as I have previously mentioned since Bob follows features
> > section, and features section is only protected by Alice's key
> > (which is compromised) the change in the EXTERNAL behaviour does
> > nothing as EXTERNAL in the case can be eliminated by an attacker by
> > stripping it from the stream features.
> > 
> > 
> 
> OK, let me see if I understand this:
> 
> Alice (a server) calls Bob (another server). We shall assume that
> Alice requires TLS, and will strictly verify the certificate against
> a known trust anchor, and require that Bob's name be present - that
> is, gold-standard TLS policy. We assume that Bob might not have such
> a policy.
> 
> Bob offers, and Alice negotiates, TLS. Both sides provide a
> certificate (and the requisite signing to prove ownership of the
> private keys. At *this* point:
> 
> * Alice has proof of Bob's certificate, and chooses to trust it. This
> proves to Alice that she is genuinely talking to Bob.
> * Bob accepts Alice's certificate, but does not consider it
> sufficient for authentication for some reason.
> 
> Alice then opens a new stream.
> 
> Bob offers EXTERNAL. This offer is, from Alice's perspective, secure.
> 
> Alice issues EXTERNAL.
> 
> Bob does not trust Alice's certificate even after EXTERNAL, and
> continues the connection.
> 
> Alice requests Dialback.
> 
> Bob does some form of Dialback (XEP-0344 or simple XEP-0220).
> 
> Now, at this point, is your assertion that Alice can be actually
> talking to an attacker, and not Bob?
> 
> Bob, I agree, might not be talking to Alice (depending on how clever
> Bob has been with XEP-0344, this might be very unlikely though). But
> that is wholly under the control of Bob; Alice's security posture is
> entirely unaffected.
> 
> You seem to suggest that the attack is based on Alice's key being
> compromised; but if this is so I do not understand what has changed
> here - if the key is compromised that obviously an attacker can
> impersonate Alice - in fact, an attacker can impersonate Alice more
> easily if a pure SASL EXTERNAL is used than if Dialback is used in
> conjunction.
>  

With dialback the integrity of the channel is not enforced therefore an
attacker being able to intercept the communication (front the server
with compromised certificate) can simply pass through the messages
waiting for authentication to complete and then "take the control
back".
Mutual TLS authentication (achieved with EXTERNAL mechanism) though
puts integrity verification similar to TLS channel bindings for SASL -
therefore the integrity is verified on both sides. An attacker won't be
able to forge Bob's certificate, so if EXTERNAL is requested an
attacker can authenticate itself for Bob as Alice (impersonate) but he
won't be able to impersonate himself to Alice as Bob.
I apologize but it seems I have swapped the roles in my example
comparing to your suggested setup.

The attack setup is following - Bob (server1) connecting to Alice
(server2) which is impersonated by an Attacker (MitM proxy with Alice's
compromised certificate).
XEP-0178 currently mandates Alice (server2) to close the stream if
Bob's (server1) auth fails (identity mismatch).  Eg. if an attacker
puts his certificate to Alice but preserves Bob's 'from' header to
maintain s2s routing for Bob - Alice rejects that connection.
Proposed change is for Alice to ignore that error and switch to
dialback on the same established channel which would allow an attacker
to maintain the control over the stream.

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


More information about the Standards mailing list