1. Introduction

This document introduces an extension to the PSA Cryptography API [PSA-CRYPT] specification, to provide support for Password-authenticated key exchange (PAKE) algorithms, and specifically for the J-PAKE algorithm.

When the proposed extension is sufficiently stable to be classed as Final, it will be integrated into a future version of [PSA-CRYPT].

This specification must be read and implemented in conjunction with [PSA-CRYPT]. All of the conventions, design considerations, and implementation considerations that are described in [PSA-CRYPT] apply to this specification.

Note

This extension has been developed in conjunction with the Mbed TLS [MBED-TLS] project, which is developing an implementation of the PSA Cryptography API.

Note

This version of the document includes Rationale commentary that provides background information relating to the design decisions that led to the current proposal. This enables the reader to understand the wider context and alternative approaches that have been considered.

The rationale is presented in green boxes, as this note is.

1.1. Objectives for the PAKE Extension

1.1.1. Scheme review

There are a number of PAKE protocols in circulation, but none of them are used widely in practice, and they are very different in scope and mechanics. The API proposed for the PSA Cryptography API focuses on schemes that are most likely to be needed by users. A number of factors are used to identify important PAKE algorithms.

Wide deployment

Considering PAKE schemes with already wide deployment allows users with existing applications to migrate to PSA. Currently there is only one scheme with non-negligible success in the industry: Secure Remote Password (SRP).

Requests

Some PAKE schemes have been requested by the community and need to be supported. Currently, these are SPAKE2+ and J-PAKE (in particular the Elliptic Curve based variant, sometimes known as ECJPAKE)

Standardization

There are PAKE schemes that are being standardized and will be recommended for use in future protocols. To ensure that the API is future proof, we need to consider these. The CFRG recommends CPace and OPAQUE for use in IETF protocols. These are also recommended for use in TLS and IKE in the future.

Applications

Some of these schemes are used in popular protocols. This information confirms the choices already made and can help to extend the list in future:

PAKE scheme Protocols
J-PAKE TLS, THREAD v1
SPAKE2+ CHIP
SRP TLS
OPAQUE TLS, IKE
CPace TLS, IKE
Dragonfly WPA3 (Before including the Dragonblood attack should be considered as well.)
SPAKE Kerberos 5 v1.17
PACE IKEv2
AugPAKE IKEv2

1.1.2. Scope of the PAKE Extension

The following PAKE schemes are considered in the PSA Crypto API design:

Balanced Augmented

J-PAKE

SPAKE2

CPace

SRP

SPAKE2+

OPAQUE

Scope of this specification

The current API proposal provides the general interface for PAKE algorithms, and the specific interface for J-PAKE.

Out of scope

PAKE protocols that do not fit into any of the above categories are not taken into consideration in the proposed API. Some schemes like that are:

PAKE scheme Specification
AMP IEEE 1363.2, ISO/IEC 11770-4
BSPEKE2 IEEE 1363.2
PAKZ IEEE 1363.2
PPK IEEE 1363.2
SPEKE IEEE 1363.2
WSPEKE IEEE 1363.2
SPEKE IEEE 1363.2
PAK IEEE 1363.2, X.1035, RFC 5683
EAP-PWD RFC 5931
EAP-EKE RFC 6124
IKE-PSK RFC 6617
PACE for IKEv2 RFC 6631
AugPAKE for IKEv2 RFC 6628
PAR IEEE 1363.2
SESPAKE RFC 8133
ITU-T X.1035
SPAKE1  
Dragonfly  
B-SPEKE  
PKEX  
EKE  
Augmented-EKE  
PAK-X  
PAKE  

The exception is SPAKE2, because of it is related to SPAKE2+.