Re: [Standards] Proposed XMPP Extension: SASL SCRAM Downgrade Protection
On Wed, 19 Oct 2022 at 16:02, Thilo Molitor wrote: > Am Mittwoch, 19. Oktober 2022, 16:32:55 CEST schrieb Dave Cridland: > > Small point: GS2 doesn't ever allow clients to know if channel binding is > > proven, since the channel binding data is passed in the clear to the > > server. It does prove the server saw the channel binding data as sent by > > the client, but not whether the server can see the same channel. > > Surely the GS2 implementing server would abort authentication if the > channel- > binding data did not match it's own channel. right? That would be a sensible and conformant implementation, yes. But what I was meaning is that the client cannot prove that the server has done so. It's mostly an irrelevance, really - but when we're discussing what can and cannot be proven at either end, I think it's important to be accurate. Dave. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed XMPP Extension: SASL SCRAM Downgrade Protection
Am Mittwoch, 19. Oktober 2022, 16:32:55 CEST schrieb Dave Cridland: > Small point: GS2 doesn't ever allow clients to know if channel binding is > proven, since the channel binding data is passed in the clear to the > server. It does prove the server saw the channel binding data as sent by > the client, but not whether the server can see the same channel. Surely the GS2 implementing server would abort authentication if the channel- binding data did not match it's own channel. right? -tmolitor ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed XMPP Extension: SASL SCRAM Downgrade Protection
On Wed, 19 Oct 2022 at 14:59, Thilo Molitor wrote: > That's a wekness of SCRAM itself. Channel-binding problems will be > detected > after the client-final-message as well. > Small point: GS2 doesn't ever allow clients to know if channel binding is proven, since the channel binding data is passed in the clear to the server. It does prove the server saw the channel binding data as sent by the client, but not whether the server can see the same channel. Dave. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed XMPP Extension: SASL SCRAM Downgrade Protection
Hi Marvin, > I think the specification partially exaggerates on what it is able to > actually achieve security-wise. > > The requirements say: "Allow detection of SASL mechanism downgrades > even if no channel-binding is in use.". However, as this is an > extension to SCRAM, it only allows detection of SASL machanism > downgrades to SCRAM (as already mentioned). The detection only happens > after the client-final-message is sent to the server. This means that > if there was any attacke possible because of downgrading to some > version of SCRAM (and because of no channel-binding being used, the > SASL mechanism serves purely as mechanism of providing client > authentication information), this attack would already be possible with > the data in the client-final-message and thus the attack would not have > been prevented. Or in short: This does not provide a protection against > a downgrade of the SASL mechanism, it merely provides detection after > it is too late. That's a wekness of SCRAM itself. Channel-binding problems will be detected after the client-final-message as well. But detecting a downgrade may still be better than not detecting it at all. At least the user could be informed about the downgrade and change her password. That said, OPAQUE will not have this weakness and adding the same downgrade protection to OPAQUE would detect the downgrade before sending "credentials" to the server. My proposal furthermore protects the list of channel-binding types agains downgrades. See my mail to Daniel earlier today. > The requirement to "allow detection of downgrades of channel-binding > types" is fulfilled - under the assumption that the attacker was not > able to gain access to the credential database of the server or the > user's cleartext password. This means that as long as any of the user's > clients still uses or can be downgraded to use PLAIN, an attacker can > compromise all clients, including those that implement this > specification. Yes, PLAIN is evil and should only be used if it can not be avoided, I answered that already in another mail. > IMO, changing clients to not accept servers claiming to only support > channel-binding that is worse than what they supported previously is > probably better than this specification (and requires to changes to the > server). That way you won't be protected on your first connection. My proposal detects downgrades even on first connection. -tmolitor ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed XMPP Extension: SASL SCRAM Downgrade Protection
Hi Peter, > In any case, if the client has a local policy not to use PLAIN (or other > mechanisms that it considers to be too weak), then it simply wouldn't > use those in case of a downgrade attack. Similar policies are in place > already for things like old versions of TLS, see here: > https://datatracker.ietf.org/doc/html/draft-ietf-uta-rfc7525bis-11#section-3.2 Yes, but if you'll leave PLAIN aside, even different flavors of SCRAM have different protection levels. If, for example, SCRAM-SHA-1 is deemed broken one day, server operators most probably will still have to support it for some time, until all clients have upgraded their policy to not support SCRAM-SHA-1 anymore. Not to mention that some server operators may not be aware of this newly discovered SCRAM SHA-1 weakness at all. In this timeframe, an attacker could still downgrade the connection to SCRAM- SHA-1 even though this is insecure now. Policies are always a hard cut creating timeframes of opportunity for attackers. Having a downgrade-protection in place will close this timeframe of opportunity altogether. -tmolitor ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed XMPP Extension: SASL SCRAM Downgrade Protection
Hi Daniel, Am Mittwoch, 19. Oktober 2022, 09:23:10 CEST schrieb Daniel Gultsch: > > But that leaves clients not able to implement this type, or any > > channel-binding at all, vulnerable to downgrades of channel-binding types > > and SASL mechanisms. > This specification protects clients that are not able to support > channel binding from being tricked into thinking the server doesn’t > support channel binding either? That doesn’t make sense. No matter if > an attacker strips the channel binding announcement the client still > won’t support channel binding. No that "being tricked" part refers to a client supporting channel-binding, but none of the types the server announces. An attacker could use this to change the server-advertised channel-bindings to only list a fictional type like "BLURDYBLOOP-CB". That would downgrade the client to not use channel-binding at all, even if both, server and client supported, for example, tls-exporter. A client now has two options: lie to the server and tell it that it does not support channel-binding at all (that's a downgrade now), refrain to connect in that case, or try to use channel-binding nevertheless (but that's roulette, because the client has to guess which channel-binding to use and if the server supports tls-server-end-point, but not tls-exporter and the client uses tls- exporter, the authentication will fail and the client won't have any way to detect if it's because of the channel-binding type it used or because of something else like wrong credentials etc.) See the security considerations of XEP-0440: https://xmpp.org/extensions/ xep-0440.html#security -tmolitor ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed XMPP Extension: SASL SCRAM Downgrade Protection
> But that leaves clients not able to implement this type, or any > channel-binding at all, vulnerable to downgrades of channel-binding types and > SASL mechanisms. This specification protects clients that are not able to support channel binding from being tricked into thinking the server doesn’t support channel binding either? That doesn’t make sense. No matter if an attacker strips the channel binding announcement the client still won’t support channel binding. cheers Daniel ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed XMPP Extension: SASL SCRAM Downgrade Protection
I think the specification partially exaggerates on what it is able to actually achieve security-wise. The requirements say: "Allow detection of SASL mechanism downgrades even if no channel-binding is in use.". However, as this is an extension to SCRAM, it only allows detection of SASL machanism downgrades to SCRAM (as already mentioned). The detection only happens after the client-final-message is sent to the server. This means that if there was any attacke possible because of downgrading to some version of SCRAM (and because of no channel-binding being used, the SASL mechanism serves purely as mechanism of providing client authentication information), this attack would already be possible with the data in the client-final-message and thus the attack would not have been prevented. Or in short: This does not provide a protection against a downgrade of the SASL mechanism, it merely provides detection after it is too late. The requirement to "allow detection of downgrades of channel-binding types" is fulfilled - under the assumption that the attacker was not able to gain access to the credential database of the server or the user's cleartext password. This means that as long as any of the user's clients still uses or can be downgraded to use PLAIN, an attacker can compromise all clients, including those that implement this specification. IMO, changing clients to not accept servers claiming to only support channel-binding that is worse than what they supported previously is probably better than this specification (and requires to changes to the server). Marvin On Wed, 2022-10-12 at 16:13 +, Jonas Schäfer wrote: > The XMPP Extensions Editor has received a proposal for a new XEP. > > Title: SASL SCRAM Downgrade Protection > Abstract: > This specification provides a way to secure the SASL and SASL2 > handshakes against method and channel-binding downgrades. > > URL: https://xmpp.org/extensions/inbox/xep-downgrade-prevention.html > > The Council will decide in the next two weeks whether to accept this > proposal as an official XEP. > ___ > 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] Proposed XMPP Extension: SASL SCRAM Downgrade Protection
On 10/17/22 5:27 PM, Thilo Molitor wrote: Thanks for your feedback Dave! Am Montag, 17. Oktober 2022, 15:36:56 CEST schrieb Dave Cridland: Any attacker able to manipulate the data coming from the server such that the client sees a restricted set of TLS channel bindings can also manipulate the data coming from the server such that the client sees a restricted set of SASL mechanisms, removing SCRAM entirely. That's the reason why PLAIN is strongly discouraged. Of course you'll need mechanisms providing mutual authentication like SCRAM or the upcoming OPAQUE mechanism. Yes, this downgrade protection does not work for all scenarios. It's not perfect, but it's a step in the right direction and really simple to implement. It's even fully backwards compatible. Most public servers today support only SCRAM and PLAIN anyways. So encouraging them to disable PLAIN and adding this downgrade protection would be enough to secure all these servers against downgrade attacks. Moreover, if the client wants to use a stronger mechanism - let's say one of the OPAQUE mechanisms in development - then it loses this protection. Yes, sure, the same protection has to be defined for OPAQUE, too. That shouldn't be a problem: if I read the early draft of OPAQUE correctly, it provides support for optional attributes like SCRAM does (it even tries to use the same characters for mandatory attributes like SCRAM). In any case, if the client has a local policy not to use PLAIN (or other mechanisms that it considers to be too weak), then it simply wouldn't use those in case of a downgrade attack. Similar policies are in place already for things like old versions of TLS, see here: https://datatracker.ietf.org/doc/html/draft-ietf-uta-rfc7525bis-11#section-3.2 Either way, I'd like more/different eyes on this - I'd highly recommend taking this work to the IETF Kitten working group and seeing what they say. Sure, I even stated in the XEP that I plan to eventually make this an I-D. That said, I wanted to gain some implementation and operational experience before going the next step forward. Having this as an experimental XEP implemented in, for example, prosody or ejabberd and Monal/Conversations would allow us to gain exactly this experience. This XEP was never meant to advance to stable, but to remain experimental and be superseded by a proper RFC some day. IMHO it is fine to advance a XEP to Draft and then obsolete it when the proper RFC is published. We have done this before, e.g. XEP-0029. Peter ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed XMPP Extension: SASL SCRAM Downgrade Protection
Thanks for your feedback Dave! Am Montag, 17. Oktober 2022, 15:36:56 CEST schrieb Dave Cridland: > Any attacker able to manipulate the data coming from the server such that > the client sees a restricted set of TLS channel bindings can also > manipulate the data coming from the server such that the client sees a > restricted set of SASL mechanisms, removing SCRAM entirely. That's the reason why PLAIN is strongly discouraged. Of course you'll need mechanisms providing mutual authentication like SCRAM or the upcoming OPAQUE mechanism. Yes, this downgrade protection does not work for all scenarios. It's not perfect, but it's a step in the right direction and really simple to implement. It's even fully backwards compatible. Most public servers today support only SCRAM and PLAIN anyways. So encouraging them to disable PLAIN and adding this downgrade protection would be enough to secure all these servers against downgrade attacks. > Moreover, if the client wants to use a stronger mechanism - let's say one > of the OPAQUE mechanisms in development - then it loses this protection. Yes, sure, the same protection has to be defined for OPAQUE, too. That shouldn't be a problem: if I read the early draft of OPAQUE correctly, it provides support for optional attributes like SCRAM does (it even tries to use the same characters for mandatory attributes like SCRAM). > Either way, I'd like more/different eyes on this - I'd highly recommend > taking this work to the IETF Kitten working group and seeing what they say. Sure, I even stated in the XEP that I plan to eventually make this an I-D. That said, I wanted to gain some implementation and operational experience before going the next step forward. Having this as an experimental XEP implemented in, for example, prosody or ejabberd and Monal/Conversations would allow us to gain exactly this experience. This XEP was never meant to advance to stable, but to remain experimental and be superseded by a proper RFC some day. -tmolitor ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed XMPP Extension: SASL SCRAM Downgrade Protection
On Wed, 12 Oct 2022 at 17:17, Jonas Schäfer wrote: > Title: SASL SCRAM Downgrade Protection > URL: https://xmpp.org/extensions/inbox/xep-downgrade-prevention.html Any attacker able to manipulate the data coming from the server such that the client sees a restricted set of TLS channel bindings can also manipulate the data coming from the server such that the client sees a restricted set of SASL mechanisms, removing SCRAM entirely. Moreover, if the client wants to use a stronger mechanism - let's say one of the OPAQUE mechanisms in development - then it loses this protection. Either way, I'd like more/different eyes on this - I'd highly recommend taking this work to the IETF Kitten working group and seeing what they say. Dave. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed XMPP Extension: SASL SCRAM Downgrade Protection
I thought we had automatic pulls of the built images... apparently we don't, pulled manually, fixed, thanks for the hint. On Samstag, 15. Oktober 2022 16:34:20 CEST Dave Cridland wrote: > 404? > > On Wed, 12 Oct 2022 at 17:17, Jonas Schäfer wrote: > > The XMPP Extensions Editor has received a proposal for a new XEP. > > > > Title: SASL SCRAM Downgrade Protection > > Abstract: > > This specification provides a way to secure the SASL and SASL2 > > handshakes against method and channel-binding downgrades. > > > > URL: https://xmpp.org/extensions/inbox/xep-downgrade-prevention.html > > > > The Council will decide in the next two weeks whether to accept this > > proposal as an official XEP. > > ___ > > 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] Proposed XMPP Extension: SASL SCRAM Downgrade Protection
404? On Wed, 12 Oct 2022 at 17:17, Jonas Schäfer wrote: > The XMPP Extensions Editor has received a proposal for a new XEP. > > Title: SASL SCRAM Downgrade Protection > Abstract: > This specification provides a way to secure the SASL and SASL2 > handshakes against method and channel-binding downgrades. > > URL: https://xmpp.org/extensions/inbox/xep-downgrade-prevention.html > > The Council will decide in the next two weeks whether to accept this > proposal as an official XEP. > ___ > 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 ___
