XEP-xxxx: TLS Channel-Binding Downgrade Protection

1.1 Examples¶

While this attack doesn't depend on specific TLS versions, but can be executed with all current or future TLS versions for which the list of defined/implemented channel-binding types differes, here are two examples for TLS 1.2 and TLS 1.3.

If the MITM-attacker terminates the TLS connection to the client with TLS 1.3 and the TLS connection to the server with TLs 1.2, the server will advertise tls-uniqe channel-binding (alongside tls-server-end-point), but not tls-exporter. The client won't pick tls-unique, because it isn't defined for TLS 1.3 and fall back to the weaker tls-server-end-point.

If the MITM-attacker chooses to terminate the TLS connection to the client with TLS 1.2 and to the server with TLS 1.3, the server will advertise tls-exporter channel-binding (alongside tls-server-end-point), but not tls-unique. Even though tls-exporter can be securely used if the extended-master-secret extension TLS extension is used, most clients won't pick tls-exporter on TLS 1.2 connections and thus fall back to the weaker tls-server-end-point.

4.1 Server Sends TLS Version As Hex¶

The server encodes the TLS version number used by the connection as defined in RFC 8446 [7], RFC 5246 [8] and their predecessors as four lowercased hexadecimal numbers. For convenience the currently defined version numbers follow:

1. TLS 1.3 has the version number 0x0304, thus is encoded as '0304'
2. TLS 1.2 has the version number 0x0303, thus is encoded as '0303'
3. TLS 1.1 has the version number 0x0302, thus is encoded as '0302'
4. TLS 1.0 has the version number 0x0301, thus is encoded as '0301'

The server then adds the optional attribute "t" with the value of the four hexadecimal characters described above to its server-first-message.

4.2 Client Verifies The TLS Version Number¶

Upon receiving the server-first-message the client calculates the version number of its own TLS connection and encodes it as four lowercased hex-encoded characters as described in Server Sends TLS Version As Hex.

The client then extracts the TLS version number presented by the server in the optional attribute "t" and compares it to its own version number. If the hex-encoded version numbers match, the TLS version used by the server and client have not been altered by an active MITM.

If the version numbers do not match, the client MUST fail the authentication. It MAY additionally show a user-facing warning message about an active MITM. If the version numbers match, an attacker could still have manipulated them. If so, the server will always fail the authentication according to RFC 5802 [5] because the client-proof will not be based upon the correct TDP value.

4.3 Full Example¶

This sections contains an example based on the ones provided in Extensible SASL Profile (XEP-0388) [4].

<!--
  Client sending stream header
-->
<stream:stream
  from='user@example.org'
  to='example.org'
  version='1.0'
  xml:lang='en'
  xmlns='jabber:client'
  xmlns:stream='http://etherx.jabber.org/streams'>

<!--
  Server responding with stream header and features
-->
<stream:stream
  from='example.org'
  id='++TR84Sm6A3hnt3Q065SnAbbk3Y='
  to='user@example.org'
  version='1.0'
  xml:lang='en'
  xmlns='jabber:client'
  xmlns:stream='http://etherx.jabber.org/streams'>
<stream:features>
  <authentication xmlns='urn:xmpp:sasl:2'>
    <mechanism>SCRAM-SHA-1</mechanism>
    <mechanism>SCRAM-SHA-1-PLUS</mechanism>
    <inline xmlns='urn:xmpp:sasl:2'>
      <!-- Server indicates that XEP-0198 can be negotiated "inline" -->
      <enable xmlns='urn:xmpp:sm:3'/>
      <!-- Server indicates support for XEP-0386 Bind 2 -->
      <bind xmlns='urn:xmpp:bind2:1'/>
    </inline>
  </authentication>
  <!-- Channel-binding information provided by XEP-0440 -->
  <sasl-channel-binding xmlns='urn:xmpp:sasl-cb:0'>
    <channel-binding type='tls-server-end-point'/>
    <channel-binding type='tls-exporter'/>
  </sasl-channel-binding>
</stream:features>

<!--
  Client initiates authentication using SCRAM-SHA-1-PLUS and channel-binding type "tls-exporter"
-->
<authenticate xmlns='urn:xmpp:sasl:2' mechanism='SCRAM-SHA-1-PLUS'>
  <!-- Base64 of: 'p=tls-exporter,,n=user,r=12C4CD5C-E38E-4A98-8F6D-15C38F51CCC6' -->
  <initial-response>cD10bHMtZXhwb3J0ZXIsLG49dXNlcixyPTEyQzRDRDVDLUUzOEUtNEE5OC04RjZELTE1QzM4RjUxQ0NDNg==</initial-response>
  <user-agent id='d4565fa7-4d72-4749-b3d3-740edbf87770'>
    <software>AwesomeXMPP</software>
    <device>Kiva's Phone</device>
  </user-agent>
</authenticate>

<!--
  SCRAM-SHA-1-PLUS challenge issued by the server as defined in RFC 5802 including the hex-encoded TLS version and the hash defined in XEP-0474..
  Attribute "t" contains 0304 (TLS 1.3), attribute "h" contains the XEP-0474 hash.
  Base64 of: 'r=12C4CD5C-E38E-4A98-8F6D-15C38F51CCC6a09117a6-ac50-4f2f-93f1-93799c2bddf6,s=QSXCR+Q6sek8bf92,i=4096,h=G6k/rBLDqgOhRRaCuuatSDFkJ08=,t=0304'
