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: > > > > 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). > > 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). > 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. > So you now think that SASL EXTERNAL as a whole is subject to some kind of downgrade attack? Could you please explain this, because it sounds entirely wrong to me. Dave.
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
