]>

me@dequbed.space

AREA WG Working Group Internet-Draft 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. Discussion Venues Discussion of this document takes place on the Common Authentication Technology Next Generation Working Group mailing list (kitten@ietf.org), which is archived at . Source for this draft and an issue tracker can be found at .

Conventions and Definitions 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 when, and only when, they appear in all capitals, as shown here.

Introduction 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" . 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 authentication information stored in an authentication database on the server is not sufficient to impersonate the client. It is additionally salted and bound to a private key of the server, making pre-stored dictionary attack impossible.
• Successful authentication does not grant the server enough information to impersonate the client.
• Mutual authentication is implicit and required. A successful authentication always strongly authenticates both sides of the exchange.
• A successful authentication provides both parties with an ephemeral shared secret. This secret has high entropy and can be used to establish a trusted encrypted channel without deriving trust from a 3rd party.
• A successful authentication additionally provides the client with a constant secret. This secret is only known to the client and the same for every authentication. It can be used to e.g. store encrypted data on the server without having to manage keys locally.

OPAQUE Algorithm Overview 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 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 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 with the configuration specified in Section : The values of client_identity and server_identity are set to the byte sequences: 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.

OPAQUE Mechanism Name 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.

OPAQUE-3DH configuration for OPAQUE-A255SHA(-PLUS) The OPAQUE-3DH configuration according to Section 7 of used by the OPAQUE-A255SHA mechanism is made up of the following cryptographic primitives:

• OPRF(ristretto255, SHA-512) as specified in
• HKDF using SHA-512 as KDF
• HMAC using SHA-512 as MAC
• SHA-512 as Hash
• Argon2id as KSF, with the remaining parameters being set during an authentication exchange
• The same ristretto255 group used by the OPRF as Group
• The ASCII-String "SASL-OPAQUE-A255SHA" as Context

Implementations of this mechanism SHOULD default to Argon2id parameters of (t=1, p=4, m=2^21).

OPAQUE Authentication Exchange An example of an OPAQUE-A255SHA authentication exchange consisting of three messages, send by the client, server and client respectively: S: c=biws,i=bT0yMDk3MTUyLHQ9MSxwPTQ=,v= C: p= ]]> First, the client sends the "client-first-message" containing:

• A GS2 header consisting of a flag indicating channel binding support and usage, and an optional SASL authorization identity.
• The authentication ID (AuthID) of the user.
• OPAQUE KE1, containing the OPRF credential request, a nonce, and an ephemeral public key.

In response the server sends the "server-message" containing:

• An encoding of requested channel binding data
• Parameters for the KSF that needs to be used by the client
• OPAQUE KE2, containing the OPRF credential response, a nonce, and an ephemeral public key.
• A MAC proving the integrity of the exchange so far and cryptographically authenticating the server to the client (also contained in KE2)

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.

OPAQUE Attributes 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 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.

• a: This is an optional attribute and is part of the GS2 bridge between GSS-API and SASL. Its specification and usage is the same as defined in .
• n: This attribute specifies the name of the user whose password is used for authentication (aka "authentication identity" ). Its encoding, preparation, and usage is the same as defined in .
• m: This attribute is reserved for future extensibility. In this version of OPAQUE its presence in a client or server message MUST cause authentication failure when the attribute is parsed by the other end.
• r: This attribute specifies a base64-encoded serialization of the KE1 message as specified by .
• c: This REQUIRED attribute specifies the base64-encoded GS2 header and channel binding data. Its specification is the same as defined in , however it is sent by the server to the client instead of the other way around as in SCRAM.
• i: This attribute specifies base64-encoded parameters for the KSF to be used. The format of the parameters is specific in Section .
• v: This attribute specifies a base64-encoded serialization of the KE2 message as specified by .
• p: This attribute specifies a base64-encoded serialization of the KE3 message as specified by .
• Further as of now unspecified mandatory and optional extensions. Mandatory extensions are encoded using the "m" attribute, optional attributes may use any unassigned attribute name. Unknown optional attributes MUST be ignored upon receipt.

