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: > > > On Wed, 1 Jul 2020 at 17:31, Ruslan N. Marchenko <m...@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).
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. --rr
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
