On Wed, 8 Jul 2020 at 12:44, Ruslan N. Marchenko <m...@ruff.mobi> wrote:
> Am Dienstag, den 07.07.2020, 10:55 +0100 schrieb Dave Cridland: > > > > On Mon, 6 Jul 2020 at 15:41, Ruslan N. Marchenko <m...@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 <m...@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 <m...@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 <m...@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. > > 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. > > > 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 > _______________________________________________ > Standards mailing list > Info: https://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: standards-unsubscr...@xmpp.org > _______________________________________________ >
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
