The Hashed Token SASL MechanismUniversity of Erlangen-Nurembergschmaus@cs.fau.deUniversity of Erlangen-Nurembergegger@cs.fau.de
Internet
Common Authentication Technology Next GenerationThis document specifies the family of Hashed Token SASL mechanisms, which 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.
This is achieved by the usage of short-lived, exclusively ephemeral hashed tokens.
It further provides hash agility, mutual authentication and is secured by channel binding.
This specification describes the the family of Hashed Token (HT) Simple Authentication and Security Layer (SASL) mechanisms.
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 .
Hence a typical sequence of actions using HT may look like the following:
The HT mechanism requires an accompanying, application protocol specific, extension, which allows clients to requests a new SASL-HT token (see ).
One example for such an application protocol specific extension based on HT is .
This XMPP extension protocol allows, amoungst 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 for that.
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.
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 ), or over similar integrity-protected and authenticated channels.
Also the application protoocl specific extension which requests a new SASL-HT token SHOULD only be used over similar protected channels.
In addition, when TLS is used, the client MUST successfully validate the server's certificate (, ).
The family of HT mechanisms is not applicable for proxy authentication, since they can not carry a authorization identity string (authzid).
Each mechanism in this family differs by the choice of the hash algorithm and the choice of the channel binding type.
A 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' and 'UNIQ'.
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' or 'UNIQ' denoting the channel binding type.
In case of 'ENDP', the tls-server-end-point channel binding type is used.
In case of 'UNIQ', the tls-unique channel binding type is used.
Valid channel binding types are defined in the IANA "Channel-Binding Types" registry as specified in .
CBTChannel Binding TypeENDPtls-server-end-pointUNIQtls-uniqueThe following table lists the HT SASL mechanisms registered by this document.
Mechanism NameHT Hash AlgorithmChannel-binding unique prefixHT-SHA-512-ENDPSHA-512tls-server-end-pointHT-SHA-512-UNIQSHA-512tls-uniqueHT-SHA3-512-ENDPSHA3-512tls-server-end-pointHT-SHA-256-UNIQSHA-256tls-uniqueThe mechanism consists of a simple exchange of exactly two messages between the initiator and responder.
The following syntax specifications use the Augmented Backus-Naur form (ABNF) notation as specified in .
The HT mechanism starts with the initiator-msg, send by the initiator to the responder.
The follwing lists the ABNF grammar for the initiator-msg:
The initiator first message starts with the authentication identity (authcid, see) as UTF-8 encoded string.
It is followed by initiator-hashed-token separated by as single null octet.
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 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 include any further appliction 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.
TODO: It should be possible to exploit TLS 1.3 early data for "0.5"
RTT resumption of the application protocol's session. That is, on
resumption the initiating entity MUST NOT send any application
protocol payload together with first flight data, besides the HT
initiator-msg. But if the responding entity is able to verify the
TLS 1.3 early data, then it can send additional application protocol
payload right away together with the "resumption successful"
response to the initiating entity.
TODO: Add note why HMAC() is always involved, even if HMAC() is
usually not required when modern hash algorithms are used.
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.
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:
The responder-msg value is defined as follows:
The initiating entity MUST verify the responder-msg to achieve mutual authentication.
This section describes compliance with SASL mechanism requirements specified in Section 5 of .
"HT-SHA-256-ENDP", "HT-SHA-256-UNIQ", "HT-SHA-3-512-ENDP" and "HT-SHA-3-512-UNIQ".Definition of server-challenges and client-responses:
HT is a client-first mechanism.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.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 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 to pin the token to a SASL mechanism, which increases the security because it makes it impossible for an attacker to downgrade the SASL mechanism.
To be secure, the HT mechanism MUST be used over a TLS channel that has had the session hash extension negotiated, or session resumption MUST NOT have been used.
It is RECOMMENDED that implementations peridically 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 for more information about Randomness Requirements for Security.
IANA has added the following family of SASL mechanisms to the SASL Mechanism registry established by :
IANA Channel-Binding TypesIANAIANA Named Information Hash Algorithm RegistryIANAXEP-0397: Instant Stream ResumptionThis document benefited from discussions on the KITTEN WG mailing list.
The authors would like to specially thank Thijs Alkemade, Sam Whited and Alexey Melnikov for their comments on this topic.
Furthermore we would like to thank Alexander Würstlein, who came up with the idea to pin the token to a SASL mechanism for increased security.