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

Ruslan N. Marchenko me at ruff.mobi
Wed Jul 8 11:43:09 UTC 2020


Am Dienstag, den 07.07.2020, 10:55 +0100 schrieb Dave Cridland:
> 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.
> 
It is not, both sides need to have private key in order to complete
identification, and client certificate authentication is executed
within server's security context (RFC 5246 7.4.4 Note: It is a fatal
handshake_failure alert for an anonymous server to request client
authentication).
 
You cannot just pick random public key (certificate) and offer it in
TLS CertificateRequest message because there is CertificateVerify
message which requires you to have access to the private key whith
which you need to sign entire handshake (security context). It *is* TLS
authentication.

But yes, you can set a policy where you accept any security context
from the server (pseudo-anonymous) and authentication only client. Or
you can skip CertificateRequest (default state) and authenticate only
server. But when you do RequestCertificate and do VERIFY_PEER (in
whatever way you like) - you are actually doing mutual TLS
authentication. 

I will stop commenting this though, I don't know why are we spending
time arguing about such an obvious thing. Do you want to highlight that
somewhere in some standards this is called out differently? By all
means. dixi.

> 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.
>  
That is again policy decision, which I also don't want to discus it in
this context as it's already hard to track this discussion.

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

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

No, I will not, because it is again a policy thing which I don't want
to discuss here.

My point was to highlight that aborting a secure channel on which
mutual TLS authentication fails is not a policy decision but a security
control thus ditching the control risks a downgrade. However while
trying to prove my point I realised that mutual authentication itself
depends on the integrity of the server side, which invalidates the
control and really moves it to the policy decision area. I think we can
close the discussion at this point.

Thanks everyone.
--rr
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20200708/f2d9a199/attachment-0001.html>


More information about the Standards mailing list