The Hashed Token SASL Mechanism
draft-ietf-kitten-sasl-ht-02

Common Authentication Technology Next Generation (kitten)     F. Schmaus
Internet-Draft         Friedrich-Alexander-Universität Erlangen-Nürnberg
Intended status: Standards Track                              T. Molitor
Expires: 24 December 2026                        Monal Instant Messenger
                                                                C. Egger
                                       Chalmers University of Technology
                                                            22 June 2026

                    The Hashed Token SASL Mechanism
                      draft-ietf-kitten-sasl-ht-02

Abstract

   This document specifies the family of Hashed Token SASL mechanisms,
   which enable a proof-of-possession-based authentication scheme and
   are meant to quickly re-authenticate a previous session.  The Hashed
   Token SASL mechanism's authentication sequence consists of only one
   round-trip.  The usage of short-lived, exclusively ephemeral hashed
   tokens is achieving the single round-trip property.  The SASL
   mechanism specified herein further provides hash agility, mutual
   authentication, support for channel binding, and the capability to
   exchange authenticated key/value pairs.

About This Document

   This note is to be removed before publishing as an RFC.

   Status information for this document may be found at
   https://datatracker.ietf.org/doc/draft-ietf-kitten-sasl-ht/.

   Source for this draft and an issue tracker can be found at
   https://github.com/flowdalic/xeps/tree/master/draft-ietf-kitten-sasl-
   ht.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

Schmaus, et al.         Expires 24 December 2026                [Page 1]
Internet-Draft       The Hashed Token SASL Mechanism           June 2026

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 24 December 2026.

Copyright Notice

   Copyright (c) 2026 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  Conventions and Terminology . . . . . . . . . . . . . . .   4
     1.2.  Applicability . . . . . . . . . . . . . . . . . . . . . .   4
   2.  The HT Family of Mechanisms . . . . . . . . . . . . . . . . .   4
   3.  The HT Authentication Exchange  . . . . . . . . . . . . . . .   5
     3.1.  Initiator First Message . . . . . . . . . . . . . . . . .   6
     3.2.  Initiator Authentication  . . . . . . . . . . . . . . . .   7
     3.3.  Final Responder Message . . . . . . . . . . . . . . . . .   7
       3.3.1.  Success Response  . . . . . . . . . . . . . . . . . .   8
       3.3.2.  Failure Response  . . . . . . . . . . . . . . . . . .   8
   4.  Compliance with SASL Mechanism Requirements . . . . . . . . .   9
   5.  Requirements for the Application-Protocol Extension . . . . .   9
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  10
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  10
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .  10
     8.2.  Informative References  . . . . . . . . . . . . . . . . .  12
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  13
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  13

Schmaus, et al.         Expires 24 December 2026                [Page 2]
Internet-Draft       The Hashed Token SASL Mechanism           June 2026

1.  Introduction

   This specification describes the family of Hashed Token (HT) Simple
   Authentication and Security Layer (SASL) [RFC4422] mechanisms, which
   enable a proof-of-possession-based authentication scheme.  The HT
   mechanism is designed to be used with short-lived, exclusively
   ephemeral tokens, called SASL-HT tokens, and allow for quick, one
   round-trip re-authentication of a previous session.

   Further properties of the HT mechanism are 1) hash agility, 2) mutual
   authentication, 3) support for channel binding, and 4) the optional
   exchange of authenticated key/value pairs.

   The ability to include arbitrary key/value pairs allows the initiator
   and responder to negotiate session parameters or exchange context-
   specific data concurrently with the authentication exchange, with
   cryptographic guarantees regarding their integrity and authenticity.
   An example use case for these key/value pairs is transmitting a
   downgrade protection hash of the initially offered SASL mechanisms
   and channel-binding types (see [XEP-0474]).

   Clients should request SASL-HT tokens from the server after being
   authenticated using a "strong" SASL mechanism like SCRAM [RFC5802].
   Hence a typical sequence of actions using HT may look like the
   following:

   A) Client authenticates using a strong mechanism (e.g., SCRAM)
   B) Client requests secret SASL-HT token
   C) Service returns SASL-HT token
      <normal client-server interaction here>
   D) Connection between client and server gets interrupted,
      for example because of a WiFi ↔ GSM switch
   E) Client resumes the previous session using HT and token from C)
   F) Service revokes the successfully used SASL-HT token
      [goto B]

   The HT mechanism requires an accompanying, application-protocol-
   specific extension, which allows clients to request a new SASL-HT
   token (see Section 5 (Section 5)).  Examples of such an application-
   protocol-specific extension based on HT are [XEP-0397] and
   [XEP-0484].

   Since the SASL-HT token is not salted, and only one hash iteration is
   used, the HT mechanism is not suitable to protect long-lived shared
   secrets (e.g., "passwords").  You may want to look at [RFC5802] for
   that.

Schmaus, et al.         Expires 24 December 2026                [Page 3]
Internet-Draft       The Hashed Token SASL Mechanism           June 2026

1.1.  Conventions and Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in
   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.  These words may also appear in this
   document in lower case as plain English words, absent their normative
   meanings.

1.2.  Applicability

   Because this mechanism transports information that an attacker should
   not control, the HT mechanism *MUST* only be used over channels
   protected by Transport Layer Security (TLS, see [RFC8446]) or over
   similar integrity-protected and authenticated channels.  Also, the
   application-protocol-specific extension that requests a new SASL-HT
   token *SHOULD* only be used over similarly protected channels.

   The family of HT mechanisms is not applicable for proxy
   authentication since they cannot carry an authorization identity
   string (authzid).

2.  The HT Family of Mechanisms

   Each mechanism in this family differs by choice of the hash algorithm
   and the selection of the channel binding [RFC5929] type.

   An HT mechanism name is a string beginning with "HT2-" followed by
   the capitalized name of the used hash, followed by "-", and suffixed
   by one of 'ENDP', 'UNIQ', 'EXPR' or 'NONE'.

   Hence, each HT mechanism has a name of the following form:

   HT2-<hash-alg>-<cb-type>

   Where <hash-alg> is the capitalized "Hash Name String" of the IANA
   "Named Information Hash Algorithm Registry" [iana-hash-alg] as
   specified in [RFC6920], and <cb-type> is one of 'ENDP', 'UNIQ',
   'EXPR' or 'NONE' denoting the channel binding type.  In the case of
   'ENDP', the tls-server-end-point channel binding type is used.  In
   the case of 'UNIQ', the tls-unique channel binding type is used.  In
   the case of 'EXPR', the tls-exporter [RFC9266] channel binding type
   is used.  Valid channel binding types are defined in the IANA
   "Channel-Binding Types" registry [iana-cbt] as specified in
   [RFC5056].

Schmaus, et al.         Expires 24 December 2026                [Page 4]
Internet-Draft       The Hashed Token SASL Mechanism           June 2026

   In the special case of 'NONE' no channel binding will be used.  In
   this case, cb-data is to be an empty string.

                    +=========+======================+
                    | cb-type | Channel Binding Type |
                    +=========+======================+
                    | ENDP    | tls-server-end-point |
                    +---------+----------------------+
                    | UNIQ    | tls-unique           |
                    +---------+----------------------+
                    | EXPR    | tls-exporter         |
                    +---------+----------------------+
                    | NONE    | _No_ Channel Binding |
                    +---------+----------------------+

                      Table 1: Mapping of cb-type to
                          Channel Binding Types

   The following table lists some examples of HT SASL mechanisms
   registered by this document.

     +===================+===================+======================+
     | Mechanism Name    | HT Hash Algorithm | Channel-binding      |
     |                   |                   | unique prefix        |
     +===================+===================+======================+
     | HT2-SHA-512-ENDP  | SHA-512           | tls-server-end-point |
     +-------------------+-------------------+----------------------+
     | HT2-SHA-512-UNIQ  | SHA-512           | tls-unique           |
     +-------------------+-------------------+----------------------+
     | HT2-SHA3-512-ENDP | SHA3-512          | tls-server-end-point |
     +-------------------+-------------------+----------------------+
     | HT2-SHA-256-UNIQ  | SHA-256           | tls-unique           |
     +-------------------+-------------------+----------------------+
     | HT2-SHA-256-NONE  | SHA-256           | N/A                  |
     +-------------------+-------------------+----------------------+

                 Table 2: Examples of HT SASL mechanisms

