The Hashed Token SASL Mechanism
draft-schmaus-kitten-sasl-ht-01
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Authors | Florian Schmaus , Christoph Egger | ||
| Last updated | 2017-10-28 (Latest revision 2017-09-29) | ||
| RFC stream | (None) | ||
| Formats | |||
| Additional resources | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-schmaus-kitten-sasl-ht-01
Common Authentication Technology Next Generation F. Schmaus
Internet-Draft C. Egger
Intended status: Experimental University of Erlangen-Nuremberg
Expires: April 2, 2018 September 29, 2017
The Hashed Token SASL Mechanism
draft-schmaus-kitten-sasl-ht-01
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 April 2, 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.
Schmaus & Egger Expires April 2, 2018 [Page 1]
Internet-Draft September 2017
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Conventions and Terminology . . . . . . . . . . . . . . . 3
1.2. Applicability . . . . . . . . . . . . . . . . . . . . . . 3
2. The HT-* Family of Mechanisms . . . . . . . . . . . . . . . . 3
3. The HT Mechanism . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Initiator First Message . . . . . . . . . . . . . . . . . 4
3.2. Final Responder Message . . . . . . . . . . . . . . . . . 5
4. Compliance with SASL Mechanism Requirements . . . . . . . . . 5
5. Security Considerations . . . . . . . . . . . . . . . . . . . 6
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
7.1. Normative References . . . . . . . . . . . . . . . . . . 6
7.2. Informative References . . . . . . . . . . . . . . . . . 8
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
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.
Schmaus & Egger Expires April 2, 2018 [Page 2]
Internet-Draft September 2017
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]).
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].
Schmaus & Egger Expires April 2, 2018 [Page 3]
Internet-Draft September 2017
+------+----------------------+
| CBT | Channel Binding Type |
+------+----------------------+
| ENDP | tls-server-end-point |
| UNIQ | tls-unique |
+------+----------------------+
Mapping of CBT to Channel Bindings
The following table lists the HT-* SASL mechanisms registered this
document.
+------------------+----------------+-------------------------------+
| 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 |
+------------------+----------------+-------------------------------+
Defined HT-* SASL mechanisms
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.
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
Schmaus & Egger Expires April 2, 2018 [Page 4]
Internet-Draft September 2017
string the initiator SHOULD prepare the data with the
UsernameCaseMapped profile of [RFC7613].
The initiator-hashed-token value is defined as: 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 MUST NOT be included in TLS 1.3 0-RTT early data
(see [I-D.ietf-tls-tls13]).
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. 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.
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 not send additional data with success.
3. HT is capable of transferring authorization identities from the
client to the server.
Schmaus & Egger Expires April 2, 2018 [Page 5]
Internet-Draft September 2017
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.
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-00
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
[I-D.ietf-tls-tls13]
Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", draft-ietf-tls-tls13-19 (work in progress),
March 2017.
[iana-cbt]
Williams, N., "IANA Channel-Binding Types", 2010,
<https://www.iana.org/assignments/channel-binding-types/
channel-binding-types.xhtml>.
Schmaus & Egger Expires April 2, 2018 [Page 6]
Internet-Draft September 2017
[iana-hash-alg]
Williams, N., "IANA Named Information Hash Algorithm
Registry", 2010, <https://www.iana.org/assignments/named-
information/named-information.xhtml#hash-alg>.
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104,
DOI 10.17487/RFC2104, February 1997,
<https://www.rfc-editor.org/info/rfc2104>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC4422] Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple
Authentication and Security Layer (SASL)", RFC 4422,
DOI 10.17487/RFC4422, June 2006,
<https://www.rfc-editor.org/info/rfc4422>.
[RFC5056] Williams, N., "On the Use of Channel Bindings to Secure
Channels", RFC 5056, DOI 10.17487/RFC5056, November 2007,
<https://www.rfc-editor.org/info/rfc5056>.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234,
DOI 10.17487/RFC5234, January 2008,
<https://www.rfc-editor.org/info/rfc5234>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<https://www.rfc-editor.org/info/rfc5280>.
[RFC5929] Altman, J., Williams, N., and L. Zhu, "Channel Bindings
for TLS", RFC 5929, DOI 10.17487/RFC5929, July 2010,
<https://www.rfc-editor.org/info/rfc5929>.
[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and
Verification of Domain-Based Application Service Identity
within Internet Public Key Infrastructure Using X.509
(PKIX) Certificates in the Context of Transport Layer
Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March
2011, <https://www.rfc-editor.org/info/rfc6125>.
Schmaus & Egger Expires April 2, 2018 [Page 7]
Internet-Draft September 2017
[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,
<https://www.rfc-editor.org/info/rfc6919>.
[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,
<https://www.rfc-editor.org/info/rfc6920>.
[RFC7613] Saint-Andre, P. and A. Melnikov, "Preparation,
Enforcement, and Comparison of Internationalized Strings
Representing Usernames and Passwords", RFC 7613,
DOI 10.17487/RFC7613, August 2015,
<https://www.rfc-editor.org/info/rfc7613>.
[RFC7627] Bhargavan, K., Ed., 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,
<https://www.rfc-editor.org/info/rfc7627>.
7.2. Informative References
[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,
<https://www.rfc-editor.org/info/rfc5802>.
[XEP-ISR-SASL2]
Schmaus, F., "XEP-XXXX: Instant Stream Resumption", 2017,
<http://geekplace.eu/xeps/xep-isr-sasl2/
xep-isr-sasl2.html>.
Appendix A. Acknowledgments
Thanks to Thijs Alkemade.
Authors' Addresses
Florian Schmaus
University of Erlangen-Nuremberg
Email: schmaus@cs.fau.de
Schmaus & Egger Expires April 2, 2018 [Page 8]
Internet-Draft September 2017
Christoph Egger
University of Erlangen-Nuremberg
Email: egger@cs.fau.de
Schmaus & Egger Expires April 2, 2018 [Page 9]