Skip to main content

The Hashed Token SASL Mechanism

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Expired".
Authors Florian Schmaus , Christoph Egger
Last updated 2022-10-10
RFC stream (None)
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
Common Authentication Technology Next Generation              F. Schmaus
Internet-Draft                                                  C. Egger
Intended status: Experimental                      FAU Erlangen-Nürnberg
Expires: 13 April 2023                                   10 October 2022

                    The Hashed Token SASL Mechanism


      This I-D is developed at
      kitten-sasl-ht (

   This document specifies the family of Hashed Token SASL mechanisms
   which enable a proof-of-possession-based authentication scheme and
   are meant to be used for quick re-authentication of 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 herin further provides
   hash agility, mutual authentication and is secured by channel

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

   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 13 April 2023.

Copyright Notice

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

Schmaus & Egger           Expires 13 April 2023                 [Page 1]
Internet-Draft       The Hashed Token SASL Mechanism        October 2022

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (
   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.

Table of Contents

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

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, and 3) being secured by channel binding.

   Clients are supposed to 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:

Schmaus & Egger           Expires 13 April 2023                 [Page 2]
Internet-Draft       The Hashed Token SASL Mechanism        October 2022

   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 requests a new SASL-HT
   token (see Section 5 (Section 5)).  One example for such an
   application protocol specific extension based on HT is [XEP-0397].
   This XMPP [RFC6120] extension protocol allows, amongst other things,
   B) and C),

   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

1.1.  Conventions and Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "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

1.2.  Applicability

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

   Also, when TLS is used, the client *MUST* successfully validate the
   server's certificate ([RFC5280], [RFC6125]).

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

Schmaus & Egger           Expires 13 April 2023                 [Page 3]
Internet-Draft       The Hashed Token SASL Mechanism        October 2022

2.  The HT Family of Mechanisms

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

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

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


   Where <hash-alg> is the capitalised "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', or
   'EXPR' 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].

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

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

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

Schmaus & Egger           Expires 13 April 2023                 [Page 4]
Internet-Draft       The Hashed Token SASL Mechanism        October 2022

      | Mechanism Name   | HT Hash Algorithm | Channel-binding      |
      |                  |                   | unique prefix        |
      | HT-SHA-512-ENDP  | SHA-512           | tls-server-end-point |
      | HT-SHA-512-UNIQ  | SHA-512           | tls-unique           |
      | HT-SHA3-512-ENDP | SHA3-512          | tls-server-end-point |
      | HT-SHA-256-UNIQ  | SHA-256           | tls-unique           |

                  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.

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

3.1.  Initiator First Message

   The HT mechanism starts with the initiator-msg, send by the initiator
   to the responder.  The following lists the ABNF grammar for the

   initiator-msg = authcid NUL initiator-hashed-token
   authcid = 1*SAFE ; MUST accept up to 255 octets
   initiator-hashed-token = 1*OCTET

   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 first message starts with the authentication identity
   (authcid, see[RFC4422]) as UTF-8 [RFC3629] encoded string.  It is
   followed by initiator-hashed-token separated by as single null octet.

Schmaus & Egger           Expires 13 April 2023                 [Page 5]
Internet-Draft       The Hashed Token SASL Mechanism        October 2022

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

   initiator-hashed-token := HMAC(token, "Initiator" || cb-data)

   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* include any further application protocol payload in
   the early data besides the HT initiator-msg and potential required
   framing of the SASL profile.  The responder *MUST* abort the SASL
   authentication if the early data contains additional application
   protocol payload.

      SASL-HT hence allows exploiting TLS 1.3 early data for "0.5 Round
      Trip Time (RTT)" resumption 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 the early data could be replayed, and
      thus needs to carry an idempotent operation.  On the other hand,
      if the responding entity can verify the early data, then it can
      send additional application protocol payload together with the
      "resumption successful" response to the initiating entity.

3.2.  Initiator Authentication

   Upon receiving the initiator-msg, the responder calculates itself 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.

   If the responder was able to authenticate the initiator, then the
   used token *MUST* be revoked immediately.

3.3.  Final Responder Message

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

   The ABNF for responder-msg is:

   responder-msg = 1*OCTET

Schmaus & Egger           Expires 13 April 2023                 [Page 6]
Internet-Draft       The Hashed Token SASL Mechanism        October 2022

   The responder-msg value is defined as follows:

   responder-msg := HMAC(token, "Responder" || cb-data)

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