3.  The HT Authentication Exchange

   The mechanism consists of a simple exchange of precisely two messages
   between the initiator and responder.  Both messages allow the
   inclusion of arbitrary key/value pairs.

   The following syntax specifications use the Augmented Backus-Naur
   form (ABNF) notation as specified in [RFC5234].

Schmaus, et al.         Expires 24 December 2026                [Page 5]
Internet-Draft       The Hashed Token SASL Mechanism           June 2026

3.1.  Initiator First Message

   The HT mechanism starts with the initiator-msg, which is sent by the
   initiator to the responder.  The following lists the ABNF grammar for
   SASL-HT in general and initiator-msg in particular:

   initiator-msg          = authcid
                            NUL extra-initiator-values
                            NUL initiator-hashed-token
   authcid                = 1*255SAFE ;; MUST accept up to 255 octets
   extra-initiator-values = key-value-pairs
   key-value-pairs        = [ key-value-pair *( "," key-value-pair ) ]
   key-value-pair         = 1*key-value-char "=" 1*key-value-char
   initiator-hashed-token = 1*OCTET

   key-value-char     = ALPHA / DIGIT / "/" / "+" / "-" / "_"

   NUL    = %0x00 ;; The null octet
   SAFE   = UTF1 / UTF2 / UTF3 / UTF4
            ;; any UTF-8 encoded Unicode character except NUL

   UTF1   = %x01-7F ;; except NUL
   UTF2   = %xC2-DF UTF0
   UTF3   = %xE0 %xA0-BF UTF0 / %xE1-EC 2(UTF0) /
            %xED %x80-9F UTF0 / %xEE-EF 2(UTF0)
   UTF4   = %xF0 %x90-BF 2(UTF0) / %xF1-F3 3(UTF0) /
            %xF4 %x80-8F 2(UTF0)
   UTF0   = %x80-BF

   The initiator's first message starts with the authentication identity
   (authcid, see[RFC4422]) as UTF-8 [RFC3629] encoded string and its
   terminating null octet followed by an optional set of comma-separated
   key/value pairs (extra-initiator-values).  This, in turn, is followed
   by another null octet and the initiator-hashed-token.

   The extra-initiator-values allow the initiator to pass arbitrary key/
   value pairs to the responder during the initial exchange.  Because
   these key/value pairs are appended to the initiator-hmac-message
   before the HMAC calculation, their integrity and authenticity are
   guaranteed by the resulting initiator-hashed-token.  If no extra
   values are being sent, the extra-initiator-values field remains
   empty, resulting in two consecutive null octets between the authcid
   and the initiator-hashed-token.

   The value of the initiator-hashed-token is defined as follows:

Schmaus, et al.         Expires 24 December 2026                [Page 6]
Internet-Draft       The Hashed Token SASL Mechanism           June 2026

   initiator-hashed-token := HMAC(token, initiator-hmac-message)
   initiator-hmac-message := "Initiator"
                             || cb-data
                             || extra-initiator-values

   HMAC() is the function defined in [RFC2104] with H being the selected
   HT hash algorithm, 'cb-data' represents the data provided by the
   selected channel binding type, and 'token' are the UTF-8 encoded
   octets of the SASL-HT token string, which acts as a shared secret
   between initiator and responder.

   The initiator-msg *MAY* be included in TLS 1.3 0-RTT early data, as
   specified in [RFC8446].  If this is the case, then the initiating
   entity *MUST NOT* contain any further application protocol payload in
   the early data besides the HT initiator-msg and potentially required
   framing of the SASL profile.  The responder *MUST* abort the SASL
   authentication if the early data contains an additional application-
   protocol payload.

      SASL-HT allows exploiting TLS 1.3 early data for "0.5 Round Trip
      Time (RTT)" re-authentication of the application protocol's
      session.  Using TLS early data requires extra care when
      implementing: The early data should only contain the SASL-HT
      payload, i.e., the initiator-msg, and not an application-protocol-
      specific payload.  The reason for this is that another entity
      could replay the early data.  Therefore, the early data needs must
      represent an idempotent operation.  On the other hand, if the
      responding entity can verify the early data, it can send an
      additional application-protocol-specific payload together with the
      "re-authentication successful" response to the initiating entity.

