A SASL and GSS-API Mechanism family using the asymmetric password-authenticated key agreement OPAQUE

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 9 April 2023.¶

Copyright Notice

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

Table of Contents

1. 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

2. Introduction

This specification describes a family of authentication mechanisms 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.¶

OPAQUE as 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 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. * Successfull authentication does not grant the server enough information to impersonate the client. * Mutual authentication is implicit and required. A successfull authentication always strongly authenticates both sides of the exchange. * A successfull authentication provides both parties with an emphemeral 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 successfull 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.¶

3. 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 authentication exchange. Nothing in OPAQUE 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 posession of an username and password. It uses the password to generate a KE1 structure as per OPAQUE [I-D.irtf-cfrg-opaque], and sends it 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 used at registration. It uses the first three to generate a KE2 structure as per OPAQUE [I-D.irtf-cfrg-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 it can return to the server.¶

The three messages KE1, KE2 and KE3 are generated using the following functions specified in OPAQUE [I-D.irtf-cfrg-opaque]:¶

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:¶

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, 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.¶

4. OPAQUE Mechanism Names

An OPAQUE mechanism name is the string "OPAQUE-" followed by an uppercase identifier for the cryptographic primitives being used. The identifier is limited to 7 octets (20 - len("OPAQUE-") - len("-PLUS")) which is too short to contain the full names of all cryptographic primitives used. Thus OPAQUE mechanisms using new groups of primitives SHOULD be registered with IANA to allow implementers to identify all required primitives.¶

The PLUS suffix is only used when the authenticating parties support channel binding. If the server supports channel binding it SHOULD advertise both the "bare" and "plus" version of whichever OPAQUE variant it support. If the server does not it will only advertise the "bare" version.¶

5. OPAQUE Authentication Exchange

C: n,,n=user,r=<ke1>
S: c=<cbdata>,i=<params>,v=<ke2>
C: p=<ke3>

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, containting 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 long term private key and client-only export key 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.¶

6. 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 [RFC5802], Section 6 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.¶

7. OPAQUE-A255SHA(-PLUS)

TODO: Define one set of primitives; probably OPAQUE-A255SHA(-PLUS), using HKDF, HMAC, ristretto255, SHA-512 and Argon2i(d?)¶

8. Formal Syntax

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 speification 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:¶

client-first-message-bare =
            [reserved-mext ","] username "," auth-request
            ["," extensions]

client-first-message = gs2-header client-first-message-bare

validator = "v=" base64

server-message-bare =
            [reserved-mext ","] channel-binding "," ksf-params ","
            credentials-response ["," extensions]

server-message = server-message-bare "," validator

client-final-message = "p=" base64

9. 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.¶

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 algorithm, so all security considerations applying to that specification also apply to this one.¶

10. Open Issues

• OPAQUE allows for a static context to be bound into generated keys to prevent cross-protocol and downgrade attacks. We should probably set that to the mechanism name (e.g. 'OPAQUE-A255SHA')¶
• 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.¶

11. IANA Considerations

The IANA is requested to add the following family of SASL mechanisms to the SASL Mechanism registry established by [RFC4422]:¶

To: iana@iana.org Subject: Registration of new SASL family OPAQUE¶

SASL mechanism name (or prefix for the family): OPAQUE- Security Considerations: See this document Published Specification: See this document For futher information: Contact the authors of this document. Owner/Change controller: the IETF Note: None¶

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

Author's Address