The Hashed Token SASL Mechanism

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/.¶

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 3 August 2025.¶

Copyright Notice

Copyright (c) 2025 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.¶

Table of Contents

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) support for channel binding.¶

Clients should 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:¶

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]. 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 that.¶

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 "HT-" 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:¶

HT-<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].¶

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

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

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].¶

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

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

responder-msg = success-response / error-response
success-response = NUL 1*OCTET
failure-response = %x01 1*SAFE

success-response := NUL HMAC(token, "Responder" || cb-data)

failure-response := %x01 <failure-description>
failure-description = "unknown-user" /
                      "invalid-token" /
                      "other-error"/
                      failure-description-ext
failure-description-ext = <additional custom failure reasons>

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-SHA3-512-ENDP", "HT-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 he 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.¶

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): 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 kitten@ietf.org¶

  Intended usage: COMMON¶

  Owner/Change controller: IESG 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 (or a successor designated by the responsible Security AD).¶

8. References

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