3.2.  Initiator Authentication

   Upon receiving the initiator-msg, the responder calculates the value
   of initiator-hashed-token and compares it with the received value
   found in the initiator-msg.  If both values are equal, then the
   initiator has been successfully authenticated.  Otherwise, if both
   values are not equal, then authentication *MUST* fail.

3.3.  Final Responder Message

   After the responder authenticated the initiator, the responder
   continues the SASL authentication by sending the responder-msg to the
   initiator.

   The ABNF for responder-msg is:

Schmaus, et al.         Expires 24 December 2026                [Page 7]
Internet-Draft       The Hashed Token SASL Mechanism           June 2026

   responder-msg          = success-response / failure-response
   success-response       = NUL extra-responder-values
                            NUL responder-hashed-token
   extra-responder-values = key-value-pairs
   responder-hashed-token = 1*OCTET
   failure-response       = %x01 failure-description

3.3.1.  Success Response

   A success response starts with an octet whose value is set to zero
   (null), followed by an optional set of comma-separated key/value
   pairs (extra-responder-values).  This is followed by another null
   octet and the octet string of the result of the HMAC function
   (responder-hashed-token).

   responder-hashed-token := HMAC(token, responder-hmac-message)
   responder-hmac-message := "Responder"
                             || cb-data
                             || extra-responder-values

   Similar to the initiator's message, the responder can use extra-
   responder-values to return arbitrary data.  Because these values are
   incorporated into the responder-hmac-message prior to calculating the
   HMAC, the initiating entity can mutually authenticate the responder
   while simultaneously verifying the integrity of the provided key/
   value pairs.

   The initiating entity *MUST* verify the responder-msg to achieve
   mutual authentication.

3.3.2.  Failure Response

   A failure response starts with an octet whose value is set to one
   (0x01), followed by an octet string describing the reason for the
   failure (failure-description).

   failure-description     = "unknown-user" /
                             "invalid-token" /
                             "other-error"/
                             failure-description-ext
   failure-description-ext = 1*SAFE ;; additional custom failure reasons

   Unrecognized failure descriptions should be treated as "other-error".
   The responder may substitute the actual failure cause with "other-
   error" to prevent information disclosure.

Schmaus, et al.         Expires 24 December 2026                [Page 8]
Internet-Draft       The Hashed Token SASL Mechanism           June 2026

4.  Compliance with SASL Mechanism Requirements

   This section describes compliance with SASL mechanism requirements
   specified in Section 5 of [RFC4422].

   1.  "HT2-SHA-256-ENDP", "HT2-SHA-256-UNIQ", "HT2-SHA3-512-ENDP",
       "HT2-SHA3-512-UNIQ", ….

   2.  Definition of server-challenges and client-responses: a) HT is a
       client-first mechanism. b) HT does send additional data with
       success (the responder-msg).

   3.  HT is not capable of transferring authorization identities from
       the client to the server.

   4.  HT does not offer any security layers (HT offers channel binding
       instead).

   5.  HT does not protect the authorization identity.