-->
<challenge xmlns='urn:xmpp:sasl:2'>
  cj0xMkM0Q0Q1Qy1FMzhFLTRBOTgtOEY2RC0xNUMzOEY1MUNDQzZhMDkxMTdhNi1hYzUwLTRmMmYtOTNmMS05Mzc5OWMyYmRkZjYscz1RU1hDUitRNnNlazhiZjkyLGk9NDA5NixoPUc2ay9yQkxEcWdPaFJSYUN1dWF0U0RGa0owOD0sdD0wMzA0
</challenge>

<!--
  The client responds with the base64 encoded SCRAM-SHA-1-PLUS client-final-message (password: 'pencil')
  The c-attribute contains the GS2-header and channel-binding data blob as defined in RFC 5802.
  Base64 of: 'c=cD10bHMtZXhwb3J0ZXIsLFRISVMgSVMgRkFLRSBDQiBEQVRB,r=12C4CD5C-E38E-4A98-8F6D-15C38F51CCC6a09117a6-ac50-4f2f-93f1-93799c2bddf6,p=KHUfN8dSy1K95crT4D5y1ItLJfs='
-->
<response xmlns='urn:xmpp:sasl:2'>
  Yz1jRDEwYkhNdFpYaHdiM0owWlhJc0xGUklTVk1nU1ZNZ1JrRkxSU0JEUWlCRVFWUkIscj0xMkM0Q0Q1Qy1FMzhFLTRBOTgtOEY2RC0xNUMzOEY1MUNDQzZhMDkxMTdhNi1hYzUwLTRmMmYtOTNmMS05Mzc5OWMyYmRkZjYscD1LSFVmTjhkU3kxSzk1Y3JUNEQ1eTFJdExKZnM9
</response>

<!--
  The server accepted this authentication, no tampering with the advertised SASL mechanisms or channel-bindings was detected.
-->
<success xmlns='urn:xmpp:sasl:2'>
  <!-- Base64 of: 'v=3w34ZIMVRkx2f2Ozb3/ecRPVdv4=' -->
  <additional-data>
    dj0zdzM0WklNVlJreDJmMk96YjMvZWNSUFZkdjQ9
  </additional-data>
  <authorization-identifier>user@example.org</authorization-identifier>
</success>

Copyright

This XMPP Extension Protocol is copyright © 1999 – 2024 by the XMPP Standards Foundation (XSF).

Permissions

Permission is hereby granted, free of charge, to any person obtaining a copy of this specification (the "Specification"), to make use of the Specification without restriction, including without limitation the rights to implement the Specification in a software program, deploy the Specification in a network service, and copy, modify, merge, publish, translate, distribute, sublicense, or sell copies of the Specification, and to permit persons to whom the Specification is furnished to do so, subject to the condition that the foregoing copyright notice and this permission notice shall be included in all copies or substantial portions of the Specification. Unless separate permission is granted, modified works that are redistributed shall not contain misleading information regarding the authors, title, number, or publisher of the Specification, and shall not claim endorsement of the modified works by the authors, any organization or project to which the authors belong, or the XMPP Standards Foundation.

Disclaimer of Warranty

## NOTE WELL: This Specification is provided on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. ##

Limitation of Liability

In no event and under no legal theory, whether in tort (including negligence), contract, or otherwise, unless required by applicable law (such as deliberate and grossly negligent acts) or agreed to in writing, shall the XMPP Standards Foundation or any author of this Specification be liable for damages, including any direct, indirect, special, incidental, or consequential damages of any character arising from, out of, or in connection with the Specification or the implementation, deployment, or other use of the Specification (including but not limited to damages for loss of goodwill, work stoppage, computer failure or malfunction, or any and all other commercial damages or losses), even if the XMPP Standards Foundation or such author has been advised of the possibility of such damages.

IPR Conformance

This XMPP Extension Protocol has been contributed in full conformance with the XSF's Intellectual Property Rights Policy (a copy of which can be found at <https://xmpp.org/about/xsf/ipr-policy> or obtained by writing to XMPP Standards Foundation, P.O. Box 787, Parker, CO 80134 USA).

Visual Presentation

The HTML representation (you are looking at) is maintained by the XSF. It is based on the YAML CSS Framework, which is licensed under the terms of the CC-BY-SA 2.0 license.

1. XEP-0474: SASL SCRAM Downgrade Protection <https://xmpp.org/extensions/xep-0474.html>.

2. XEP-0440: SASL Channel-Binding Type Capability <https://xmpp.org/extensions/xep-0440.html>.

3. RFC 6120: Extensible Messaging and Presence Protocol (XMPP): Core <http://tools.ietf.org/html/rfc6120>.

4. XEP-0388: Extensible SASL Profile <https://xmpp.org/extensions/xep-0388.html>.

5. RFC 5802: Salted Challenge Response Authentication Mechanism (SCRAM) SASL and GSS-API Mechanisms <http://tools.ietf.org/html/rfc5802>.

6. RFC 7677: SCRAM-SHA-256 and SCRAM-SHA-256-PLUS Simple Authentication and Security Layer (SASL) Mechanisms <http://tools.ietf.org/html/rfc7677>.

7. RFC 8446: The Transport Layer Security (TLS) Protocol Version 1.3 <http://tools.ietf.org/html/rfc8446>.

8. RFC 5246: The Transport Layer Security (TLS) Protocol Version 1.2 <http://tools.ietf.org/html/rfc5246>.

9. The Internet Assigned Numbers Authority (IANA) is the central coordinator for the assignment of unique parameter values for Internet protocols, such as port numbers and URI schemes. For further information, see <http://www.iana.org/>.

10. The XMPP Registrar maintains a list of reserved protocol namespaces as well as registries of parameters used in the context of XMPP extension protocols approved by the XMPP Standards Foundation. For further information, see <https://xmpp.org/registrar/>.