[Standards] XEP-0388 SASL2 / ProtoXEP: #8 downgrade detection
This series of mails concluded that channel-binding together with SCRAM (or
OPAQUE) provides for the highest additional security beyond TLS.
But channel-binding can only be used, if a MITM isn't able to deactivate it
before it can detect the MITM.
The security considerations of XEP-0440 ( https://xmpp.org/extensions/
xep-0440.html#security ) show a scenario where a MITM is able to change the
server-announced list of supported channel-binding types to only include a
dummy type the client certainly does not support or to contain no channel-
bindings at all.
A client in this situation has two possible actions at hand:
1. Signal in it's SCRAM handshake, that it does support channel-binding, but
not the one the server advertised (use "y" for the channel-binding flag as
described in RFC 5802).
The server will fail authentication if it supports channel-binding.
That's bad UX if the problem only arose because no mutual channel-binding type
could be found rather than because a MITM occurred.
2. Signal in its SCRAM handshake that it does not support channel-binding at
all (use "n" for the channel-binding flag as described in RFC 5802).
That won't fail the authentication but leaves a possible MITM undetected.
XEP 0440 tries to mitigate this by suggesting to use pinning for the channel-
binding types. But that introduces other problems: A server operator deciding
to offload TLS termination to an extra box would not be able to offer "tls-
exporter" on his server anymore (only the weaker "tls-server-end-point").
Pinning will not allow this downgrade in security and fail the connection/
authentication.
I've written my ProtoXEP ("SASL SCRAM Downgrade Protection") to overcome
exactly this problem.
(Side note: Naming it "SASL SCRAM Downgrade Detection" would have been a
better choice.)
As long as PLAIN is not supported by the client (and not the only mechanism
announced by the server), this protocol can be used to detect downgrades on
the channel-binding types, even if channel-binding is not used, and fail the
authentication if a downgrade was detected.
Some clients can not support channel-binding (for example web-clients).
To allow some level of downgrade detection even for those type of clients,
I've added the list of announced SASL mechanisms as perceived by the client
alongside the list of channel-binding types as perceived by the client.
A downgrade from SCRAM-SHA-256 to, say, SCRAM-SHA-1 could be detected even
without channel-binding in place and may some day be valuable, if SCRAM-SHA-1
get broken.
Yes, that downgrade detection of SASL mechanisms is of limited use in case of
SCRAM, because the downgrade can only be detected after the client-final-
message was sent, which already contains the client proof based upon the
password. But that's a limitation of SCRAM itself, my downgrade detection
could be defined for OPAQUE as well and OPAQUE does not have this weakness that
SCRAM has. But the downgrade detection of SCRAM mechanisms could still be used
to inform the user that a password change could be helpful.
(For the record: that same limitation holds for channel-binding using SCRAM as
well: the mismatch in channel-binding data will only be detected by the server
after the client-final-message was sent.)
To make it clear: The main goal of my ProtoXEP is to protect the list of
channel-binding types, not the list of SASL mechanisms. But while I was at it,
I thought it was trivial to add at least some level of protection for the SASL
mechanisms as well.
An implementation of this ProtoXEP for Prosody and Monal already exists and
works well.
-tmolitor
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___
[Standards] XEP-0388 SASL2: #7 SASL PLAIN
Using the PLAIN mechanism will send the password in cleartext, only protected by TLS itself, the server will always see your cleartext password and channel- binding isn't supported by PLAIN, too. That's fine, if you deem TLS to be always secure and your server to never be evil or compromised. Yes, really, that's fine. But you'll loose another layer of security. Having multiple layers of security is always beneficial. RFC 6120 discourages the use of PLAIN in section 13.8.3. We merely added a pointer to this RFC into SASL2 to stress that more. That doesn't mean one couldn't still use PLAIN. It may well be that the deployment (LDAP etc.) makes it impossible to use something else than PLAIN. Let me stress that again: SASL2 does still allow that, even when pointing to RFC 6120 (which would already be normative on that subject, even without the additional pointer in SASL2). Why did we add the pointer nonetheless? Because supporting PLAIN, *even if the deployment doesn't warrant it*, weakens security. As soon as the client does support PLAIN, a MITM able to break into the TLS channel could downgrade the used SASL mechanism to plain by manipulating the server advertised mechanism list to only include PLAIN. Channel-binding would be a technique to detect such a MITM, but channel- binding is only possible with SCRAM (or OPAQUE), not when using PLAIN. In my opinion removing support for PLAIN in clients would be the best thing to do. But I see, that some deployments require the use of PLAIN. In a private discussion with Holger, we came up with a solution, that could help solving that deadlock using a compromise: Use a security profile in a well-known path on a webserver serving the same domain as the xmpp server, similar to the well-known path used for POSH (RFC 7711). This profile would tell the client, if the domain in question needs PLAIN turned on or off. The default in case such a profile is absent would be "on". (This could even eventually switched to "off" if all major clients support such a profile. But that's for another discussion in several years.) This security profile could even contain other security relevant settings our community comes up with. Maybe, just speculating, this profile could be also part of POSH. There is one other mitigation possible: SASL mechanism pinning. But while pinning is a valid approach it has some downsides, too. It does not cover the first connection and depends on ordering of mechanisms. If you upgrade the pinning to stronger mechanisms as soon as the server advertises them, you'll permanently break authentication for your client if the server operator just briefly activated these stronger mechanisms and deactivates them again (for various reasons). If, on the other hand, you don't upgrade your pinning as outlined above, your client will remain on a sort of security baseline that eventually will be outdated over the years and virtually be as good as no pinning at all. Pinning is the best solution we currently have at hand. In my opinion the proposed security profile above would be an even better solution worth writing a ProtoXEP for. And those solutions could be even combined. As for now, nothing in the SASL2 XEP does forbid to use PLAIN. All I wanted was to add awareness of the security implications of PLAIN (especially without pinning) and I think I've reached that goal. -tmolitor ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] XEP-0388 SASL2: #6 TLS
One topic not directly connected to SASL2, but to channel-binding and SCRAM in general, is the security of TLS. When discussing about whether PLAIN is a good choice or whether channel- binding has any benefit or even if SCRAM is needed, the underlying problem ist, that everyone has another view upon how secure TLS is. And that view influences the discussion about these topics. Let me sum up some of the properties SCRAM and channel-binding offer, before diving into the TLS stuff itself. Channel-binding: Channel-binding allows client and server to agree upon using the same TLS channel without a MITM between them. While the relatively weak "tls-server-end-point" channel-binding only makes sure the same certificate as used by the server is seen by the client, other channel-binding types like "tls-exporter" are really strong, coupling every newly established TLS channel to a unique random-looking value. SCRAM: Salted Challenge Response Authentication Mechanism allows mutual authentication for server and client (to be exact: SCRAM allows each party to proof that they know the password or a hash thereof). That allows for servers not storing the plaintext password, but a salted hash of it. It allows for clients doing the same, but that prevents them to use any other authentication method than exactly the SCRAM flavor the password was originally stored in. Most clients therefore use the (often hardware backed) keystore of their operating system to store the password securely. Yes Marvin, I consider the storage of password hashes on the user's devices of no practical relevance here. But the storage of those hashes on the server is. SCRAM uses nonces to make the SCRAM exchange replay-save. Even if an attacker records the whole SCRAM exchange he won't be able to use this data to authenticate himself (as long as the hashes SCRAM is based upon have not been broken). TLS: Yes, TLS 1.2 and 1.3 itself is secure (as of today), but the PKI is not. There are numerous shortcomings and I recommend reading Bruce Schneier's article over here: https://www.schneier.com/academic/archives/2000/01/ ten_risks_of_pki_wha.html Some of the issues mentioned therein are still valid today. - I have seen schools and companies demanding to install their CA into phones and computers to access the internet over wifi. These MITM boxes create new certificates on the fly while filtering internet access and frequently exhibit security holes. - Certificate Transparency doesn't work automatically: you'll have to monitor your domain yourself, to detect misissuance. That's something operators of small home-deployments most probably won't do. - Certificate Revocation Lists are frequently not checked at all (we don't even do OCSP stapling in our open source xmpp servers, mobile platforms even seem to not support OCSP stapling at all), stolen private keys can be used for the rest of the lifetime of a certificate (that could be up to a full year!) - People often click away certificate trust warnings - CAs still misissue certificates, despite certificate transparency - Bugs like Heartbleed allow stealing of private keys - Russia and other states are trying to lead people to install their CA: https://bugzilla.mozilla.org/show_bug.cgi?id=1758773 - many more Yes, the web platform solely relies upon TLS, but that does not mean that it's the holy grail of internet security. Even older TLS versions like TLS 1.0 or SSL 3 are deemed insecure today. If we can improve the security beyond simply using TLS, we should. More so if this does not have any negative side effects (like disabling PLAIN in every client would have on these deployments only supporting PLAIN). To me, supporting SCRAM (the whole family, not just SCRAM-SHA-1) and channel- binding is a valuable goal to strive for as a second layer of defence even when using TLS. Defense in depth is something that's important. It borrows people some time after one layer of defence is broken, but before all software (server and clients) could be upgraded. And yes, this defence in depth has to be established some time *before* another layer of our security gets broken, not afterwards. Journalists, activists and other people at risk of being MITMed benefit from this additional defense, too. -tmolitor ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] XEP-0388 SASL2: #5 protocol agility - channel-binding types
As with SASL mechanisms, today various different channel-binding types with varying strength can be used. SCRAM and the upcoming OPAQUE mechanism can use channel-binding to make sure the TLS channel is MITM-free (the "-PLUS" variants of SCRAM and OPAQUE). You'll need channel-binding to make sure an attacker that is able to break into the TLS channel can not downgrade the used SASL mechanism to something weak enough for him to break. All of this is nice, but the current XMPP protocol flow - as implemented in servers/clients today - lacks a way to negotiate which channel-binding should be used by the client or server. If both do support multiple but only partially overlapping mechanisms, the client has to guess which one is also supported by the server. That can lead to authentication failures if the client uses a binding, the server does not know. XMPP lacks a way to indicate that the failed authentication was due to wrong channel-binding type used nor should we add such an indication for various security reasons. Sequentially probing all channel-binding methods a client supports would significantly extend the time needed to log in, too, which could exhaust the limited background time available on mobile platforms as well as degrade UX. Luckily all of this was already solved by Florian Schmaus in XEP-0440: SASL Channel-Binding Type Capability. We therefore made XEP-0440 mandatory to implement, if channel-binding is implemented by the server/client at all. Without implementing channel-binding, XEP-0440 is not needed, of course. -tmolitor ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] XEP-0388 SASL2: #4 SASL2 tasks
Previously the SASL2 XEP used a base64 encoded challenge-response flow for it's tasks. That allows challenges and responses to be of arbitrary payload, but makes it difficult to encode information when defining SASL2 tasks for XMPP in future XEPs. One example we came across ourselves are the SCRAM upgrade tasks. For these upgrades the server needs to send the client the used salt as well as the iteration count to use. Encoding this into a base64 string would involve to either develop some arbitrary text-encoding (like "s=xxx,i=4096") or base64-encode XML. Both is not perfect and could be even more problematic for other SASL2 tasks. We therefore decided to use XML for SASL2 tasks. To make the protocol flow easier, I've pushed an update to the PR adding a wrapper-element to the SASL2 protocol flow for tasks: https://github.com/xsf/ xeps/pull/1214/commits/251800fabb9ac4fd095f9b04a04f062022c94dbe This element can contain any element defined in a future specification of the task in question. For SCRAM upgrades, the task is defined in this split-out ProtoXEP over here: https://github.com/tmolitor-stud-tu/xeps/commits/scram-upgrades (rendered version: https://dyn.eightysoft.de/final/xep-scram-upgrade.html ) For other tasks the SASL2 gives a fictional example using base64, too: https:// dyn.eightysoft.de/final/xep-0388.html#example-14 SASL2 tasks originally defined for another protocol (say SMTP) could now still use base64 while other tasks only defined for XMPP could use the richer and more readable XML variant. -tmolitor ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] XEP-0388 SASL2: #3 protocol agility - SASL mechanisms
This consists of various sub-parts. All of these assume, that the server does not store passwords in plaintext, but in hashed form of some sort (e.g. SCRAM, OPAQUE etc.). There are various reasons to not let servers store passwords in plaintext, if possible. Prosody, for example, stores it's password hashed by default: https://prosody.im/doc/plain_or_hashed The missing protocol agility was already mentioned on this very list, but no one presented a solution back then: https://mail.jabber.org/pipermail/ standards/2019-January/035720.html Let me stress that the upgrade mechanism defined in SASL2 can not only be used to upgrade between different mechanisms of the SCRAM family, but can be used to upgrade from SCRAM to OPAQUE (or something entirely new), too. 1. Mechanism Announcements SASL1 and the original SASL2 proposal provide no way of introducing new SASL mechanisms for server operators. If, for example, a server operator wants to introduce SCRAM-SHA-256 while previously only supporting SCRAM-SHA-1 (and therefore only having SCRAM-SHA-1 hashes stored on the server), he simply can't do that without causing damage: Globally announcing SCRAM-SHA-256 will make clients happily use it, even though the server still does not have the corresponding hashes and salts in its storage --> authentication will fail. SASL2 therefore contains a way to announce only authentication methods that can be used for a specific user account, not what is globally enabled. It does so by using the from-attribute of the stream-header already present in RFC 6120. That way we did not need to introduce another round-trip. Round-trip reduction is one of the goals of SASL2 and especially important for mobile devices. That does not come without a cost, though: attackers could use this information to determine which accounts are present on the server and maybe even fingerprint which software might be used. Because of this, we suggest multiple counter-measures in the Security Considerations of SASL2: https://dyn.eightysoft.de/final/xep-0388.html#security Namely randomizing the provided mechanisms for not-existing accounts and rate- limiting. Overall I think these security implications are not that big (especially with the suggested countermeasures in place): other parts of XMPP already allow for some sort of fingerprinting (querying OMEMO keys and other open PEP-nodes etc.). 2. Mechanism Upgrades Point 1 would be pretty limited if there was no way of upgrading the SASL mechanisms a server can offer for a specific account. An account registered when only SCRAM-SHA-1 was supported would otherwise virtually stay on SCRAM-SHA-1 forever (more precisely: until the user resets the password of this account). To overcome this limitation, we used the already existing SASL2 tasks to introduce a way for clients to upgrade the server to new SASL mechanisms. The server lists all mechanisms it could support, if it had the needed data in it's storage and the client picks one of these it supports, too, to send the server this needed data. The details depend on the used mechanism (SCRAM, OPAQUE etc.) and are defined in a new ProtoXEP for SCRAM (that's the split-out I announced lately: https://github.com/xsf/xeps/pull/1214/commits/ 251800fabb9ac4fd095f9b04a04f062022c94dbe ). This will make sure the server never sees the cleartext password, if we additionally update XEP-0389: Extensible In-Band Registration to send only hashes, too. This way even an evil or compromised server won't be able to extract your password and potentially use it for credential stuffing. Reducing the attack surface is always good and using hashes for mechanism upgrades rather than cleartext passwords provides for exactly this. -tmolitor ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] XEP-0388 SASL2: #2 Inline features
Again, MattJ already explained this well: https://mail.jabber.org/pipermail/ standards/2022-October/038998.html SASL2 allows for inlining additional elements into the authentication flow. That, like pipelining, reduces round-trip-times. To let clients distinguish, which features can be inlined into the SASL2 authentication flow and which features are supported by the server but can not be inlined, a new "namespace" for inlinable features is needed. As MattJ says: > It's important to stress that, despite calling out XEP-0198 and Bind 2 > in the changelog and text, this is intended for example purposes only. > There is no intention to increase the scope of XEP-0388 to cover which > specific protocols can be negotiated (in fact this is the whole reason > for introducing as an extension point). The Bind2 update already in our pipeline as well as the XEP-0198 update use that element as specified in our SASL2 update. In fact, Bind2 has it's own element, too. > The split is between things that are enabled before resource binding, > and those that are enabled after resource binding. You can see an > example here: https://matthewwild.co.uk/uploads/xeps-tmp/ xep-0386.html#example-1 -tmolitor ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] XEP-0388 SASL2: #1 client-identifier
I'm trying to rephrase and sum up here, what MattJ already said: https:// mail.jabber.org/pipermail/standards/2022-October/038998.html Stable client-identifier: This allows per-device tokens or even passwords. It allows to present users with a list of devices that currently have access to their account. Software and Device: The software and device information allows users to better identify their clients than just using the opaque client-identifier: "Conversations on Kiva's iPhone" is far more descriptive than "0ba15cd[...]". @MattJ: Add it, if I'm missing something here -tmolitor ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XEP-0388: SASL2 enhancements
Hi all, the SASL2 update consists of various parts. Mixing them doesn't help our discussion and I guess most people will loose track sooner or later. I will therefore start a new thread for every part, to discuss them separately. I also want to stress what MattJ already said: > New Bind 2 (and SASL2) is already implemented by at least Prosody, > Conversations and Monal. We learnt a lot from our collaboration > and testing, and have tweaked and improved various things along > the way as we discovered what did and didn't work well during > implementation. Overall, I'm pretty happy with what we have working. -tmolitor Am Donnerstag, 20. Oktober 2022, 13:49:50 CEST schrieb Marvin W: > Hi Thilo, > > On Wed, 2022-10-19 at 21:41 +0200, Thilo Molitor wrote: > > I want us to move away from that "PLAIN is sometimes needed, let's > > support > > it in all relevant clients without further interaction by the user > > and ignore > > any security implications this might have" stance that seems be > > common, to > > something like "only support PLAIN in clients after configured to do > > so, to not > > allow for trivial MITM attacks". > > That's essentially a "default secure" rather a "default insecure" > > approach. > > You make it sound as if PLAIN over TLS was anywhere near insecure. It's > not. It's what is protecting your emails, your online banking, your tax > declaration, ... (at least on first connection, some of these can store > a token for further use instead of the plain password). > > The main advantage of SCRAM is that clients don't need to store the > plain password, but can store the SaltedPassword instead. This is still > a valid credential, but it is restricted to the server (as each server > would have it's own salt), so if users reuse passwords (which they > shouldn't, but do anyways), it's not as much of an issue, if the XMPP > client is attacked, as only the XMPP account would be affected. > > Under certain extreme conditions it might be sensible to put some kind > of additional security to TLS, for example Signal is known to use > certificate pinning with their own CA. And for these special cases it's > worth having something like SCRAM with channel binding specified (and > both defaulting to it and pinning to it is somewhat sensible). > > But that doesn't mean we should frame PLAIN over TLS as insecure. It's > not. It also doesn't allow for trivial MITM attacks: If a public CA was > to issue certificates it shouldn't issue, it will get banned > immediately (and thanks to certificate transparency we will learn about > this close to immediately). And if a private CA was installed onto a > system, the attacker could have installed malware at the same time, > that would be able to fish the user's password and thereby break > SCRAM's channel binding. > > Given that there are always usecases where SCRAM cannot be used (RFC > already mentioned PAM and LDAP, but there are even further, basically > everything where credentials are not handled by the XMPP server itself) > > > I've split out the SCRAM upgrade task definition into a new ProtoXEP: > > https:// > > github.com/tmolitor-stud-tu/xeps/tree/scram-upgrades > > Rendered version: > > https://dyn.eightysoft.de/final/xep-scram-upgrade.html > > Just wanted to mention that this specification isn't really a "SCRAM > upgrade", but rather a "change salted password" specification (which > might be an interesting idea to have, but that's another story), > because the server has no way to verify that the salted password is the > same as the previous one when upgrading from SCRAM-SHA-1 to SCRAM-SHA- > 256. > > I also question the proposed upgrade mechanism in general. The server > can only suggest mechanisms independent of the user's account name. If > the server previously only stored SCRAM-SHA-1 secrets and some users > upgraded but others didn't, the list can't be used meaningfully. What > we'd need here is a new error code for the server to tell the client > after the message that the user can't use SCRAM-SHA-256 > yet, but will be able to do so after some upgrade operation being > performed (which probably entails sending the password in plain). > A client that is trying to do SCRAM-SHA-256 when the server doesn't > have matching credentials yet must have the plain password at hand > already (as it can't have the SaltedPassword yet due to lack of salt), > so it is already prepared to provide it. If channel binding is desired > for security reasons, one could also do a SCRAM-SHA-1-PLUS before > sending the password to the server in plain. > > Marvin > ___ > 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:
Re: [Standards] XEP-0388: SASL2 enhancements
Hi Marvin, > > I've split out the SCRAM upgrade task definition into a new ProtoXEP: > > https:// > > github.com/tmolitor-stud-tu/xeps/tree/scram-upgrades > > Rendered version: > > https://dyn.eightysoft.de/final/xep-scram-upgrade.html > > Just wanted to mention that this specification isn't really a "SCRAM > upgrade", but rather a "change salted password" specification (which > might be an interesting idea to have, but that's another story), > because the server has no way to verify that the salted password is the > same as the previous one when upgrading from SCRAM-SHA-1 to SCRAM-SHA- > 256. Well, if a client used different passwords to generate she SCRAM-SHA-256 hash than was used for the SCRAM-SHA-1, mere chaos would evolve. But you are right: we should add wording to XEP-0388 that the password used for the new hash MUST be the same as used to log in the client in the first place. > I also question the proposed upgrade mechanism in general. The server > can only suggest mechanisms independent of the user's account name. If > the server previously only stored SCRAM-SHA-1 secrets and some users > upgraded but others didn't, the list can't be used meaningfully. What > we'd need here is a new error code for the server to tell the client > after the message that the user can't use SCRAM-SHA-256 > yet, but will be able to do so after some upgrade operation being > performed (which probably entails sending the password in plain). > A client that is trying to do SCRAM-SHA-256 when the server doesn't > have matching credentials yet must have the plain password at hand > already (as it can't have the SaltedPassword yet due to lack of salt), > so it is already prepared to provide it. If channel binding is desired > for security reasons, one could also do a SCRAM-SHA-1-PLUS before > sending the password to the server in plain. You misunderstood the upgrade tasks: the server knows perfectly well which SASL mechanisms a specific account can be upgraded to and which mechanisms can already be used right away (the "from"-attribute of the stream header tells it which account the client wants to upgrade). Of course the server has to store all hashes independently (e.g. two database fields, one for SCRAM-SHA-1 and one for SCRAM-SHA-256). This wasn't outlined in the XEP because I figured details on the storage implementations of servers were out of scope for this XEP. But I could well add some wording that all hashes should be stored on the server, not only one of them. -tmolitor ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