5.  Requirements for the Application-Protocol Extension

   It is *REQUIRED* that the application-protocol-specific extension
   provides a mechanism to request a SASL-HT token in the form of a
   Unicode string.  The returned token *MUST* have been newly generated
   by a cryptographically secure random number generator, and it MUST
   contain at least 128 bits of entropy.

   It is *RECOMMENDED* that the protocol allows the requestor to signal
   the name of the SASL mechanism that the requestor intends to use with
   the token.  If a token is used with a mechanism different from the
   one signaled upon requesting the token, then the authentication
   *MUST* fail.  This requirement allows pinning the token to a SASL
   mechanism, which increases the security because it makes it
   impossible for an attacker to downgrade the SASL mechanism.

   It is *RECOMMENDED* that the protocol defines a way for a client to
   request rotation or revocation of a token.

6.  Security Considerations

   The HT mechanism *MUST* be used over a TLS channel that has the
   session hash extension [RFC7627] negotiated.

   It is *RECOMMENDED* that implementations periodically require a full
   authentication using a strong SASL mechanism that does not use the
   SASL-HT token.

Schmaus, et al.         Expires 24 December 2026                [Page 9]
Internet-Draft       The Hashed Token SASL Mechanism           June 2026

   A cryptographically secure random generator must generate the SASL-HT
   token.  See [RFC4086] for more information about Randomness
   Requirements for Security.  In addition, a comparison of the
   initiator's HMAC with the responder's calculated HMAC *SHOULD* be
   performed via constant-time comparison functions to protect against
   timing attacks.

   The tokens used with HT mechanisms *SHOULD* have a limited lifetime,
   e.g., based on usage count or time elapsed since issuance.

   Due to the additional security properties afforded by channel
   binding, it is *RECOMMENDED* that clients use HT mechanisms with
   channel binding whenever possible.

7.  IANA Considerations

   IANA is requested to add the following family of SASL mechanisms to
   the SASL Mechanism registry established by [RFC4422]:

      To: iana@iana.org

      Subject: Registration of a new SASL family HT

      SASL mechanism name (or prefix for the family): HT2-*

      Security considerations: Section 6 of draft-ietf-kitten-sasl-ht

      Published specification (optional, recommended): draft-ietf-
      kitten-sasl-ht-XX (TODO)

      Person & email address to contact for further information: IETF
      SASL WG kitten@ietf.org (mailto:kitten@ietf.org)

      Intended usage: COMMON

      Owner/Change controller: IESG iesg@ietf.org (mailto:iesg@ietf.org)

      Note: Members of this family MUST be explicitly registered using
      the "IETF Review" [RFC8126] registration procedure.  Reviews MUST
      be requested on the Kitten WG mailing list kitten@ietf.org
      (mailto:kitten@ietf.org) (or a successor designated by the
      responsible Security AD).

8.  References

8.1.  Normative References

Schmaus, et al.         Expires 24 December 2026               [Page 10]
Internet-Draft       The Hashed Token SASL Mechanism           June 2026

   [RFC2104]  Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
              Hashing for Message Authentication", RFC 2104,
              DOI 10.17487/RFC2104, February 1997,
              <https://www.rfc-editor.org/info/rfc2104>.

   [RFC3629]  Yergeau, F., "UTF-8, a transformation format of ISO
              10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November
              2003, <https://www.rfc-editor.org/info/rfc3629>.

   [RFC4086]  Eastlake 3rd, D., Schiller, J., and S. Crocker,
              "Randomness Requirements for Security", BCP 106, RFC 4086,
              DOI 10.17487/RFC4086, June 2005,
              <https://www.rfc-editor.org/info/rfc4086>.

   [RFC4422]  Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple
              Authentication and Security Layer (SASL)", RFC 4422,
              DOI 10.17487/RFC4422, June 2006,
              <https://www.rfc-editor.org/info/rfc4422>.

   [RFC5056]  Williams, N., "On the Use of Channel Bindings to Secure
              Channels", RFC 5056, DOI 10.17487/RFC5056, November 2007,
              <https://www.rfc-editor.org/info/rfc5056>.

   [RFC5234]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", STD 68, RFC 5234,
              DOI 10.17487/RFC5234, January 2008,
              <https://www.rfc-editor.org/info/rfc5234>.

   [RFC5929]  Altman, J., Williams, N., and L. Zhu, "Channel Bindings
              for TLS", RFC 5929, DOI 10.17487/RFC5929, July 2010,
              <https://www.rfc-editor.org/info/rfc5929>.

   [RFC6920]  Farrell, S., Kutscher, D., Dannewitz, C., Ohlman, B.,
              Keranen, A., and P. Hallam-Baker, "Naming Things with
              Hashes", RFC 6920, DOI 10.17487/RFC6920, April 2013,
              <https://www.rfc-editor.org/info/rfc6920>.

   [RFC7627]  Bhargavan, K., Ed., Delignat-Lavaud, A., Pironti, A.,
              Langley, A., and M. Ray, "Transport Layer Security (TLS)
              Session Hash and Extended Master Secret Extension",
              RFC 7627, DOI 10.17487/RFC7627, September 2015,
              <https://www.rfc-editor.org/info/rfc7627>.

   [RFC8446]  Rescorla, E., "The Transport Layer Security (TLS) Protocol
              Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
              <https://www.rfc-editor.org/info/rfc8446>.