4.  Compliance with SASL Mechanism Requirements

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

   1.  "HT-SHA-256-ENDP", "HT-SHA-256-UNIQ", "HT-SHA-3-512-ENDP" and

   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

   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 form of a Unicode
   string.  The returned token *MUST* have been newly generated by a
   cryptographically secure random number generator and MUST contain at
   least 128 bit of entropy.

   It is *RECOMMENDED* that the protocol allows the requestor to signal
   the name of the SASL mechanism which he intends to use with the
   token.  If a token is used with a different mechanism than the one
   which was signalled upon requesting the token, then the
   authentication *MUST* fail.  This 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.

6.  Security Considerations

   To be secure, the HT mechanism *MUST* be used over a TLS channel that
   has had the session hash extension [RFC7627] negotiated, or session
   resumption *MUST NOT* have been used.

Schmaus & Egger           Expires 13 April 2023                 [Page 7]
Internet-Draft       The Hashed Token SASL Mechanism        October 2022

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

   It is of vital importance that the SASL-HT token is generated by a
   cryptographically secure random generator.  See [RFC4086] for more
   information about Randomness Requirements for Security.

7.  IANA Considerations

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


      Subject: Registration of a new SASL family HT

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

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

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

      Person & email address to contact for further information: IETF
      SASL WG (

      Intended usage: COMMON

      Owner/Change controller: IESG (

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

8.  References

8.1.  Normative References

   [RFC2104]  Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
              Hashing for Message Authentication", RFC 2104,
              DOI 10.17487/RFC2104, February 1997,

Schmaus & Egger           Expires 13 April 2023                 [Page 8]
Internet-Draft       The Hashed Token SASL Mechanism        October 2022

   [RFC3629]  Yergeau, F., "UTF-8, a transformation format of ISO
              10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November
              2003, <>.

   [RFC4086]  Eastlake 3rd, D., Schiller, J., and S. Crocker,
              "Randomness Requirements for Security", BCP 106, RFC 4086,
              DOI 10.17487/RFC4086, June 2005,

   [RFC4422]  Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple
              Authentication and Security Layer (SASL)", RFC 4422,
              DOI 10.17487/RFC4422, June 2006,

   [RFC5056]  Williams, N., "On the Use of Channel Bindings to Secure
              Channels", RFC 5056, DOI 10.17487/RFC5056, November 2007,

   [RFC5234]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", STD 68, RFC 5234,
              DOI 10.17487/RFC5234, January 2008,

   [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
              (TLS) Protocol Version 1.2", RFC 5246,
              DOI 10.17487/RFC5246, August 2008,

   [RFC5280]  Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
              Housley, R., and W. Polk, "Internet X.509 Public Key
              Infrastructure Certificate and Certificate Revocation List
              (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,

   [RFC5929]  Altman, J., Williams, N., and L. Zhu, "Channel Bindings
              for TLS", RFC 5929, DOI 10.17487/RFC5929, July 2010,

   [RFC6125]  Saint-Andre, P. and J. Hodges, "Representation and
              Verification of Domain-Based Application Service Identity
              within Internet Public Key Infrastructure Using X.509
              (PKIX) Certificates in the Context of Transport Layer
              Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March
              2011, <>.

Schmaus & Egger           Expires 13 April 2023                 [Page 9]
Internet-Draft       The Hashed Token SASL Mechanism        October 2022

   [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,

   [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,

   [RFC8446]  Rescorla, E., "The Transport Layer Security (TLS) Protocol
              Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,

   [RFC9266]  Whited, S., "Channel Bindings for TLS 1.3", RFC 9266,
              DOI 10.17487/RFC9266, July 2022,

              Williams, N., "IANA Named Information Hash Algorithm
              Registry", 2010, <

   [iana-cbt] Williams, N., "IANA Channel-Binding Types", 2010,

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <>.

8.2.  Informative References

   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", RFC 5226,
              DOI 10.17487/RFC5226, May 2008,

Schmaus & Egger           Expires 13 April 2023                [Page 10]
Internet-Draft       The Hashed Token SASL Mechanism        October 2022

   [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,

   [RFC6120]  Saint-Andre, P., "Extensible Messaging and Presence
              Protocol (XMPP): Core", RFC 6120, DOI 10.17487/RFC6120,
              March 2011, <>.

   [XEP-0397] Schmaus, F., "XEP-0397: Instant Stream Resumption", 3
              November 2018,


   This document benefited from discussions on the KITTEN WG mailing
   list.  The authors would like to especially thank Thijs Alkemade, Sam
   Whited and Alexey Melnikov for their comments on this topic.
   Furthermore, we would like to thank Alexander Wuerstlein, who came up
   with the idea to pin the token to a SASL mechanism for increased

Authors' Addresses

   Florian Schmaus
   FAU Erlangen-Nürnberg

   Christoph Egger
   FAU Erlangen-Nürnberg

Schmaus & Egger           Expires 13 April 2023                [Page 11]