OPAQUE SASL Mechanism

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 16 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

OPAQUE is an efficient, versatile, modern cryptographic primitive with strong security guarantees that goes beyond what existing SASL mechanisms provide. One of the most important features is that the user's password or anything derived from it is neither exposed to the server nor in the protocol. Another important security property is that replay attacks are not possible. OPAQUE can be used can be used over plaintext channels, although the lack of binding between authentication and the rest of the protocol usually form an independent reason to not use that.¶

The closest SASL authentication mechanism to OPAQUE is SRP [RFC2945], which is vulnerable to pre-computation attacks, lacks proof of security, and is less efficient than OPAQUE. Moreover, SRP requires a ring as it mixes addition and multiplication operations, and thus does not work over standard elliptic curves. OPAQUE is therefore a suitable replacement for applications that use SRP.¶

3. Notation

All protocol messages and structures defined in this document use the syntax from [RFC8446], Section 3.¶

4. Protocol overview

This specification instantiates OPAQUE-3DH with the following configuration tuple ([OPAQUE] configurations section): (OPRF(ristretto255, SHA-512), HKDF-SHA-512, HMAC-SHA-512, SHA-512, argon2i(67108864, 2), ristretto255). The sizes of all message components are set accordingly.¶

The messages closely follow the specification of OPAQUE AKE messsages([OPAQUE] AKE messages section), and any field names and calls not defined herein are clarified in that specification.¶

SASL OPAQUE is a client-initiated mechanism. In total 3 messages are necessary to authenticate the client to the server.¶

struct {
    // credential request
    u8 blinded_hashed_to_curve_password[32];
    u8 ephemeral_user_public_key[32];
    u8 user_nonce[32];
    // end of credential request
    u8 userid[]; // utf8 null-terminated
    u8 authid[]; // utf8 null-terminated
} request;

struct {
  // credential_response
  u8 evaluated_message[32];
  u8 masking_nonce[32];
  u8 longterm_server_public_key[32];
  u8 envelope_nonce[32];
  u8 envelope_auth_tag[64];
  u8 nonceS[32];
  u8 ephemeral_server_public_key[32];
  u8 auth[64];
  // end of credential response
  u8 realm[]; // utf8 null-terminated.
} response;

struct {
  u8 auth[64];
} client_auth_token;

5. Security Considerations

OPAQUE guarantees that the users passwords are never exposed to the server (see registration caveat below). This protects against the users passwords being logged as plaintext, or other exposure when TLS may fail, including PKI attacks, certificate mishandling, termination outside the security perimeter, visibility to TLS-terminating intermediaries.¶

OPAQUE also provides an optional enumeration mitigation by responding with a fake "response" to requests for non-existing clients. This is something that the server implementation should support. For more details on this see the "preventing-client-enumeration" section of the OPAQUE[OPAQUE] RFC.¶

The security considerations of the OPAQUE[OPAQUE] RFC also apply to the SASL mechanism. Additional security considerations are:¶

1. This SASL mechanism specification does not define channel binding, however it is possible to achieve this by adding the channel binding information to the user and server name. The details of this depend strongly on the channel being bound. The OPAQUE RFC notes this: > In principle, identities may change across different sessions as > long as there is a policy that can establish if the identity is > acceptable or not to the peer.¶
2. This specification does not define a secure layer protocol, despite OPAQUE lends itself perfectly to establish the keying of such. It is debatable what kind of SL could be initialized from OPAQUE, it could be a simple XChacha20/Poly1305[XCHACHA20] channel, some form of Double-Ratchet[_3DH], or even using TLS [TLSv1.3] PSK_KE mode all these variants have their pros and cons.¶
3. The OPAQUE RFC only specifies the 4 step password-privacy-protecting registration procedure, which does not apply to how SASL creates new users. With SASL new users are usually added on the server by using a tool like saslpasswd2 which creates the accounts for all SASL supported mechanisms, and thus the users password is exposed to the server. On one hand this violates one of OPAQUEs strengths, never exposing the password to the server, but on the other hand it enables the server to enforce password quality rules. It is warmly recommended for implementers to provide means to create new users by applying the 4 step procedure also specified by the OPAQUE RFC.¶

4. Key-Stretching Functions (such as Argon2 [ARGON2], scrypt [SCRYPT], and PBKDF2 [PBKDF2]) are only executed and used on the client. This has a couple consequences:¶

   • it eliminates a resource-exhaustion DoS attack vector against the server.¶
   • implementers must consider low-resource clients which might be overwhelmed by overly resource-intensive KSF configurations.¶
   • clients can choose their KSF independently of the server, the only important detail is that all clients must use the same KSF config for the same user record. Client KSF configuration might be stored at client side in a configuration, although this eliminates one of the benefits of OPAQUE of not needing any info besides the user password on the client, but this might be unimportant for a lot of applications.¶

6. IANA Considerations

This document has no IANA actions.¶

Acknowledgments

TODO acknowledge.¶

Author's Address