The Hashed Token SASL Mechanism
draft-schmaus-kitten-sasl-ht-02

Abstract

This document specifies a SASL mechanism designed to be used with short-lived, exclusively ephemeral 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 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 May 1, 2018.

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 (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. 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
• 1.1. Conventions and Terminology
• 1.2. Applicability
• 2. The HT-* Family of Mechanisms
• 3. The HT Mechanism
• 3.1. Initiator First Message
• 3.2. Final Responder Message
• 4. Compliance with SASL Mechanism Requirements
• 5. Security Considerations
• 6. IANA Considerations
• 7. References
• 7.1. Normative References
• 7.2. Informative References
• Appendix A. Acknowledgments
• Authors' Addresses

1. Introduction

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:

A) Client authenticates using a strong mechanism (e.g., SCRAM)
B) Client requests secret SASL-HT token
   <normal client-server interaction here>
C) Connection between client and server gets interrupted
   (e.g., WiFi ↔ GSM switch)
D) Client resumes previous session using the token from B
E) Client requests secret SASL-HT token
   [goto C]

An example application protocol specific extension based on SASL-HT is [XEP-ISR-SASL2].

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

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

The family of HT-* mechanisms is not applicable for proxy authentication, since they can not carry a authorization identity string (authzid).

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.

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:

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

The following table lists the HT-* SASL mechanisms registered by this document.

3. The HT Mechanism

The 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 [RFC5234].

3.1. Initiator First Message

The HT-* SASL mechanism starts with the initiator-msg, send by the initiator to the responder. This results in the follwing ABNF syntax:

initiator-msg = authcid-length authcid-data initiator-hashed-token

authcid-length = 2OCTET

authcid-data = 1*OCTET

initiator-hashed-token = 1*OCTET

The initiator-msg starts with an unsigned 16-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 UsernameCasePreserved profile of [RFC8265].

The authcid-data is followed by initiator-hashed-token. The value of the initiator-hashed-token is defined as follows:

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

HMAC() is the function defined in [RFC2104] 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 MAY be included in TLS 1.3 0-RTT early data, as specified in [I-D.ietf-tls-tls13]. 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.

3.2. Final Responder Message

This message is followed by a message from the responder to the initiator. The ABNF for responder-msg is:

responder-msg = 1*OCTET

The responder-msg value is defined as follows:

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

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

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-SHA-3-512-ENDP" and "HT-SHA-3-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. 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.

It is RECOMMENDED that implementations peridically require a full authentication using a strong SASL mechanism which does not use the HT-* token.

6. IANA Considerations

IANA has added 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 FIXME of draft-schmaus-kitten-sasl-ht
Published specification (optional, recommended):
  draft-schmaus-kitten-sasl-ht-00 (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" [@!RFC5226] registration procedure.
Reviews MUST be requested on the Kitten WG mailing list
<kitten@ietf.org> (or a successor designated by the responsible
Security AD).

7. References

7.1. Normative References

7.2. Informative References

Appendix A. Acknowledgments

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

Authors' Addresses