KSF parameter encoding The Argon2id 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. ; should we wait on that or specify our own format? The limits and interpretation of the parameters set in 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 , 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:

SASL Mechanism Requirements This section describes the required information for SASL mechanisms as laid out in . 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.

Channel Binding 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 with the following differences:

• The non-PLUS and PLUS variants of the mechanism are instead named OPAQUE-<variant> and OPAQUE-<variant>-PLUS respectively.
• As it is the server who sends the channel binding data the client is responsible to verify this data by constructing the expected value of the "c=" attribute and comparing it to the received one. This comparison SHOULD be implemented to be constant-time.

Default Channel Binding 'tls-exporter' is the default channel binding type for any application that do not specify one. Servers MUST implement the 'tls-exporter' channel binding type if they implement any channel binding and make use of TLS-1.3 . Clients SHOULD implement the 'tls-exporter' channel binding type if they implement any channel binding and make use of TLS-1.3. Server and clients SHOULD implement the 'tls-unique' 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 vulnerability using e.g. the Extended Master Secret Extension . Servers MUST use the channel binding type indicated by the client, or fail authentication if they do not support it.

Formal Syntax The following syntax specification is written in Augmented Backus-Naur Form (ABNF) notation as specified in . The non-terminals "UTF8-2", "UTF8-3" and "UTF8-4" are defined in . The syntax is based in large parts on , which may be referenced for clarification. If this specification and are in conflict, this specification takes priority. Used definitions from are reproduced here for convenience: DIGIT = UTF8-2 = UTF8-3 = UTF8-4 = 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 . 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:

Security Considerations 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 specification also apply to this one.

Open Issues

• With the current design the KSF parameters can not be MAC-verified until after they have been used. This is bad. The only other option is using the ephemeral keypair to generate a MAC key and use that. This may impact security.
• This mechanism should be extended to also become a GSS-API mechanism like SCRAM is.

IANA Considerations 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.

