The OPAQUE Asymmetric PAKE Protocol
draft-krawczyk-cfrg-opaque-01
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Replaced".
Expired & archived
|
|
|---|---|---|---|
| Author | Dr. Hugo Krawczyk | ||
| Last updated | 2019-07-03 (Latest revision 2018-12-30) | ||
| Replaced by | draft-irtf-cfrg-opaque, draft-irtf-cfrg-opaque | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | Expired | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
This Internet-Draft is no longer active. A copy of the expired Internet-Draft is available in these formats:
Abstract
This draft describes the OPAQUE protocol, a secure asymmetric password authenticated key exchange (aPAKE) that supports mutual authentication in a client-server setting without any reliance on PKI. OPAQUE is the first PKI-free aPAKE to accommodate secret salt and therefore it is the first to be secure against pre-computation attacks upon server compromise. In contrast, prior aPAKE protocols did not use salt and if they did, the salt was transmitted in the clear from server to user allowing for the building of targeted pre-computed dictionaries. OPAQUE security has been proven by Jarecki et al. (Eurocrypt 2018) in a strong and universally composable formal model of aPAKE security. In addition, the protocol provides forward secrecy and the ability to hide the password from the server even during password registration. Strong security, good performance and an array of additional features make OPAQUE a natural candidate for practical use and for adoption as a standard. To this end, this draft presents several optimized instantiations of OPAQUE and ways of integrating OPAQUE with TLS.
Authors
(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)