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