|Internet-Draft||The Hashed Token SASL Mechanism||November 2022|
|Schmaus & Egger||Expires 11 May 2023||[Page]|
- Common Authentication Technology Next Generation
- Intended Status:
The Hashed Token SASL Mechanism
This document specifies the family of Hashed Token SASL mechanisms which enable a proof-of-possession-based authentication scheme and 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. The usage of short-lived, exclusively ephemeral hashed tokens is achieving the single round-trip property. The SASL mechanism specified herin further provides hash agility, mutual authentication and support for channel binding.¶
This note is to be removed before publishing as an RFC.¶
Status information for this document may be found at https://datatracker.ietf.org/doc/draft-schmaus-kitten-sasl-ht/.¶
Source for this draft and an issue tracker can be found at https://github.com/flowdalic/xeps/tree/master/draft-schmaus-kitten-sasl-ht.¶
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 11 May 2023.¶
Copyright (c) 2022 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.¶
This specification describes the family of Hashed Token (HT) Simple Authentication and Security Layer (SASL) [RFC4422] mechanisms, which enable a proof-of-possession-based authentication scheme. 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) support for channel binding.¶
Clients are supposed to request SASL-HT tokens from the server after being authenticated using a "strong" SASL mechanism like SCRAM [RFC5802]. Hence a typical sequence of actions using HT may look like the following:¶
A) Client authenticates using a strong mechanism (e.g., SCRAM) B) Client requests secret SASL-HT token C) Service returns SASL-HT token <normal client-server interaction here> D) Connection between client and server gets interrupted, for example because of a WiFi ↔ GSM switch E) Client resumes the previous session using HT and token from C) F) Service revokes the successfully used SASL-HT token [goto B]¶
The HT mechanism requires an accompanying, application protocol specific, extension, which allows clients to requests a new SASL-HT token (see Section 5 (Section 5)). One example for such an application protocol specific extension based on HT is [XEP-0397]. This XMPP [RFC6120] extension protocol allows, amongst 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 [RFC5802] 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. These words may also appear in this document in lower case as plain English words, absent their normative meanings.¶
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 [RFC8446]), or over similar integrity-protected and authenticated channels. Also, the application protcol specific extension which requests a new SASL-HT token SHOULD only be used over similarly protected channels.¶
The family of HT mechanisms is not applicable for proxy authentication since they can not carry an authorization identity string (authzid).¶
An HT mechanism name is a string beginning with "HT-" followed by the capitalised name of the used hash, followed by "-", and suffixed by one of 'ENDP', 'UNIQ', 'EXPR' or 'NONE'.¶
Hence each HT mechanism has a name of the following form:¶
Where <hash-alg> is the capitalised "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', 'UNIQ', 'EXPR' or 'NONE' denoting the channel binding type. In the case of 'ENDP', the tls-server-end-point channel binding type is used. In the case of 'UNIQ', the tls-unique channel binding type is used. In the case of 'EXPR', the tls-exporter [RFC9266] channel binding type is used. Valid channel binding types are defined in the IANA "Channel-Binding Types" registry [iana-cbt] as specified in [RFC5056].¶
In the special case of 'NONE', no channel binding is to be used (cb-data is to be an empty string).¶
|cb-type||Channel Binding Type|
The following table lists some examples of HT SASL mechanisms registered by this document.¶
|Mechanism Name||HT Hash Algorithm||Channel-binding unique prefix|
The mechanism consists of a simple exchange of precisely two messages between the initiator and responder.¶
The HT mechanism starts with the initiator-msg, send by the initiator to the responder. The following lists the ABNF grammar for the initiator-msg:¶
initiator-msg = authcid NUL initiator-hashed-token authcid = 1*SAFE ; MUST accept up to 255 octets initiator-hashed-token = 1*OCTET NUL = %0x00 ; The null octet SAFE = UTF1 / UTF2 / UTF3 / UTF4 ;; any UTF-8 encoded Unicode character except NUL UTF1 = %x01-7F ;; except NUL UTF2 = %xC2-DF UTF0 UTF3 = %xE0 %xA0-BF UTF0 / %xE1-EC 2(UTF0) / %xED %x80-9F UTF0 / %xEE-EF 2(UTF0) UTF4 = %xF0 %x90-BF 2(UTF0) / %xF1-F3 3(UTF0) / %xF4 %x80-8F 2(UTF0) UTF0 = %x80-BF¶
The initiator first message starts with the authentication identity (authcid, see[RFC4422]) as UTF-8 [RFC3629] 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:¶
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 selected channel binding type, and 'token' are the UTF-8 encoded octets of the SASL-HT token string which acts as a shared secret between initiator and responder.¶
The initiator-msg MAY be included in TLS 1.3 0-RTT early data, as specified in [RFC8446]. If this is the case, then the initiating entity MUST NOT include any further application 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.¶
SASL-HT hence allows exploiting TLS 1.3 early data for "0.5 Round Trip Time (RTT)" resumption of the application protocol's session. Using TLS early data requires extra care when implementing: The early data should only contain the SASL-HT payload, i.e., the initiator-msg, and not an application protocol specific payload. The reason for this is that the early data could be replayed, and thus needs to carry an idempotent operation. On the other hand, if the responding entity can verify the early data, then it can send additional application protocol payload together with the "resumption successful" response to the initiating entity.¶
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.¶
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:¶
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.¶
- "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: a) HT is a client-first mechanism. b) 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 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 pinning the token to a SASL mechanism, which increases the security because it makes it impossible for an attacker to downgrade the SASL mechanism.¶
It is RECOMMENDED that the protocol defines a way for a client to request rotation or revocation of a token.¶
It is RECOMMENDED that implementations periodically 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 [RFC4086] for more information about Randomness Requirements for Security. In addition, comparison of the client's HMAC with the server's calculated HMAC SHOULD be performed using constant-time comparison functions, to protect against timing attacks.¶
The tokens used with HT mechanisms SHOULD have a limited lifetime, e.g. based on usage count or time elapsed since issuance.¶
Due to the additional security properties afforded by channel binding, it is RECOMMENDED that clients use HT mechanisms supporting channel binding in environments that can support it.¶
Subject: Registration of a new SASL family HT¶
SASL mechanism name (or prefix for the family): HT-*¶
Published specification (optional, recommended): draft-schmaus-kitten-sasl-ht-XX (TODO)¶
Intended usage: COMMON¶
Note: Members of this family MUST be explicitly registered using the "IETF Review" [RFC8126] registration procedure. Reviews MUST be requested on the Kitten WG mailing list email@example.com (or a successor designated by the responsible Security AD).¶
- Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, DOI 10.17487/RFC2104, , <https://www.rfc-editor.org/info/rfc2104>.
- Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, , <https://www.rfc-editor.org/info/rfc3629>.
- Eastlake 3rd, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, DOI 10.17487/RFC4086, , <https://www.rfc-editor.org/info/rfc4086>.
- Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple Authentication and Security Layer (SASL)", RFC 4422, DOI 10.17487/RFC4422, , <https://www.rfc-editor.org/info/rfc4422>.
- Williams, N., "On the Use of Channel Bindings to Secure Channels", RFC 5056, DOI 10.17487/RFC5056, , <https://www.rfc-editor.org/info/rfc5056>.
- Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, , <https://www.rfc-editor.org/info/rfc5234>.
- 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, , <https://www.rfc-editor.org/info/rfc5280>.
- Altman, J., Williams, N., and L. Zhu, "Channel Bindings for TLS", RFC 5929, DOI 10.17487/RFC5929, , <https://www.rfc-editor.org/info/rfc5929>.
- 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, , <https://www.rfc-editor.org/info/rfc6125>.
- Farrell, S., Kutscher, D., Dannewitz, C., Ohlman, B., Keranen, A., and P. Hallam-Baker, "Naming Things with Hashes", RFC 6920, DOI 10.17487/RFC6920, , <https://www.rfc-editor.org/info/rfc6920>.
- 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, , <https://www.rfc-editor.org/info/rfc7627>.
- Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, , <https://www.rfc-editor.org/info/rfc8446>.
- Whited, S., "Channel Bindings for TLS 1.3", RFC 9266, DOI 10.17487/RFC9266, , <https://www.rfc-editor.org/info/rfc9266>.
- Williams, N., "IANA Named Information Hash Algorithm Registry", , <https://www.iana.org/assignments/named-information/named-information.xhtml#hash-alg>.
- Williams, N., "IANA Channel-Binding Types", , <https://www.iana.org/assignments/channel-binding-types/channel-binding-types.xhtml>.
- Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/info/rfc2119>.
- Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/info/rfc8174>.
- 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, , <https://www.rfc-editor.org/info/rfc5802>.
- Saint-Andre, P., "Extensible Messaging and Presence Protocol (XMPP): Core", RFC 6120, DOI 10.17487/RFC6120, , <https://www.rfc-editor.org/info/rfc6120>.
- Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, , <https://www.rfc-editor.org/info/rfc8126>.
- Schmaus, F., "XEP-0397: Instant Stream Resumption", , <https://xmpp.org/extensions/xep-0397.html>.
This document benefited from discussions on the KITTEN WG mailing list. The authors would like to especially thank Thijs Alkemade, Sam Whited and Alexey Melnikov for their comments on this topic. Furthermore, we would like to thank Alexander Wuerstlein, who came up with the idea to pin the token to a SASL mechanism for increased security. And last but not least, thanks to Matthew Wild for working on the -NONE variant of SASL-HT.¶