References Normative References This document describes how to use a Generic Security Service Application Program Interface (GSS-API) mechanism in the Simple Authentication and Security Layer (SASL) framework. This is done by defining a new SASL mechanism family, called GS2. This mechanism family offers a number of improvements over the previous "SASL/ GSSAPI" mechanism: it is more general, uses fewer messages for the authentication phase in some cases, and supports negotiable use of channel binding. Only GSS-API mechanisms that support channel binding and mutual authentication are supported. [STANDARDS-TRACK] The secure authentication mechanism most widely deployed and used by Internet application protocols is the transmission of clear-text passwords over a channel protected by Transport Layer Security (TLS). There are some significant security concerns with that mechanism, which could be addressed by the use of a challenge response authentication mechanism protected by TLS. Unfortunately, the challenge response mechanisms presently on the standards track all fail to meet requirements necessary for widespread deployment, and have had success only in limited use. This specification describes a family of Simple Authentication and Security Layer (SASL; RFC 4422) authentication mechanisms called the Salted Challenge Response Authentication Mechanism (SCRAM), which addresses the security concerns and meets the deployability requirements. When used in combination with TLS or an equivalent security layer, a mechanism from this family could improve the status quo for application protocol authentication and provide a suitable choice for a mandatory-to-implement mechanism for future application protocol standards. [STANDARDS-TRACK] Internet technical specifications often need to define a formal syntax. Over the years, a modified version of Backus-Naur Form (BNF), called Augmented BNF (ABNF), has been popular among many Internet specifications. The current specification documents ABNF. It balances compactness and simplicity with reasonable representational power. The differences between standard BNF and ABNF involve naming rules, repetition, alternatives, order-independence, and value ranges. This specification also supplies additional rule definitions and encoding for a core lexical analyzer of the type common to several Internet specifications. [STANDARDS-TRACK] ISO/IEC 10646-1 defines a large character set called the Universal Character Set (UCS) which encompasses most of the world's writing systems. The originally proposed encodings of the UCS, however, were not compatible with many current applications and protocols, and this has led to the development of UTF-8, the object of this memo. UTF-8 has the characteristic of preserving the full US-ASCII range, providing compatibility with file systems, parsers and other software that rely on US-ASCII values but are transparent to other values. This memo obsoletes and replaces RFC 2279. This document describes the Argon2 memory-hard function for password hashing and proof-of-work applications. We provide an implementer-oriented description with test vectors. The purpose is to simplify adoption of Argon2 for Internet protocols. This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF. This document defines a channel binding type, tls-exporter, that is compatible with TLS 1.3 in accordance with RFC 5056, "On the Use of Channel Bindings to Secure Channels". Furthermore, it updates the default channel binding to the new binding for versions of TLS greater than 1.2. This document updates RFCs 5801, 5802, 5929, and 7677. Algorand Foundation Novi Research Cloudflare, Inc. Work in Progress Brave Software Cloudflare, Inc. Cloudflare, Inc. Cloudflare, Inc. An Oblivious Pseudorandom Function (OPRF) is a two-party protocol between client and server for computing the output of a Pseudorandom Function (PRF). The server provides the PRF secret key, and the client provides the PRF input. At the end of the protocol, the client learns the PRF output without learning anything about the PRF secret key, and the server learns neither the PRF input nor output. An OPRF can also satisfy a notion of 'verifiability', called a VOPRF. A VOPRF ensures clients can verify that the server used a specific private key during the execution of the protocol. A VOPRF can also be partially-oblivious, called a POPRF. A POPRF allows clients and servers to provide public input to the PRF computation. This document specifies an OPRF, VOPRF, and POPRF instantiated within standard prime-order groups, including elliptic curves. This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This document specifies a simple Hashed Message Authentication Code (HMAC)-based key derivation function (HKDF), which can be used as a building block in various protocols and applications. The key derivation function (KDF) is intended to support a wide range of applications and requirements, and is conservative in its use of cryptographic hash functions. This document is not an Internet Standards Track specification; it is published for informational purposes. This document describes HMAC, a mechanism for message authentication using cryptographic hash functions. HMAC can be used with any iterative cryptographic hash function, e.g., MD5, SHA-1, in combination with a secret shared key. The cryptographic strength of HMAC depends on the properties of the underlying hash function. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind The Simple Authentication and Security Layer (SASL) is a framework for providing authentication and data security services in connection-oriented protocols via replaceable mechanisms. It provides a structured interface between protocols and mechanisms. The resulting framework allows new protocols to reuse existing mechanisms and allows old protocols to make use of new mechanisms. The framework also provides a protocol for securing subsequent protocol exchanges within a data security layer. This document describes how a SASL mechanism is structured, describes how protocols include support for SASL, and defines the protocol for carrying a data security layer over a connection. In addition, this document defines one SASL mechanism, the EXTERNAL mechanism. This document obsoletes RFC 2222. [STANDARDS-TRACK] This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations. This document defines three channel binding types for Transport Layer Security (TLS), tls-unique, tls-server-end-point, and tls-unique-for-telnet, in accordance with RFC 5056 (On Channel Binding). Note that based on implementation experience, this document changes the original definition of 'tls-unique' channel binding type in the channel binding type IANA registry. [STANDARDS-TRACK] The Transport Layer Security (TLS) master secret is not cryptographically bound to important session parameters such as the server certificate. Consequently, it is possible for an active attacker to set up two sessions, one with a client and another with a server, such that the master secrets on the two sessions are the same. Thereafter, any mechanism that relies on the master secret for authentication, including session resumption, becomes vulnerable to a man-in-the-middle attack, where the attacker can simply forward messages back and forth between the client and server. This specification defines a TLS extension that contextually binds the master secret to a log of the full handshake that computes it, thus preventing such attacks. Informative References INRIA Paris-Rocqencourt INRIA Paris-Rocqencourt Microsoft Research INRIA Paris-Rocqencourt IMDEA Software Institute miTLS

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