Common Authentication Technology Next Generation F. Schmaus
Internet-Draft University of Erlangen-Nuremberg
Intended status: Informational March 22, 2017
Expires: September 23, 2017

The Hashed Token SASL Mechanism


This document specifies a new SASL mechanism designed to authenticate using short-lived, exclusively emphermeral tokens.

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 September 23, 2017.

Copyright Notice

Copyright (c) 2017 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 ( 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. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

1. Introduction

This section specifies the the family of Hashed Token (HT-) SASL mechanisms. This mechanism was designed to be used with short-lived tokens, used as shared secrets, for authentication. It provides hash agility, mutual authentication and is secured by channel binding. 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 [RFC5802] for that.

1.1. Conventions and Terminology

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 [RFC2119].

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 [RFC6919].

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 TLS, or over similar integrity-protected and authenticated channels. In addition, when TLS is used, the client MUST successfully validate the server's certificate ([RFC5280],[RFC6125]).

2. The HT-* Family of Mechanisms

Each mechanism in this family differs by the choice of the hash algorithm and the choice of the channel binding [RFC5929] type. Each mechanism has a name of the form HT-[HA]-[CBT] where [HA] is the capitalized "Hash Name String" of the IANA "Named Information Hash Algorithm Registry" [iana-hash-alg] as specified in [RFC6920], and [CBT] 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 [iana-cbt] as specified in [RFC5056].

Mapping of CBT to Channel Bindings
CBT Channel Binding Type
ENDP tls-server-end-point
UNIQ tls-unique

The following table lists a few examples of HT-* SASL mechanism names.

Example HT-* SASL mechanisms
Mechanism Name 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

3. The HT Mechanism

The mechanism consists of a simple exchange of exactly two messages between the initiator and responder. It starts with the message from the initiator to the responder. This 'initiator-message' is defined as follows:

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

HMAC() is the function defined in [RFC2104] with H being the chosen hash algorithm, 'cb-data' represents the data provided by the channel binding type, and 'token' are the UTF-8 encoded bytes of the token String which acts as shared secret between initiator and responder. The initiator-message MUST NOT be included in TLS 1.3 0-RTT early data ([I-D.ietf-tls-tls13]).

This message is followed by a message from the responder to the initiator. This 'responder-message' is defined as follows:

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

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

3.1. 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 "HT-SHA-3-512-UNIQ".
  2. Definition of server-challenges and client-responses:
    HT is a client-first mechanism.
    HT does not send additional data with success.
  3. HT is capable of transferring authorization identities from the client to the server. (TODO)
  4. HT does not offer any security layers (HT offers channel binding instead).
  5. HT does not protect the authorization identity.

4. Security Considerations

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

5. IANA Considerations


6. References

6.1. Normative References

[I-D.ietf-tls-tls13] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", Internet-Draft draft-ietf-tls-tls13-18, October 2016.
[RFC2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, DOI 10.17487/RFC2104, February 1997.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997.
[RFC4422] Melnikov, A. and K. Zeilenga, "Simple Authentication and Security Layer (SASL)", RFC 4422, DOI 10.17487/RFC4422, June 2006.
[RFC5929] Altman, J., Williams, N. and L. Zhu, "Channel Bindings for TLS", RFC 5929, DOI 10.17487/RFC5929, July 2010.
[RFC6919] Barnes, R., Kent, S. and E. Rescorla, "Further Key Words for Use in RFCs to Indicate Requirement Levels", RFC 6919, DOI 10.17487/RFC6919, April 2013.
[RFC7627] Bhargavan, K., 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.
[iana-cbt] Williams, N., "IANA Channel-Binding Types", 2010.
[iana-hash-alg] Williams, N., "IANA Named Information Hash Algorithm Registry", 2010.

6.2. Informative References

[RFC5056] Williams, N., "On the Use of Channel Bindings to Secure Channels", RFC 5056, DOI 10.17487/RFC5056, November 2007.
[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.
[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.

Appendix A. Acknowledgements

Thanks to Thijs Alkemade.

Author's Address

Florian Schmaus University of Erlangen-Nuremberg EMail: