Internet-Draft | OPAQUE Authentication | January 2023 |
von Reitzenstein Čerpnjak | Expires 20 July 2023 | [Page] |
This specification describes a Simple Authentication and Security Layer (SASL, RFC4422) authentication mechanisms based on the OPAQUE asymmetric password-authenticated key agreement (PAKE) protocol.¶
The mechanism offers two distinct advantages over the SCRAM family of mechanisms. The underlying OPAQUE protocol provides the ability for clients to register without the server having to have access to the clear text password of an user, preventing password exfiltration at registration. Secondly a successful authentication produces a long-term secret key specific to the user that can be used to access encrypted server-side data without needing to share keys between clients via side-band mechanisms.¶
When used in combination with TLS or an equivalent security layer these mechanisms allow for secure channel binding.¶
This note is to be removed before publishing as an RFC.¶
Discussion of this document takes place on the Common Authentication Technology Next Generation Working Group mailing list (kitten@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/kitten/.¶
Source for this draft and an issue tracker can be found at https://github.com/dequbed/draft-reitzenstein-auth-opaque.¶
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 20 July 2023.¶
Copyright (c) 2023 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.¶
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.¶
This specification describes an authentication mechanism called OPAQUE, based on the asymmetric PAKE of the same name. The mechanisms provide strong mutual authentication and allow binding the authentication to an pre-existing underlying encrypted transport.¶
The mechanism specified in this document is a Simple Authentication and Security Layer (SASL) mechanism compatible to the bridge between SASL and the Generic Security Services Application Programming Interface (GSS-API) called "GS2" [RFC5801]. This means that the mechanism can be used as either a SASL mechanism or a GSS-API mechanism.¶
The OPAQUE algorithm provides the following features which this mechanism makes use of:¶
The Authenticated Key Exchange defined by OPAQUE consists of three messages -- KE1, KE2 and KE3 -- send by the client (KE1, KE3) and server (KE2) respectively. A client knows the outcome of the authentication after receiving KE2, the server after receiving KE3.¶
The following is a description of a full SASL OPAQUE-A255SHA authentication exchange. Nothing in OPAQUE-A255SHA prevents sending the first client response with the SASL authentication request as defined by an application protocol ("initial client response"). See [RFC4422] for more details.¶
The OPAQUE client starts by being in possession of an username and password. It uses the password to generate a KE1, and sends this message and the username to the server.¶
The server retrieves the corresponding authentication information, i.e. registration record, OPRF seed, server private key, and the key-stretching function (KSF) parameters that were used at registration. It uses the first three to generate a KE2 message as per [OPAQUE] and sends that, channel binding data (if any) and the KSF parameters to the client.¶
The client authenticates the server using KE2 and the KSF parameters, also showing the integrity of the channel binding data in the process, and generates a final KE3 message it can return to the server.¶
The three messages KE1, KE2 and KE3 are generated using the following functions specified in [OPAQUE] with the configuration specified in Section 5:¶
KE1 := ClientInit(password) KE2 := ServerInit( server_identity, server_private_key, server_public_key, record, credential_identifier, oprf_seed, KE1, client_identity ) KE3 := ClientFinish(client_identity, server_identity, KE2)¶
The values of client_identity
and server_identity
are set to the byte sequences:¶
client_identity := client-first-message + "," + client_public_key server_identity := server-message-bare + "," + server_public_key¶
With the values and encodings of the remaining parameters per the OPAQUE specification, client_
- and server_public_key
being encoded as raw bytes, and +
indicating concatenation.¶
Upon receipt of KE3 the server can validate the authentication exchange including integrity of the channel binding data it sent previously, and extract a session key that strongly authenticates the client to the server.¶
The name of the mechanism specified in this document is "OPAQUE-A255SHA" or "OPAQUE-A255SHA-PLUS" respectively. The "-PLUS" suffix is only used when the authenticating parties support and intent to use channel binding. If the server supports channel binding it SHOULD advertise both the bare and the plus version of this mechanism. If the server does not it will only advertise the bare version.¶
The OPAQUE-3DH configuration according to Section 7 of [OPAQUE] used by the OPAQUE-A255SHA mechanism is made up of the following cryptographic primitives:¶
Implementations of this mechanism SHOULD default to Argon2id parameters of (t=1, p=4, m=2^21).¶
An example of an OPAQUE-A255SHA authentication exchange consisting of three messages, send by the client, server and client respectively:¶
C: n,,n=user,r=<ke1> S: c=biws,i=bT0yMDk3MTUyLHQ9MSxwPTQ=,v=<ke2> C: p=<ke3>¶
First, the client sends the "client-first-message" containing:¶
In response the server sends the "server-message" containing:¶
The client then recovers a client-only export key and a shared secret specific to this session from the OPRF response using the defined KSF with the user-provided password and parameters sent by the server.¶
To finalize the authentication a client sends a "client-final-message" containing itself a MAC over the exchange (in KE3), thus cryptographically authenticating the client to the server.¶
This section details all attributes permissible in messages, their use and their value format. All Attribute keys are a single US-ASCII letter and case-sensitive. The selection of letters used for attribute keys is based on SCRAM [RFC5802] to make it easier to adapt extensions defined for SCRAM to this mechanism.¶
The order of attributes is fixed for all messages, except for extension attributes which are limited to designated positions but may appear in any order. Implementations MUST NOT assume a specific ordering of extensions.¶
The Argon2id [RFC9106] algorithm as used by OPAQUE-A255SHA requires the three parameters t, p, and m to be additionally transferred from server to client for an authentication exchange. The values for these parameters are fixed at registration time, but may be different for each user.¶
Note: Argon2 may get a PKCS#5 parameter encoding, e.g. https://github.com/P-H-C/phc-winner-argon2/issues/348 ; should we wait on that or specify our own format?Nadja¶
The limits and interpretation of the parameters set in [RFC9106] apply. Parameters are encoded as a sequence of ASCII key-value pairs separated by ASCII commas. The key and value in each pair are separated by a single ASCII equals sign ('='). The keys for the parameters are the single letter identifiers assigned by [RFC9106], the values are encoded as decimal numbers with no digit delimiters or separators.¶
Example of the encoding of the parameters number of passes = 1, degree of parallelism = 4 and memory size = 2 GiB (i.e. 2^21 KiB) using the above rules:¶
m=2097152,t=1,p=4¶
This section describes the required information for SASL mechanisms as laid out in [RFC4422], Section 5.¶
1) "OPAQUE-A255SHA" and "OPAQUE-A255SHA-PLUS"¶
2a) OPAQUE is a client-first mechanism¶
2b) OPAQUE does not send any additional data to indicate a successful outcome. All authentication exchanges take 3 messages regardless of success.¶
3) OPAQUE can transfer authorization identities from the client to the server.¶
4) OPAQUE does not offer security layers but allows channel binding.¶
5) OPAQUE uses a MAC to protect the integrity of the entire authentication exchange including the authzid.¶
OPAQUE supports binding the authentication to an underlying secure transport. Support for channel binding is optional, therefore the usage of channel binding is negotiable.¶
The negotiation of channel binding is performed as defined in [RFC5802], Section 6 with the following differences:¶
'tls-exporter' is the default channel binding type for any application that do not specify one.¶
Servers MUST implement the 'tls-exporter' [RFC9266] channel binding type if they implement any channel binding and make use of TLS-1.3 [RFC8446]. Clients SHOULD implement the 'tls-exporter' [RFC9266] channel binding type if they implement any channel binding and make use of TLS-1.3.¶
Server and clients SHOULD implement the 'tls-unique' [RFC5929] channel binding if they implement channel binding and make use of TLS-1.2. If a server or client implements 'tls-unique' they MUST ensure appropriate protection from the [TripleHandshake] vulnerability using e.g. the Extended Master Secret Extension [RFC7627].¶
Servers MUST use the channel binding type indicated by the client, or fail authentication if they do not support it.¶
The following syntax specification is written in Augmented Backus-Naur Form (ABNF) notation as specified in [RFC5234]. The non-terminals "UTF8-2", "UTF8-3" and "UTF8-4" are defined in [RFC3629].¶
The syntax is based in large parts on [RFC5802], Section 7, which may be referenced for clarification. If this specification and [RFC5802] are in conflict, this specification takes priority.¶
Used definitions from [RFC5802] are reproduced here for convenience:¶
ALPHA = <as defined in RFC 5234 appendix B.1> DIGIT = <as defined in RFC 5234 appendix B.1> UTF8-2 = <as defined in RFC 3629 (STD 63)> UTF8-3 = <as defined in RFC 3629 (STD 63)> UTF8-4 = <as defined in RFC 3629 (STD 63)> attr-val = ALPHA "=" value ;; Generic syntax of any attribute sent ;; by server or client value = 1*value-char value-safe-char = %x01-2B / %x2D-3C / %x3E-7F / UTF8-2 / UTF8-3 / UTF8-4 ;; UTF8-char except NUL, "=", and ",". value-char = value-safe-char / "=" printable = %x21-2B / %x2D-7E ;; Printable ASCII except ",". ;; Note that any "printable" is also ;; a valid "value". base64-char = ALPHA / DIGIT / "/" / "+" base64-4 = 4base64-char base64-3 = 3base64-char "=" base64-2 = 2base64-char "==" base64 = *base64-4 [base64-3 / base64-2] posit-number = %x31-39 *DIGIT ;; A positive number. saslname = 1*(value-safe-char / "=2C" / "=3D") ;; Conforms to <value>. authzid = "a=" saslname ;; Protocol specific. cb-name = 1*(ALPHA / DIGIT / "." / "-") ;; See RFC 5056, Section 7. ;; E.g., "tls-server-end-point" or ;; "tls-unique". gs2-cbind-flag = ("p=" cb-name) / "n" / "y" ;; "n" -> client doesn't support channel binding. ;; "y" -> client does support channel binding ;; but thinks the server does not. ;; "p" -> client requires channel binding. ;; The selected channel binding follows "p=". gs2-header = gs2-cbind-flag "," [ authzid ] "," ;; GS2 header for OPAQUE username = "n=" saslname ;; Usernames are prepared using SASLprep. reserved-mext = "m=" 1*(value-char) ;; Reserved for signaling mandatory extensions. ;; The exact syntax will be defined in ;; the future. channel-binding = "c=" base64 ;; base64 encoding of cbind-input. cbind-data = 1*OCTET cbind-input = gs2-header [ cbind-data ] ;; cbind-data MUST be present for ;; gs2-cbind-flag of "p" and MUST be absent ;; for "y" or "n".¶
The following definitions are specific to OPAQUE:¶
ke1 = "r=" base64 ;; base64 encoding of the OPAQUE KE1 message struct ke2 = "v=" base64 ;; base64 encoding of the OPAQUE KE2 message struct ke3 = "p=" base64 ;; base64 encoding of the OPAQUE KE3 message struct ksf-params = "i=" base64 ;; base64 encoding of KSF parameters client-first-message-bare = [reserved-mext ","] username "," ke1 ["," extensions] client-first-message = gs2-header client-first-message-bare server-message-bare = [reserved-mext ","] channel-binding "," ksf-params ["," extensions] server-message = server-message-bare "," ke2 client-final-message = ke3¶
The KSF parameters and channel bindings aren't authenticated before KSF usage, allowing a DoS of a client by an malicious actor posing as the server, as it can send excessively expensive KSF parameters.¶
If not used with a secure channel providing confidentiality this mechanism leaks the authid and authzid of an authenticating user to any passive observer.¶
The cryptographic security of this mechanism is not increased over the one provided by the underlying OPAQUE protocol, so all security considerations listed in the [OPAQUE] specification also apply to this one.¶
A future revision of this document will request a new registry for the OPAQUE family of SASL mechanism, outlining all required details on the primitives used by the 'OPAQUE-A255SHA' variant.¶
Thank you to Daniel Bourdrez, Hugo Krawczyk, Kevin Lewi, and C. A. Wood for their work on the OPAQUE PAKE that this mechanism is based on. Thank you to Abhijit Menon-Sen, Alexey Melnikov, Nicolas Williams, and Chris Newman for their work on the SCRAM RFC, most of which this draft oh so blatanly steals for its own gain.¶