From 56f884bdf25809e0e133fcff5e1f4cbe12f9e2a1 Mon Sep 17 00:00:00 2001 From: Thilo Molitor Date: Sun, 2 Oct 2022 22:13:27 +0200 Subject: [PATCH] New ProtoXEP: SASL SCRAM Downgrade Protection --- inbox/xep-downgrade-prevention.xml | 179 +++++++++++++++++++++++++++++ 1 file changed, 179 insertions(+) create mode 100644 inbox/xep-downgrade-prevention.xml diff --git a/inbox/xep-downgrade-prevention.xml b/inbox/xep-downgrade-prevention.xml new file mode 100644 index 00000000..2c64f852 --- /dev/null +++ b/inbox/xep-downgrade-prevention.xml @@ -0,0 +1,179 @@ + + +%ents; +]> + + +
+ SASL SCRAM Downgrade Protection + This specification provides a way to secure the SASL and SASL2 handshakes against method and channel-binding downgrades. + &LEGALNOTICE; + xxxx + ProtoXEP + Standards Track + Standards + Council + + XMPP Core + RFC 5802 + XEP-0388 + + + + SSDP + &tmolitor; + + 0.0.1 + 2022-10-11 + tm + Initial version. + +
+ +

&rfc6120; and &xep0388; define a way to negotiate SASL mechanisms. When used together with SCRAM mechanisms (&rfc5802;) and channel-binding (&xep0440;) the mechanism selection is protected against downgrade attacks by an active MITM tampering with the TLS channel and advertised SASL mechanisms, while the negotiation of the channel-binding types is still not protected against such downgrade attacks.

+

&xep0440; tries to mitigate this by making the "tls-server-end-point" (&rfc5929;) channel-binding mandatory to implement for servers. 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. Furthermore "tls-server-end-point" provides weaker security guarantees than other channel-bindings like for example "tls-exporter" (defined in &rfc5705; and &rfc9266;).

+

This specification aims to solve this issue by spcifying a downgrade protection for both SASL mechanisms and channel-binding types using an optional SCRAM attribute (see &rfc5802;). This specification can be used for SASL1 (&rfc6120;) and SASL2 (&xep0388;) profiles as well as any other SASL profile.

+

Note: In the long term the author strives to publish this as an RFC rather than a XEP to also make this protection available to other protocols, after gaining implementation experience.

+ + +

This protocol was designed with the following requirements in mind:

+
    +
  • Allow detection of SASL mechanism downgrades even if no channel-binding is in use.
    • +
  • Allow detection of downgrades of channel-binding types.
    • +
  • Support all currently defined and future SCRAM mechanisms (&rfc5802; and &rfc7677;)
    • +
+

Note that this specification intentionally leaves out support for SASL PLAIN. If server and client support PLAIN, no protection against SASL method or channel-binding downgrades is possible and the security relies solely on the underlying TLS channel. As explained in ยง 13.8.3 of &rfc6120;, servers and clients SHOULD NOT support SASL PLAIN unless it is required by the authentication backend.

+ + +

This specification uses some abbreviations:

+
    +
  • SASL1: the XMPP SASL profile specified in &rfc6120;
    • +
  • SASL2: the XMPP SASL profile specified in &xep0388;
    • +
+ + +

Sections 5.1 and 7 of &rfc5802; allow for arbitrary optional attributes inside SCRAM messages. This specification uses those optional attribute to implement a downgrade protection.

+ +

The server uses the optional attribute "d" with the value "ssdp" in its server-first-message to indicate support for this specification.

+

A client supporting this specification but not seeing this attribute advertised by the server MAY abort the authentication. It is RECOMMENDED to wait until the whole SCRAM flow hash been completed to distinguish the case of a server not supporting this specification from a MITM stripping out this optional SCRAM attribute.

+ + +

If the server indicated support for this spec in the server-first-message and the client supports it, the client calculates a hash for the server-advertised list of SASL mechanisms and channel-binding types as follows.

+

Note: All sorting operations MUST be performed using "i;octet" collation as specified in Section 9.3 of &rfc4790;.

