]> Friedrich-Alexander-Universität Erlangen-Nürnberg

Germany flow@cs.fau.de

Monal Instant Messenger

Germany thilo+ietf@eightysoft.de

Chalmers University of Technology

Sweden christoph.egger@chalmers.se

Security Common Authentication Technology Next Generation (kitten) 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. Status information for this document may be found at . Source for this draft and an issue tracker can be found at .

Introduction This specification describes the family of Hashed Token (HT) Simple Authentication and Security Layer (SASL) 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 ). Clients should request SASL-HT tokens from the server after being authenticated using a "strong" SASL mechanism like SCRAM . Hence a typical sequence of actions using HT may look like the following:

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). Examples of such an application-protocol-specific extension based on HT are and . 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 for that.

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

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 ) 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).

The HT Family of Mechanisms Each mechanism in this family differs by choice of the hash algorithm and the selection of the channel binding 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:

- ]]>

Where <hash-alg> is the capitalized "Hash Name String" of the IANA "Named Information Hash Algorithm Registry" as specified in , 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 channel binding type is used. Valid channel binding types are defined in the IANA "Channel-Binding Types" registry as specified in . 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 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

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 .

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:

The initiator's first message starts with the authentication identity (authcid, see) as UTF-8 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:

HMAC() is the function defined in 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 . 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.

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.

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:

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).

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.

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).

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

Compliance with SASL Mechanism Requirements This section describes compliance with SASL mechanism requirements specified in Section 5 of . "HT2-SHA-256-ENDP", "HT2-SHA-256-UNIQ", "HT2-SHA3-512-ENDP", "HT2-SHA3-512-UNIQ", …. 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). HT is not capable of transferring authorization identities from the client to the server. HT does not offer any security layers (HT offers channel binding instead). HT does not protect the authorization identity.

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.

Security Considerations The HT mechanism MUST be used over a TLS channel that has the session hash extension 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 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.

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

• To: iana@iana.org Subject: Registration of a new SASL family HT SASL mechanism name (or prefix for the family): HT2-* Security considerations: 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 Intended usage: COMMON Owner/Change controller: IESG iesg@ietf.org Note: Members of this family MUST be explicitly registered using the "IETF Review" registration procedure. Reviews MUST be requested on the Kitten WG mailing list kitten@ietf.org (or a successor designated by the responsible Security AD).

&RFC2104; &RFC3629; &RFC4086; &RFC4422; &RFC5056; &RFC5234; &RFC5929; &RFC6920; &RFC7627; &RFC8446; &RFC9266; IANA IANA &RFC2119; &RFC8174; &RFC5802; &RFC8126;

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.