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: > > > > 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). > > 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. 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. > > > 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. > > No, external is not a downgrade. Just to make (ab)use of external > dowgraded to dialback you need level of interception which makes dowgrade > by the PR in scope redundant as you can achieve the same outcome (dialback) > regardless of whether the external behaves as in current XEP0178 edition or > as in proposed modified one. > Ah, OK. Still not a downgrade, as Alice can still authenticate Bob in exactly the same way, and to suppress EXTERNAL you'd need an integrity attack against the session, which'd currently be heavily mitigated by Alice having authenticated Bob's certificate. Dave.
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