+
    +
  1. Initialize an empty ASCII string S
    2. +
  2. Sort all server-advertised SASL mechanisms and append them to string S joined by delimiter "," (%x2C)
    3. +
  3. If the server used &xep0440; to advertise channel-bindings, append "|" (%x7C) to S
    4. +
  4. If the server used &xep0440; to advertise channel-bindings, sort all server-advertised channel-binding types and append them to string S joined by delimiter "," (%x2C)
    5. +
  5. Hash S using the same hash mechanism as used for the SCRAM mechanism currently in use and encode the result using base64
    6. +
+

The client then adds the optional attribute "d" with the base64 encoded hash obtained in step 5 to its client-final-message. The client MAY send this attribute even if the server did not advertise support.

+

Note: If the server simultaneously advertises SASL1 and SASL2, only the mechanism list of the SASL protocol the client uses for authentication MUST be considered for hashing.

+ + +

Upon receiving the client-final-message the server calculates its own base64 encoded hash using the list of SASL mechanisms and channel-binding types it advertised using SASL1 or SASL2 and &xep0440; by applying the same algorithm as defined in Client Sends Downgrade Protection Hash.

+

The server then extracts the base64 encoded hash presented by the client in the optional attribute "d" and compares it to its own hash. If the hashes match, the list of SASL mechanisms and channel-binding types has not been changed by an active MITM.

+

If the hashes do not match, the server MUST fail the authentication as specified in &rfc6120; section 6.5 or &xep0388; section 2.6.2 using the "aborted" error-condition. If &xep0388; is used, the application-specific error-condition "downgrade-detected" in the namespace "urn:xmpp:ssdp:0" MUST be added, too. It MAY further include an optional descriptive text to further clarify this error as specified in &xep0388; section 6.2.6 or &rfc6120; section 6.5. If additional SCRAM data is provided, the used SCRAM "server-error-value" MUST be "downgrade-detected".

+

Non-XMPP implementations MAY use a SCRAM "server-error-value" of "downgrade-detected" alongside any protocol specific error-condition.

+ + +

This sections contains an example based on the ones provided in &xep0388;.

+ + + + + + + + SCRAM-SHA-1 + SCRAM-SHA-1-PLUS + + + + + + + + + + + + + + + + + + cD10bHMtZXhwb3J0ZXIsLG49dXNlcixyPTEyQzRDRDVDLUUzOEUtNEE5OC04RjZELTE1QzM4RjUxQ0NDNg== + + AwesomeXMPP + Kiva's Phone + + + + + + cj0xMkM0Q0Q1Qy1FMzhFLTRBOTgtOEY2RC0xNUMzOEY1MUNDQzZhMDkxMTdhNi1hYzUwLTRmMmYtOTNmMS05Mzc5OWMyYmRkZjYscz1RU1hDUitRNnNlazhiZjkyLGk9NDA5NixkPXNzZHA= + + + + + Yz1jRDEwYkhNdFpYaHdiM0owWlhJc0xNY29Rdk9kQkRlUGQ0T3N3bG1BV1YzZGcxYTFXaDF0WVBUQndWaWQxMFZVLHI9MTJDNENENUMtRTM4RS00QTk4LThGNkQtMTVDMzhGNTFDQ0M2YTA5MTE3YTYtYWM1MC00ZjJmLTkzZjEtOTM3OTljMmJkZGY2LHA9VUFwbzd4bzZQYTlKK1ZhZWpmei9kRzdCb21VPSxkPWRSYzNSZW51U1k5eXBnUHBFUm93b2F5U1FaWT0= + + + + + + + dj1zUXE4QTFkZVBMNUR4V1gyMlN6NFRKTUQ3dDQ9 + + user@example.org +]]> + + + +

Using SCRAM attributes makes them part of the HMAC signatures used in the SCRAM protocol flow efficiently protecting them against any MITM attacker not knowing the password used.

+ + +

This document requires no interaction with &IANA;.

+ + +

This specification does not need any interaction with the ®ISTRAR;.

+ + +

This specification does not specify any new XML elements.

+ + \ No newline at end of file