Schmaus, et al.         Expires 24 December 2026               [Page 11]
Internet-Draft       The Hashed Token SASL Mechanism           June 2026

   [RFC9266]  Whited, S., "Channel Bindings for TLS 1.3", RFC 9266,
              DOI 10.17487/RFC9266, July 2022,
              <https://www.rfc-editor.org/info/rfc9266>.

   [iana-hash-alg]
              Williams, N., "IANA Named Information Hash Algorithm
              Registry", 2010, <https://www.iana.org/assignments/named-
              information/named-information.xhtml#hash-alg>.

   [iana-cbt] Williams, N., "IANA Channel-Binding Types", 2010,
              <https://www.iana.org/assignments/channel-binding-types/
              channel-binding-types.xhtml>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

8.2.  Informative References

   [RFC5802]  Newman, C., Menon-Sen, A., Melnikov, A., and N. Williams,
              "Salted Challenge Response Authentication Mechanism
              (SCRAM) SASL and GSS-API Mechanisms", RFC 5802,
              DOI 10.17487/RFC5802, July 2010,
              <https://www.rfc-editor.org/info/rfc5802>.

   [RFC8126]  Cotton, M., Leiba, B., and T. Narten, "Guidelines for
              Writing an IANA Considerations Section in RFCs", BCP 26,
              RFC 8126, DOI 10.17487/RFC8126, June 2017,
              <https://www.rfc-editor.org/info/rfc8126>.

   [XEP-0397] Schmaus, F., "XEP-0397: Instant Stream Resumption", 3
              November 2018,
              <https://xmpp.org/extensions/xep-0397.html>.

   [XEP-0474] Molitor, T., "XEP-0474: SASL SCRAM Downgrade Protection",
              25 October 2025,
              <https://xmpp.org/extensions/xep-0474.html>.

   [XEP-0484] Wild, M., "XEP-0484: Fast Authentication Streamlining
              Tokens", 30 June 2024,
              <https://xmpp.org/extensions/xep-0484.html>.

Schmaus, et al.         Expires 24 December 2026               [Page 12]
Internet-Draft       The Hashed Token SASL Mechanism           June 2026

Acknowledgments

   This document benefited from discussions on the KITTEN WG mailing
   list.  The authors especially thank Thijs Alkemade, Sam Whited, and
   Alexey Melnikov for their comments.  Furthermore, we would like to
   thank Alexander Würstlein, who devised the idea to pin the token to a
   SASL mechanism for increased security.  And last but not least,
   thanks to Matthew Wild for working on the -NONE variant of SASL-HT.

Authors' Addresses

   Florian Schmaus
   Friedrich-Alexander-Universität Erlangen-Nürnberg
   Germany
   Email: flow@cs.fau.de

   Thilo Molitor
   Monal Instant Messenger
   Germany
   Email: thilo+ietf@eightysoft.de

   Christoph Egger
   Chalmers University of Technology
   Sweden
   Email: christoph.egger@chalmers.se

Schmaus, et al.         Expires 24 December 2026               [Page 13]