Re: [Standards] XEP-0178: Clarify SASL-EXTERNAL specification when s2s auth fails
On Dienstag, 30. Juni 2020 17:59:34 CEST Jonas Schäfer wrote: > Hi list, > > (Editor hat on) > > On behalf of the Council, I’d like to bring this pull request to the > attention of the community: > > https://github.com/xsf/xeps/pull/963 Okay, this took me a long time to look at. I think intent-wise this is OK by me. We haven’t written down anywhere that a server or client may not attempt multiple authentication flows within the same TCP stream and I don’t think we should. Allowing the initiator to proceed with dialback if external fails (and if the responder offers dialback, of course) is just another instance of that. I’ll post my vote in the minutes thread. kind regards, Jonas signature.asc Description: This is a digitally signed message part. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XEP-0178: Clarify SASL-EXTERNAL specification when s2s auth fails
My apologies for not replying to this one, though I think it's covered elsewhere in this discussion. For completeness: On Wed, 1 Jul 2020 at 13:28, Philipp Hancke wrote: > If the receiving server follows the process described in #9 of >https://xmpp.org/extensions/xep-0178.html#s2s > which says that you do the authentication at this point (and then again > in #11) how can external fail? > > If in step 7b, the Initiator (Server1) doesn't include a `from` attribute (which is not conformant to RFC 6120), and in addition either: a) Uses an explicit authorization identity that does not match in the SASL EXTERNAL exchange, or b) Does not provide an authorization identity, and one cannot be derived from the certificate (wildcards, etc). Option (a) used to be quite common, where a certificate for `example.org` was being used additionally by `conference.example.org` for instance, but less so now. The same vintage servers that neglect to provide a `from` attribute also tend to always provide an authorization identifier, so (b) isn't very common at all. > If the receiving server can not authenticate the request its a policy > decision to not offer external and maybe use dialback. > > Am 30.06.20 um 17:59 schrieb Jonas Schäfer: > > Hi list, > > > > (Editor hat on) > > > > On behalf of the Council, I’d like to bring this pull request to the > attention > > of the community: > > > > https://github.com/xsf/xeps/pull/963 > > > > Input from server operators specifically would be welcomed to see if this > > change is in fact desirable or if you can see any issues with that. At > least > > one member of the community has already expressed [1] that they think > this may > > lead to downgrade attacks. > > > > kind regards and thank you, > > Jonas > > > > [1]: > https://mail.jabber.org/pipermail/standards/2020-June/037592.html > > > > > > ___ > > 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 > ___ > ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XEP-0178: Clarify SASL-EXTERNAL specification when s2s auth fails
Am Donnerstag, den 09.07.2020, 11:27 +0100 schrieb Dave Cridland: > On Wed, 8 Jul 2020 at 12:44, Ruslan N. Marchenko > wrote: > > Am Dienstag, den 07.07.2020, 10:55 +0100 schrieb Dave Cridland: > > > 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. > With dialback the integrity of the channel is not enforced therefore an attacker being able to intercept the communication (front the server with compromised certificate) can simply pass through the messages waiting for authentication to complete and then "take the control back". Mutual TLS authentication (achieved with EXTERNAL mechanism) though puts integrity verification similar to TLS channel bindings for SASL - therefore the integrity is verified on both sides. An attacker won't be able to forge Bob's certificate, so if EXTERNAL is requested an attacker can authenticate itself for Bob as Alice (impersonate) but he won't be able to impersonate himself to Alice as Bob. I apologize but it seems I have swapped the roles in my example comparing to your suggested setup. The attack setup is following - Bob (server1) connecting to Alice (server2) which is impersonated by an Attacker (MitM proxy with Alice's compromised certificate). XEP-0178 currently mandates Alice (server2) to close the stream if Bob's (server1) auth fails (identity mismatch). Eg. if an attacker puts his certificate to Alice but preserves Bob's 'from' header to maintain s2s routing for Bob - Alice rejects that connection. Proposed change is for Alice to ignore that error and switch to dialback on the same established channel which would allow an attacker to maintain the control over the stream. --rr ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XEP-0178: Clarify SASL-EXTERNAL specification when s2s auth fails
On Wed, 8 Jul 2020 at 12:44, Ruslan N. Marchenko wrote: > Am Dienstag, den 07.07.2020, 10:55 +0100 schrieb Dave Cridland: > > > > On Mon, 6 Jul 2020 at 15:41, Ruslan N. Marchenko 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 wrote: > > Am Montag, den 06.07.2020, 10:46 +0100 schrieb Dave Cridland: > > > > On Sun, 5 Jul 2020 at 22:13, Ruslan N. Marchenko wrote: > > Am Samstag, den 04.07.2020, 19:47 +0100 schrieb Dave Cridland: > > > > On Thu, 2 Jul 2020 at 06:58, Ruslan N. Marchenko 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
Re: [Standards] XEP-0178: Clarify SASL-EXTERNAL specification when s2s auth fails
Am Dienstag, den 07.07.2020, 10:55 +0100 schrieb Dave Cridland: > On Mon, 6 Jul 2020 at 15:41, Ruslan N. Marchenko > 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 > > > > 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 > di
Re: [Standards] XEP-0178: Clarify SASL-EXTERNAL specification when s2s auth fails
On Mon, 6 Jul 2020 at 15:41, Ruslan N. Marchenko 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 wrote: > > Am Montag, den 06.07.2020, 10:46 +0100 schrieb Dave Cridland: > > > > On Sun, 5 Jul 2020 at 22:13, Ruslan N. Marchenko wrote: > > Am Samstag, den 04.07.2020, 19:47 +0100 schrieb Dave Cridland: > > > > On Thu, 2 Jul 2020 at 06:58, Ruslan N. Marchenko 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 authent
Re: [Standards] XEP-0178: Clarify SASL-EXTERNAL specification when s2s auth fails
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 > > wrote: > > > Am Montag, den 06.07.2020, 10:46 +0100 schrieb Dave Cridland: > > > > On Sun, 5 Jul 2020 at 22:13, Ruslan N. Marchenko > > > > 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. X509 based TLS is Server Auth. VERIFY_PEER requests CLient Auth - both together are mutual x509 TLS Auth. 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 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. > 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. > ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XEP-0178: Clarify SASL-EXTERNAL specification when s2s auth fails
Am Montag, den 06.07.2020, 13:19 +0100 schrieb Dave Cridland: > On Mon, 6 Jul 2020 at 12:44, Ruslan N. Marchenko > wrote: > > Am Montag, den 06.07.2020, 10:46 +0100 schrieb Dave Cridland: > > > On Sun, 5 Jul 2020 at 22:13, Ruslan N. Marchenko > > > 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. > > 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. 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. > > > > > > > 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. > ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XEP-0178: Clarify SASL-EXTERNAL specification when s2s auth fails
On Mon, 6 Jul 2020 at 12:44, Ruslan N. Marchenko wrote: > Am Montag, den 06.07.2020, 10:46 +0100 schrieb Dave Cridland: > > > > On Sun, 5 Jul 2020 at 22:13, Ruslan N. Marchenko wrote: > > Am Samstag, den 04.07.2020, 19:47 +0100 schrieb Dave Cridland: > > > > On Thu, 2 Jul 2020 at 06:58, Ruslan N. Marchenko wrote: > > Am Mittwoch, den 01.07.2020, 22:53 +0100 schrieb Dave Cridland: > > > > On Wed, 1 Jul 2020 at 17:31, Ruslan N. Marchenko 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
Re: [Standards] XEP-0178: Clarify SASL-EXTERNAL specification when s2s auth fails
Am Montag, den 06.07.2020, 10:46 +0100 schrieb Dave Cridland: > On Sun, 5 Jul 2020 at 22:13, Ruslan N. Marchenko > wrote: > > Am Samstag, den 04.07.2020, 19:47 +0100 schrieb Dave Cridland: > > > On Thu, 2 Jul 2020 at 06:58, Ruslan N. Marchenko > > > 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. > > > 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 downg
Re: [Standards] XEP-0178: Clarify SASL-EXTERNAL specification when s2s auth fails
On Sun, 5 Jul 2020 at 22:13, Ruslan N. Marchenko wrote: > Am Samstag, den 04.07.2020, 19:47 +0100 schrieb Dave Cridland: > > > > On Thu, 2 Jul 2020 at 06:58, Ruslan N. Marchenko wrote: > > Am Mittwoch, den 01.07.2020, 22:53 +0100 schrieb Dave Cridland: > > > > On Wed, 1 Jul 2020 at 17:31, Ruslan N. Marchenko 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 ___
Re: [Standards] XEP-0178: Clarify SASL-EXTERNAL specification when s2s auth fails
Am Samstag, den 04.07.2020, 19:47 +0100 schrieb Dave Cridland: > On Thu, 2 Jul 2020 at 06:58, Ruslan N. Marchenko > wrote: > > Am Mittwoch, den 01.07.2020, 22:53 +0100 schrieb Dave Cridland: > > > On Wed, 1 Jul 2020 at 17:31, Ruslan N. Marchenko > > > 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 ___
Re: [Standards] XEP-0178: Clarify SASL-EXTERNAL specification when s2s auth fails
On Thu, 2 Jul 2020 at 06:58, Ruslan N. Marchenko wrote: > Am Mittwoch, den 01.07.2020, 22:53 +0100 schrieb Dave Cridland: > > > > On Wed, 1 Jul 2020 at 17:31, Ruslan N. Marchenko 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). > > > By disrupting the authentication in whatever way (just to make it fail - > eg strip from field) you will then expect the peers will follow new > (amended) standard and retry dialback. The fact that other side doesn't > trust our certificate (when we know it is ok) may mean there's broken > integrity on this connection so we should also assume the worst and drop > the connection. > > > What? Why? If Alice finds Bob doesn't trust their certificate, but Alice > does trust Bob's, why would Alice worry? > > Because under normal circumstances the certificate is trusted hence > expectation is it will be accepted. > Same as if you know your credentials are valid but server does not accept > it. It means something worng with the server or it is wrong server. > > Alice knows whether or not it's the right server based on Bob's presented certificate. If Bob then turns out to not trust Alice's certificate, this doesn't affect whether or not Alice has trusted Bob's, and Bob is still proven to be the right server. If this were not the case, then there would be an attack whereby Bob *pretends* to trust Alice's credentials. > Let's put couple examples here > - we have exchanged certificate fingerprints with Alice - we both _must_ > trust each other certificates. If we don't there are two possibilities - > misconfiguration and mitm. > That's a fallacy - the trust relationship is, for want of a better phrase, half-duplex - Alice's trust of Bob doesn't tell you anything about Bob's trust of Alice and vice-versa. > - we both obtained certificates from trusted authority and expect we both > trust each other. If we don't either there's misconfiguration on our side, > on other side (CA might have revoked the cert) or the dark side (mitm). > > Again, no - if Alice sees a valid certificate for Bob, then Alice can know there is no MITM between them. If Bob doesn't see a valid certificate from Alice then Bob cannot know that, but that affects Bob's knowledge, and not Alice's. Moreover, there is no absolute definition of a trusted authority. Perhaps Bob's admin isn't satisfied wi
Re: [Standards] XEP-0178: Clarify SASL-EXTERNAL specification when s2s auth fails
Am Mittwoch, den 01.07.2020, 22:53 +0100 schrieb Dave Cridland: > On Wed, 1 Jul 2020 at 17:31, Ruslan N. Marchenko > 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. > > > 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) > > > By disrupting the authentication in whatever way (just to make it > > fail - eg strip from field) you will then expect the peers will > > follow new (amended) standard and retry dialback. The fact that > > other side doesn't trust our certificate (when we know it is ok) > > may mean there's broken integrity on this connection so we should > > also assume the worst and drop the connection. > > What? Why? If Alice finds Bob doesn't trust their certificate, but > Alice does trust Bob's, why would Alice worry? Because under normal circumstances the certificate is trusted hence expectation is it will be accepted. Same as if you know your credentials are valid but server does not accept it. It means something worng with the server or it is wrong server. Let's put couple examples here - we have exchanged certificate fingerprints with Alice - we both _must_ trust each other certificates. If we don't there are two possibilities - misconfiguration and mitm.- we both obtained certificates from trusted authority and expect we both trust each other. If we don't either there's misconfiguration on our side, on other side (CA might have revoked the cert) or the dark side (mitm). In other words - If Bob cares about secure communication with Alice he cares whether she trusts his certificate or not.What is suggested though is - let's ignore this and do our best to reach Availability, sacrificing Integrity and Confidentiality. > Alice's trust requirements are still met either way, and Alice can > prove there is no MITM attack on the session to Bob. > > Indeed, Alice cannot tell if Bob blindly trusts anything at all and > always offers, and accepts, EXTERNAL. Why only be concerned about > some kinds of misconfiguration? > ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XEP-0178: Clarify SASL-EXTERNAL specification when s2s auth fails
On Wed, 1 Jul 2020 at 17:31, Ruslan N. Marchenko wrote: > Am Mittwoch, den 01.07.2020, 10:37 +0100 schrieb Dave Cridland: > > > > On Tue, 30 Jun 2020 at 17:59, Ruslan N. Marchenko wrote: > > Am Dienstag, den 30.06.2020, 17:59 +0200 schrieb Jonas Schäfer: > > Hi list, > > > > (Editor hat on) > > > > On behalf of the Council, I’d like to bring this pull request to the > > attention > > of the community: > > > > https://github.com/xsf/xeps/pull/963 > > > > Input from server operators specifically would be welcomed to see if > > this > > change is in fact desirable or if you can see any issues with that. > > At least > > one member of the community has already expressed [1] that they think > > this may > > lead to downgrade attacks. > > > Let me rephrase/expand a bit my statement. > > The SASL EXTERNAL mandates use of TLS and certificate validation (XEP- > 0220 does not). In theory you can achieve exactly the same level of > security with Dialback as with EXTERNAL - eg. both sides still auth > each others' certificates during dialback, and similarly one can put > additional measures such as DANE + DNSEC. > > > See also XEP-0344. > > Note that SASL EXTERNAL absolutely does *not* mandate the use of either > TLS or X.509 authentication - that is simply (by far) the most common use. > > In SASL (4422) no, in XMPP (6120 13.8.4 and the XEP in discussion) it > does. > > 13.8.4 says that TLS+X.509 Auth requires EXTERNAL, not the other way around. > There are two parties involved, and while EXTERNAL is nearly exclusively > offered by the Responder when TLS is in use *and* it has validated the > certificates of the Initiator *and* the supplied or inferred authorization > identifier matches, it says absolutely nothing about the Initiator's use of > TLS, X.509, etc - whether or not the Initiator decides to use the mechanism > offered. > > > Now if EXTERNAL fails - that means there's something wrong with the > certificates. And proposal to fail back to dialback means we want to > tolerate certificate validation errors. Which is a downgrade. > > > Suggesting there is a downgrade attack here raises two important questions: > > By whom? > > Upon whom? > > Let's assume that Alice.example is connecting to Bob.example. Alice may, > or may not, have decided to trust Bob's certificate. Bob might have decided > to trust Alice's, or might not. These are completely independent choices on > the part of the servers. > > In this scenario Bob offers EXTERNAL but then, when that is taken by > Alice, it fails. There are few cases where this is sensible - one is where > Alice does not provide a "from" on the stream (technically a violation) and > the authorization identifier in EXTERNAL is either not present or doesn't > match, one is where Alice provides a "from", but then uses a different > authorization identifier in EXTERNAL (or at least one that doesn't match > the certificate). Neither strike me as good behaviour by Alice, but still. > > At this point, if Bob is willing to let Alice use Dialback (either pure > XEP-0220, or some form of XEP-0344), why shouldn't it leave the session > going and allow it? In other words, the downgrade "attack" is by Bob, on > Bob. > > 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. > 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. > By disrupting the authentication in whatever way (just to make it fail - > eg strip from field) you will then expect the peers will follow new > (amended) standard and retry dialback. The fact that other side doesn't > trust our certificate (when we know it is ok) may mean there's broken > integrity on this connection so we should also assume the worst and drop > the connection. > What? Why? If Alice finds Bob doesn't trust their certificate, but Alice does trust Bob's, why would Alice worr
Re: [Standards] XEP-0178: Clarify SASL-EXTERNAL specification when s2s auth fails
Am Mittwoch, den 01.07.2020, 10:37 +0100 schrieb Dave Cridland: > On Tue, 30 Jun 2020 at 17:59, Ruslan N. Marchenko > wrote: > > Am Dienstag, den 30.06.2020, 17:59 +0200 schrieb Jonas Schäfer: > > > > > Hi list, > > > > > > > > > > (Editor hat on) > > > > > > > > > > On behalf of the Council, I’d like to bring this pull request to > > the > > > > > attention > > > > > of the community: > > > > > > > > > > https://github.com/xsf/xeps/pull/963 > > > > > > > > > > Input from server operators specifically would be welcomed to see > > if > > > > > this > > > > > change is in fact desirable or if you can see any issues with > > that. > > > > > At least > > > > > one member of the community has already expressed [1] that they > > think > > > > > this may > > > > > lead to downgrade attacks. > > > > > > > > > Let me rephrase/expand a bit my statement. > > > > > > > > The SASL EXTERNAL mandates use of TLS and certificate validation > > (XEP- > > > > 0220 does not). In theory you can achieve exactly the same level of > > > > security with Dialback as with EXTERNAL - eg. both sides still auth > > > > each others' certificates during dialback, and similarly one can > > put > > > > additional measures such as DANE + DNSEC. > > > > > > See also XEP-0344. > > Note that SASL EXTERNAL absolutely does *not* mandate the use of > either TLS or X.509 authentication - that is simply (by far) the most > common use. > In SASL (4422) no, in XMPP (6120 13.8.4 and the XEP in discussion) it does. > There are two parties involved, and while EXTERNAL is nearly > exclusively offered by the Responder when TLS is in use *and* it has > validated the certificates of the Initiator *and* the supplied or > inferred authorization identifier matches, it says absolutely nothing > about the Initiator's use of TLS, X.509, etc - whether or not the > Initiator decides to use the mechanism offered. > > > Now if EXTERNAL fails - that means there's something wrong with the > > > > certificates. And proposal to fail back to dialback means we want > > to > > > > tolerate certificate validation errors. Which is a downgrade. > > > > > > Suggesting there is a downgrade attack here raises two important > questions: > > By whom? > > Upon whom? > > Let's assume that Alice.example is connecting to Bob.example. Alice > may, or may not, have decided to trust Bob's certificate. Bob might > have decided to trust Alice's, or might not. These are completely > independent choices on the part of the servers. > > In this scenario Bob offers EXTERNAL but then, when that is taken by > Alice, it fails. There are few cases where this is sensible - one is > where Alice does not provide a "from" on the stream (technically a > violation) and the authorization identifier in EXTERNAL is either not > present or doesn't match, one is where Alice provides a "from", but > then uses a different authorization identifier in EXTERNAL (or at > least one that doesn't match the certificate). Neither strike me as > good behaviour by Alice, but still. > > At this point, if Bob is willing to let Alice use Dialback (either > pure XEP-0220, or some form of XEP-0344), why shouldn't it leave the > session going and allow it? In other words, the downgrade "attack" is > by Bob, on Bob. > 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. > 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, it cannot establish partially where one side trusts (authenticates) and other does not. By disrupting the authentication in whatever way (just to make it fail - eg strip from field) you will then expect the peers will follow new (amended) standard and retry dialback. The fact that other side doesn't trust our certificate (when we know it is ok) may mean there's broken integrity on this connection so we should also assume the worst and drop the connection. --rr ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XEP-0178: Clarify SASL-EXTERNAL specification when s2s auth fails
If the receiving server follows the process described in #9 of https://xmpp.org/extensions/xep-0178.html#s2s which says that you do the authentication at this point (and then again in #11) how can external fail? If the receiving server can not authenticate the request its a policy decision to not offer external and maybe use dialback. Am 30.06.20 um 17:59 schrieb Jonas Schäfer: Hi list, (Editor hat on) On behalf of the Council, I’d like to bring this pull request to the attention of the community: https://github.com/xsf/xeps/pull/963 Input from server operators specifically would be welcomed to see if this change is in fact desirable or if you can see any issues with that. At least one member of the community has already expressed [1] that they think this may lead to downgrade attacks. kind regards and thank you, Jonas [1]: https://mail.jabber.org/pipermail/standards/2020-June/037592.html ___ 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 ___
Re: [Standards] XEP-0178: Clarify SASL-EXTERNAL specification when s2s auth fails
On Tue, 30 Jun 2020 at 19:59, Holger Weiß wrote: > * Jonas Schäfer [2020-06-30 17:59]: > > On behalf of the Council, I'd like to bring this pull request to the > attention > > of the community: > > > > https://github.com/xsf/xeps/pull/963 > > Wait, is this PR actually modifying the authentication step it intends > to change? I was assuming we're talking about XEP-0178, #3, step 7 (a), > where the spec tells the receiving server to close the connection if > initial certificate verification fails. The PR is instead changing step > 11 (b), where the receiving server checks the new stream's 'from' > against the certificate. > > I don't think that's the case, but it is certainly unclear. What it (attempts to, i think) say is that if the authorization identifier does not match, then... And it *also* says that the authorization identifier should be taken from the stream from, and that this ought to match any supplied during the EXTERNAL exchange itself. We should probably clarify this text, it *is* unclear, but I don't think this particular change makes it any less so. > Holger > ___ > 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 ___
Re: [Standards] XEP-0178: Clarify SASL-EXTERNAL specification when s2s auth fails
On Wed, 1 Jul 2020 at 10:41, Dave Cridland wrote:
>
>
> On Tue, 30 Jun 2020 at 19:46, Kim Alvefur wrote:
>
>> This does result in a number of different possible configurations. Not
>> great for something security related. Personally I hope we might be able
>> to phase out Dialback in the future. Today, largely thanks to Let's
>> Encrypt, more and more servers have valid certificates. So, the Dialback
>> code paths are more and more disused.
>>
>> My own server requires valid certificates and this is mosly an issue
>> with certain XSF members (you know who you are). As a bonus, many
>> unmaintained certificates with expired certificates that I am unable to
>> establish s2s with appear to be sources of spam, which I am spared from.
>
>
> Getting rid of the dialback syntax entirely depends on whether we want to
> get rid of S2S multiplexing ("Piggybacking") or not. Also XEP-0288 depends
> on the dialback syntax.
>
>
Ooops - no, it doesn't. XEP-0288 is independent, so it's just multiplexing.
> FWIW, there are deployments around which - for sensible reasons - do not
> use TLS at all, and having dialback is a useful way of
> providing authentication without TLS, though it's not clear to me they need
> even the security of the actual dialback token verification.
>
> Dave.
>
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___
Re: [Standards] XEP-0178: Clarify SASL-EXTERNAL specification when s2s auth fails
On Tue, 30 Jun 2020 at 19:46, Kim Alvefur wrote:
> This does result in a number of different possible configurations. Not
> great for something security related. Personally I hope we might be able
> to phase out Dialback in the future. Today, largely thanks to Let's
> Encrypt, more and more servers have valid certificates. So, the Dialback
> code paths are more and more disused.
>
> My own server requires valid certificates and this is mosly an issue
> with certain XSF members (you know who you are). As a bonus, many
> unmaintained certificates with expired certificates that I am unable to
> establish s2s with appear to be sources of spam, which I am spared from.
Getting rid of the dialback syntax entirely depends on whether we want to
get rid of S2S multiplexing ("Piggybacking") or not. Also XEP-0288 depends
on the dialback syntax.
FWIW, there are deployments around which - for sensible reasons - do not
use TLS at all, and having dialback is a useful way of
providing authentication without TLS, though it's not clear to me they need
even the security of the actual dialback token verification.
Dave.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___
Re: [Standards] XEP-0178: Clarify SASL-EXTERNAL specification when s2s auth fails
On Tue, 30 Jun 2020 at 17:59, Ruslan N. Marchenko wrote: > Am Dienstag, den 30.06.2020, 17:59 +0200 schrieb Jonas Schäfer: > > Hi list, > > > > (Editor hat on) > > > > On behalf of the Council, I’d like to bring this pull request to the > > attention > > of the community: > > > > https://github.com/xsf/xeps/pull/963 > > > > Input from server operators specifically would be welcomed to see if > > this > > change is in fact desirable or if you can see any issues with that. > > At least > > one member of the community has already expressed [1] that they think > > this may > > lead to downgrade attacks. > > > Let me rephrase/expand a bit my statement. > > The SASL EXTERNAL mandates use of TLS and certificate validation (XEP- > 0220 does not). In theory you can achieve exactly the same level of > security with Dialback as with EXTERNAL - eg. both sides still auth > each others' certificates during dialback, and similarly one can put > additional measures such as DANE + DNSEC. > > See also XEP-0344. Note that SASL EXTERNAL absolutely does *not* mandate the use of either TLS or X.509 authentication - that is simply (by far) the most common use. There are two parties involved, and while EXTERNAL is nearly exclusively offered by the Responder when TLS is in use *and* it has validated the certificates of the Initiator *and* the supplied or inferred authorization identifier matches, it says absolutely nothing about the Initiator's use of TLS, X.509, etc - whether or not the Initiator decides to use the mechanism offered. > Now if EXTERNAL fails - that means there's something wrong with the > certificates. And proposal to fail back to dialback means we want to > tolerate certificate validation errors. Which is a downgrade. > > Suggesting there is a downgrade attack here raises two important questions: By whom? Upon whom? Let's assume that Alice.example is connecting to Bob.example. Alice may, or may not, have decided to trust Bob's certificate. Bob might have decided to trust Alice's, or might not. These are completely independent choices on the part of the servers. In this scenario Bob offers EXTERNAL but then, when that is taken by Alice, it fails. There are few cases where this is sensible - one is where Alice does not provide a "from" on the stream (technically a violation) and the authorization identifier in EXTERNAL is either not present or doesn't match, one is where Alice provides a "from", but then uses a different authorization identifier in EXTERNAL (or at least one that doesn't match the certificate). Neither strike me as good behaviour by Alice, but still. At this point, if Bob is willing to let Alice use Dialback (either pure XEP-0220, or some form of XEP-0344), why shouldn't it leave the session going and allow it? In other words, the downgrade "attack" is by Bob, on Bob. 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. > Now, if we want to loosen the failure scenario, we need to explicitly > call out that this is only acceptable without loss of security controls > (validation) - eg just a misconfiguration. > > Now again EXTERNAL misconfiguration is kind of obvious - connection is > lost if integrity/confidentiality is not achievable. Dialback does not > put anything like that in place to ensure that. > > Regards, > Ruslan > > ___ > 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 ___
Re: [Standards] XEP-0178: Clarify SASL-EXTERNAL specification when s2s auth fails
* Jonas Schäfer [2020-06-30 17:59]: > On behalf of the Council, I'd like to bring this pull request to the > attention > of the community: > > https://github.com/xsf/xeps/pull/963 Wait, is this PR actually modifying the authentication step it intends to change? I was assuming we're talking about XEP-0178, #3, step 7 (a), where the spec tells the receiving server to close the connection if initial certificate verification fails. The PR is instead changing step 11 (b), where the receiving server checks the new stream's 'from' against the certificate. Holger ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XEP-0178: Clarify SASL-EXTERNAL specification when s2s auth fails
Hello list On Tue, Jun 30, 2020 at 05:59:34PM +0200, Jonas Schäfer wrote: > https://github.com/xsf/xeps/pull/963 > > Input from server operators specifically would be welcomed to see if > this change is in fact desirable or if you can see any issues with > that. At least one member of the community has already expressed [1] > that they think this may lead to downgrade attacks. >[1]: https://mail.jabber.org/pipermail/standards/2020-June/037592.html (Prosody developer hat) TL;DR: It's probably fine, but I wish Dialback would go away. As mentioned in the PR, this reflects how current versions of ejabberd and prosody already behave (by default?). These two implementations account for a large part of the open XMPP federation. So, if this XEP is to describe current practice, then this PR is good. I do not think that it constitutes a downgrade attack, rather it becomes a local policy decision of whether to trust Dialback when faced with untrusted certificates. Dialback is still fairly hard to circumvent AFAIK. At least in Prosody, certificate validation strictness and Dialback are configurable. Falling back to Dialback might only be done if the remote server thinks your own certificate is insufficient, but you think theirs is fine. This does result in a number of different possible configurations. Not great for something security related. Personally I hope we might be able to phase out Dialback in the future. Today, largely thanks to Let's Encrypt, more and more servers have valid certificates. So, the Dialback code paths are more and more disused. My own server requires valid certificates and this is mosly an issue with certain XSF members (you know who you are). As a bonus, many unmaintained certificates with expired certificates that I am unable to establish s2s with appear to be sources of spam, which I am spared from. -- Kim "Zash" Alvefur signature.asc Description: PGP signature ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XEP-0178: Clarify SASL-EXTERNAL specification when s2s auth fails
Am Dienstag, den 30.06.2020, 19:27 +0200 schrieb Holger Weiß: > * Ruslan N. Marchenko [2020-06-30 18:58]: > > Now if EXTERNAL fails - that means there's something wrong with the > > certificates. And proposal to fail back to dialback means we want > > to > > tolerate certificate validation errors. Which is a downgrade. > > Whether or not this downgrade is acceptable is a policy > decision. The > proposed change to XEP-0178 allows for implementing either policy > decision in a sane way. No? > No, policy descision can be made without standard change - that's what happenning right now. Piggybacking the standard to reflect someone's _questionable_ policy decision is nor right thing to do. If someone cannot configure EXTERNAL auth - let's just not advertise it, after all it is negotiable. --rr ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XEP-0178: Clarify SASL-EXTERNAL specification when s2s auth fails
* Ruslan N. Marchenko [2020-06-30 18:58]: > Now if EXTERNAL fails - that means there's something wrong with the > certificates. And proposal to fail back to dialback means we want to > tolerate certificate validation errors. Which is a downgrade. Whether or not this downgrade is acceptable is a policy decision. The proposed change to XEP-0178 allows for implementing either policy decision in a sane way. No? Holger ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XEP-0178: Clarify SASL-EXTERNAL specification when s2s auth fails
Am Dienstag, den 30.06.2020, 17:59 +0200 schrieb Jonas Schäfer: > Hi list, > > (Editor hat on) > > On behalf of the Council, I’d like to bring this pull request to the > attention > of the community: > > https://github.com/xsf/xeps/pull/963 > > Input from server operators specifically would be welcomed to see if > this > change is in fact desirable or if you can see any issues with that. > At least > one member of the community has already expressed [1] that they think > this may > lead to downgrade attacks. > Let me rephrase/expand a bit my statement. The SASL EXTERNAL mandates use of TLS and certificate validation (XEP- 0220 does not). In theory you can achieve exactly the same level of security with Dialback as with EXTERNAL - eg. both sides still auth each others' certificates during dialback, and similarly one can put additional measures such as DANE + DNSEC. Now if EXTERNAL fails - that means there's something wrong with the certificates. And proposal to fail back to dialback means we want to tolerate certificate validation errors. Which is a downgrade. Now, if we want to loosen the failure scenario, we need to explicitly call out that this is only acceptable without loss of security controls (validation) - eg just a misconfiguration. Now again EXTERNAL misconfiguration is kind of obvious - connection is lost if integrity/confidentiality is not achievable. Dialback does not put anything like that in place to ensure that. Regards, Ruslan ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] XEP-0178: Clarify SASL-EXTERNAL specification when s2s auth fails
Hi list, (Editor hat on) On behalf of the Council, I’d like to bring this pull request to the attention of the community: https://github.com/xsf/xeps/pull/963 Input from server operators specifically would be welcomed to see if this change is in fact desirable or if you can see any issues with that. At least one member of the community has already expressed [1] that they think this may lead to downgrade attacks. kind regards and thank you, Jonas [1]: https://mail.jabber.org/pipermail/standards/2020-June/037592.html signature.asc Description: This is a digitally signed message part. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
