The Hashed Token SASL MechanismUniversity of Erlangen-Nurembergschmaus@cs.fau.de
Internet
Common Authentication Technology Next GenerationThis document specifies a SASL mechanism designed to be used with short-lived, exclusively ephemeral tokens.
This section specifies the the family of Hashed Token (HT-*) SASL mechanisms.
It provides hash agility, mutual authentication and is secured by channel binding.
This mechanism was designed to be used with short-lived tokens for quick, one round-trip, re-authentication of a previous session.
Clients are supposed to request such tokens from the server after being authenticated using a "strong" SASL mechanism (e.g. SCRAM).
Hence a typical sequence of actions using SASL-HT may look like the following:
An example application protocol specific extension based on SASL-HT is .
Since the 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", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 .
Additionally, the key words "MIGHT", "COULD", "MAY WISH TO", "WOULD
PROBABLY", "SHOULD CONSIDER", and "MUST (BUT WE KNOW YOU WON'T)" in
this document are to interpreted as described in RFC 6919 .
Because this mechanism transports information that should not be controlled by an attacker, the HT-* mechanism MUST only be used over channels protected by TLS, or over similar integrity-protected and authenticated 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 "HT-" followed by the capitalized "Hash Name String", followed by "-", and suffixed by one of 'ENDP' and 'UNIQ'.
Hence each 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 this document.
Mechanism NameHash 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-* SASL mechanism starts with the initiator-msg, send by the initiator to the responder.
initiator-msg = authcid-length authcid-data initiator-hashed-token
authcid-length = 4OCTET
authcid-data = 1*OCTET
initiator-hashed-token = 1*OCTET
The initiator message starts with an unsigned 32-bit integer in big endian. It denotes length of the authcid-data, which contains the authentication identity.
Before sending the authentication identity string the initiator SHOULD prepare the data with the UsernameCaseMapped profile of .
The initiator-hashed-token value is defined as: HMAC(token, "Initiator" || cb-data)
HMAC() is the function defined in with H being the selected HT-* hash algorithm, 'cb-data' represents the data provided by the channel binding type, and 'token' are the UTF-8 encoded octets of the token string which acts as shared secret between initiator and responder.
The initiator-msg MUST NOT be included in TLS 1.3 0-RTT early data (see ).
This message is followed by a message from the responder to the initiator. This 'responder-msg' is defined as follows:
responder-msg = 1*OCTET
The responder-msg value is defined as: HMAC(token, "Responder" || cb-data)
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 not send additional data with success.HT is 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.To be secure, HT-* MUST be used over a TLS channel that has had the session hash extension negotiated, or session resumption MUST NOT have been used.
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-XXXX: Instant Stream ResumptionThanks to Thijs Alkemade.