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. 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. > 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. > 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? Dave.
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
