draft-irtf-cfrg-opaque-13.txt | draft-irtf-cfrg-opaque-14.txt | |||
---|---|---|---|---|
Network Working Group D. Bourdrez | Network Working Group D. Bourdrez | |||
Internet-Draft | Internet-Draft | |||
Intended status: Informational H. Krawczyk | Intended status: Informational H. Krawczyk | |||
Expires: 20 June 2024 AWS | Expires: 25 September 2024 AWS | |||
K. Lewi | K. Lewi | |||
Meta | Meta | |||
C. A. Wood | C. A. Wood | |||
Cloudflare, Inc. | Cloudflare, Inc. | |||
18 December 2023 | 24 March 2024 | |||
The OPAQUE Asymmetric PAKE Protocol | The OPAQUE Augmented PAKE Protocol | |||
draft-irtf-cfrg-opaque-13 | draft-irtf-cfrg-opaque-14 | |||
Abstract | Abstract | |||
This document describes the OPAQUE protocol, a secure asymmetric | This document describes the OPAQUE protocol, an augmented (or | |||
password-authenticated key exchange (aPAKE) that supports mutual | asymmetric) password-authenticated key exchange (aPAKE) that supports | |||
authentication in a client-server setting without reliance on PKI and | mutual authentication in a client-server setting without reliance on | |||
with security against pre-computation attacks upon server compromise. | PKI and with security against pre-computation attacks upon server | |||
In addition, the protocol provides forward secrecy and the ability to | compromise. In addition, the protocol provides forward secrecy and | |||
hide the password from the server, even during password registration. | the ability to hide the password from the server, even during | |||
This document specifies the core OPAQUE protocol and one | password registration. This document specifies the core OPAQUE | |||
instantiation based on 3DH. | protocol and one instantiation based on 3DH. | |||
Discussion Venues | Discussion Venues | |||
This note is to be removed before publishing as an RFC. | This note is to be removed before publishing as an RFC. | |||
Source for this draft and an issue tracker can be found at | Source for this draft and an issue tracker can be found at | |||
https://github.com/cfrg/draft-irtf-cfrg-opaque. | https://github.com/cfrg/draft-irtf-cfrg-opaque. | |||
Status of This Memo | Status of This Memo | |||
skipping to change at page 1, line 49 ¶ | skipping to change at page 1, line 49 ¶ | |||
Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
Drafts is at https://datatracker.ietf.org/drafts/current/. | Drafts is at https://datatracker.ietf.org/drafts/current/. | |||
Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
This Internet-Draft will expire on 20 June 2024. | This Internet-Draft will expire on 25 September 2024. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2023 IETF Trust and the persons identified as the | Copyright (c) 2024 IETF Trust and the persons identified as the | |||
document authors. All rights reserved. | document authors. All rights reserved. | |||
This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
Provisions Relating to IETF Documents (https://trustee.ietf.org/ | Provisions Relating to IETF Documents (https://trustee.ietf.org/ | |||
license-info) in effect on the date of publication of this document. | license-info) in effect on the date of publication of this document. | |||
Please review these documents carefully, as they describe your rights | Please review these documents carefully, as they describe your rights | |||
and restrictions with respect to this document. Code Components | and restrictions with respect to this document. Code Components | |||
extracted from this document must include Revised BSD License text as | extracted from this document must include Revised BSD License text as | |||
described in Section 4.e of the Trust Legal Provisions and are | described in Section 4.e of the Trust Legal Provisions and are | |||
provided without warranty as described in the Revised BSD License. | provided without warranty as described in the Revised BSD License. | |||
skipping to change at page 2, line 31 ¶ | skipping to change at page 2, line 31 ¶ | |||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 | |||
1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 5 | 1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 5 | |||
1.2. Notation . . . . . . . . . . . . . . . . . . . . . . . . 5 | 1.2. Notation . . . . . . . . . . . . . . . . . . . . . . . . 5 | |||
2. Cryptographic Dependencies . . . . . . . . . . . . . . . . . 6 | 2. Cryptographic Dependencies . . . . . . . . . . . . . . . . . 6 | |||
2.1. Oblivious Pseudorandom Function . . . . . . . . . . . . . 6 | 2.1. Oblivious Pseudorandom Function . . . . . . . . . . . . . 6 | |||
2.2. Key Derivation Function and Message Authentication | 2.2. Key Derivation Function and Message Authentication | |||
Code . . . . . . . . . . . . . . . . . . . . . . . . . . 7 | Code . . . . . . . . . . . . . . . . . . . . . . . . . . 7 | |||
2.3. Hash Functions . . . . . . . . . . . . . . . . . . . . . 8 | 2.3. Hash Functions . . . . . . . . . . . . . . . . . . . . . 8 | |||
3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 8 | 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 8 | |||
3.1. Setup . . . . . . . . . . . . . . . . . . . . . . . . . . 9 | 3.1. Setup . . . . . . . . . . . . . . . . . . . . . . . . . . 9 | |||
3.2. Offline Registration . . . . . . . . . . . . . . . . . . 9 | 3.2. Registration . . . . . . . . . . . . . . . . . . . . . . 9 | |||
3.3. Online Authenticated Key Exchange . . . . . . . . . . . . 10 | 3.3. Online Authenticated Key Exchange . . . . . . . . . . . . 10 | |||
4. Client Credential Storage and Key Recovery . . . . . . . . . 11 | 4. Client Credential Storage and Key Recovery . . . . . . . . . 11 | |||
4.1. Key Recovery . . . . . . . . . . . . . . . . . . . . . . 13 | 4.1. Key Recovery . . . . . . . . . . . . . . . . . . . . . . 13 | |||
4.1.1. Envelope Structure . . . . . . . . . . . . . . . . . 13 | 4.1.1. Envelope Structure . . . . . . . . . . . . . . . . . 13 | |||
4.1.2. Envelope Creation . . . . . . . . . . . . . . . . . . 13 | 4.1.2. Envelope Creation . . . . . . . . . . . . . . . . . . 13 | |||
4.1.3. Envelope Recovery . . . . . . . . . . . . . . . . . . 14 | 4.1.3. Envelope Recovery . . . . . . . . . . . . . . . . . . 14 | |||
5. Offline Registration . . . . . . . . . . . . . . . . . . . . 15 | 5. Registration . . . . . . . . . . . . . . . . . . . . . . . . 15 | |||
5.1. Registration Messages . . . . . . . . . . . . . . . . . . 17 | 5.1. Registration Messages . . . . . . . . . . . . . . . . . . 17 | |||
5.2. Registration Functions . . . . . . . . . . . . . . . . . 17 | 5.2. Registration Functions . . . . . . . . . . . . . . . . . 17 | |||
5.2.1. CreateRegistrationRequest . . . . . . . . . . . . . . 18 | 5.2.1. CreateRegistrationRequest . . . . . . . . . . . . . . 18 | |||
5.2.2. CreateRegistrationResponse . . . . . . . . . . . . . 18 | 5.2.2. CreateRegistrationResponse . . . . . . . . . . . . . 18 | |||
5.2.3. FinalizeRegistrationRequest . . . . . . . . . . . . . 19 | 5.2.3. FinalizeRegistrationRequest . . . . . . . . . . . . . 19 | |||
6. Online Authenticated Key Exchange . . . . . . . . . . . . . . 20 | 6. Online Authenticated Key Exchange . . . . . . . . . . . . . . 20 | |||
6.1. AKE Messages . . . . . . . . . . . . . . . . . . . . . . 23 | 6.1. AKE Messages . . . . . . . . . . . . . . . . . . . . . . 23 | |||
6.2. AKE Functions . . . . . . . . . . . . . . . . . . . . . . 24 | 6.2. AKE Functions . . . . . . . . . . . . . . . . . . . . . . 24 | |||
6.2.1. GenerateKE1 . . . . . . . . . . . . . . . . . . . . . 24 | 6.2.1. GenerateKE1 . . . . . . . . . . . . . . . . . . . . . 24 | |||
6.2.2. GenerateKE2 . . . . . . . . . . . . . . . . . . . . . 25 | 6.2.2. GenerateKE2 . . . . . . . . . . . . . . . . . . . . . 25 | |||
skipping to change at page 3, line 18 ¶ | skipping to change at page 3, line 18 ¶ | |||
6.4.3. 3DH Client Functions . . . . . . . . . . . . . . . . 35 | 6.4.3. 3DH Client Functions . . . . . . . . . . . . . . . . 35 | |||
6.4.4. 3DH Server Functions . . . . . . . . . . . . . . . . 37 | 6.4.4. 3DH Server Functions . . . . . . . . . . . . . . . . 37 | |||
7. Configurations . . . . . . . . . . . . . . . . . . . . . . . 39 | 7. Configurations . . . . . . . . . . . . . . . . . . . . . . . 39 | |||
8. Application Considerations . . . . . . . . . . . . . . . . . 40 | 8. Application Considerations . . . . . . . . . . . . . . . . . 40 | |||
9. Implementation Considerations . . . . . . . . . . . . . . . . 42 | 9. Implementation Considerations . . . . . . . . . . . . . . . . 42 | |||
9.1. Implementation Safeguards . . . . . . . . . . . . . . . . 42 | 9.1. Implementation Safeguards . . . . . . . . . . . . . . . . 42 | |||
9.2. Error Considerations . . . . . . . . . . . . . . . . . . 43 | 9.2. Error Considerations . . . . . . . . . . . . . . . . . . 43 | |||
10. Security Considerations . . . . . . . . . . . . . . . . . . . 43 | 10. Security Considerations . . . . . . . . . . . . . . . . . . . 43 | |||
10.1. Notable Design Differences . . . . . . . . . . . . . . . 44 | 10.1. Notable Design Differences . . . . . . . . . . . . . . . 44 | |||
10.2. Security Analysis . . . . . . . . . . . . . . . . . . . 47 | 10.2. Security Analysis . . . . . . . . . . . . . . . . . . . 47 | |||
10.3. Related Protocols . . . . . . . . . . . . . . . . . . . 48 | 10.3. Identities . . . . . . . . . . . . . . . . . . . . . . . 48 | |||
10.4. Identities . . . . . . . . . . . . . . . . . . . . . . . 48 | 10.4. Export Key Usage . . . . . . . . . . . . . . . . . . . . 49 | |||
10.5. Export Key Usage . . . . . . . . . . . . . . . . . . . . 50 | 10.5. Static Diffie-Hellman Oracles . . . . . . . . . . . . . 49 | |||
10.6. Static Diffie-Hellman Oracles . . . . . . . . . . . . . 50 | 10.6. Random-Key Robust MACs . . . . . . . . . . . . . . . . . 50 | |||
10.7. Random-Key Robust MACs . . . . . . . . . . . . . . . . . 50 | 10.7. Input Validation . . . . . . . . . . . . . . . . . . . . 50 | |||
10.8. Input Validation . . . . . . . . . . . . . . . . . . . . 50 | 10.8. OPRF Key Stretching . . . . . . . . . . . . . . . . . . 50 | |||
10.9. OPRF Key Stretching . . . . . . . . . . . . . . . . . . 51 | 10.9. Client Enumeration . . . . . . . . . . . . . . . . . . . 51 | |||
10.10. Client Enumeration . . . . . . . . . . . . . . . . . . . 51 | 10.10. Protecting the Registration Masking Key . . . . . . . . 51 | |||
10.11. Protecting the Registration Masking Key . . . . . . . . 52 | 10.11. Password Salt and Storage Implications . . . . . . . . . 52 | |||
10.12. Password Salt and Storage Implications . . . . . . . . . 52 | 10.12. AKE Private Key Storage . . . . . . . . . . . . . . . . 52 | |||
10.13. AKE Private Key Storage . . . . . . . . . . . . . . . . 52 | 10.13. Client Authentication Using Credentials . . . . . . . . 52 | |||
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 53 | 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 53 | |||
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 53 | 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 53 | |||
12.1. Normative References . . . . . . . . . . . . . . . . . . 53 | 12.1. Normative References . . . . . . . . . . . . . . . . . . 53 | |||
12.2. Informative References . . . . . . . . . . . . . . . . . 53 | 12.2. Informative References . . . . . . . . . . . . . . . . . 53 | |||
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 57 | Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 57 | |||
Appendix B. Alternate Key Recovery Mechanisms . . . . . . . . . 57 | Appendix B. Alternate Key Recovery Mechanisms . . . . . . . . . 57 | |||
Appendix C. Alternate AKE Instantiations . . . . . . . . . . . . 58 | Appendix C. Alternate AKE Instantiations . . . . . . . . . . . . 57 | |||
C.1. HMQV Instantiation Sketch . . . . . . . . . . . . . . . . 58 | C.1. HMQV Instantiation Sketch . . . . . . . . . . . . . . . . 58 | |||
C.2. SIGMA-I Instantiation Sketch . . . . . . . . . . . . . . 59 | C.2. SIGMA-I Instantiation Sketch . . . . . . . . . . . . . . 59 | |||
Appendix D. Test Vectors . . . . . . . . . . . . . . . . . . . . 59 | Appendix D. Test Vectors . . . . . . . . . . . . . . . . . . . . 59 | |||
D.1. Real Test Vectors . . . . . . . . . . . . . . . . . . . . 60 | D.1. Real Test Vectors . . . . . . . . . . . . . . . . . . . . 60 | |||
D.1.1. OPAQUE-3DH Real Test Vector 1 . . . . . . . . . . . . 60 | D.1.1. OPAQUE-3DH Real Test Vector 1 . . . . . . . . . . . . 60 | |||
D.1.2. OPAQUE-3DH Real Test Vector 2 . . . . . . . . . . . . 63 | D.1.2. OPAQUE-3DH Real Test Vector 2 . . . . . . . . . . . . 63 | |||
D.1.3. OPAQUE-3DH Real Test Vector 3 . . . . . . . . . . . . 66 | D.1.3. OPAQUE-3DH Real Test Vector 3 . . . . . . . . . . . . 66 | |||
D.1.4. OPAQUE-3DH Real Test Vector 4 . . . . . . . . . . . . 69 | D.1.4. OPAQUE-3DH Real Test Vector 4 . . . . . . . . . . . . 69 | |||
D.1.5. OPAQUE-3DH Real Test Vector 5 . . . . . . . . . . . . 72 | D.1.5. OPAQUE-3DH Real Test Vector 5 . . . . . . . . . . . . 72 | |||
D.1.6. OPAQUE-3DH Real Test Vector 6 . . . . . . . . . . . . 74 | D.1.6. OPAQUE-3DH Real Test Vector 6 . . . . . . . . . . . . 74 | |||
skipping to change at page 4, line 20 ¶ | skipping to change at page 4, line 20 ¶ | |||
This makes the password vulnerable to server mishandling, including | This makes the password vulnerable to server mishandling, including | |||
accidentally logging the password or storing it in plaintext in a | accidentally logging the password or storing it in plaintext in a | |||
database. Server compromise resulting in access to these plaintext | database. Server compromise resulting in access to these plaintext | |||
passwords is not an uncommon security incident, even among security- | passwords is not an uncommon security incident, even among security- | |||
conscious organizations. Moreover, plaintext password authentication | conscious organizations. Moreover, plaintext password authentication | |||
over secure channels such as TLS is also vulnerable to cases where | over secure channels such as TLS is also vulnerable to cases where | |||
TLS may fail, including PKI attacks, certificate mishandling, | TLS may fail, including PKI attacks, certificate mishandling, | |||
termination outside the security perimeter, visibility to TLS- | termination outside the security perimeter, visibility to TLS- | |||
terminating intermediaries, and more. | terminating intermediaries, and more. | |||
Asymmetric (or Augmented) Password Authenticated Key Exchange (aPAKE) | Augmented (or Asymmetric) Password Authenticated Key Exchange (aPAKE) | |||
protocols are designed to provide password authentication and | protocols are designed to provide password authentication and | |||
mutually authenticated key exchange in a client-server setting | mutually authenticated key exchange in a client-server setting | |||
without relying on PKI (except during client registration) and | without relying on PKI (except during client registration) and | |||
without disclosing passwords to servers or other entities other than | without disclosing passwords to servers or other entities other than | |||
the client machine. A secure aPAKE should provide the best possible | the client machine. A secure aPAKE should provide the best possible | |||
security for a password protocol. Indeed, some attacks are | security for a password protocol. Indeed, some attacks are | |||
inevitable, such as online impersonation attempts with guessed client | inevitable, such as online impersonation attempts with guessed client | |||
passwords and offline dictionary attacks upon the compromise of a | passwords and offline dictionary attacks upon the compromise of a | |||
server and leakage of its credential file. In the latter case, the | server and leakage of its credential file. In the latter case, the | |||
attacker learns a mapping of a client's password under a one-way | attacker learns a mapping of a client's password under a one-way | |||
skipping to change at page 4, line 42 ¶ | skipping to change at page 4, line 42 ¶ | |||
the password. Crucially important is for the password protocol to | the password. Crucially important is for the password protocol to | |||
use an unpredictable one-way mapping. Otherwise, the attacker can | use an unpredictable one-way mapping. Otherwise, the attacker can | |||
pre-compute a deterministic list of mapped passwords leading to | pre-compute a deterministic list of mapped passwords leading to | |||
almost instantaneous leakage of passwords upon server compromise. | almost instantaneous leakage of passwords upon server compromise. | |||
This document describes OPAQUE, an aPAKE that is secure against pre- | This document describes OPAQUE, an aPAKE that is secure against pre- | |||
computation attacks (as defined in [JKX18]). OPAQUE provides forward | computation attacks (as defined in [JKX18]). OPAQUE provides forward | |||
secrecy with respect to password leakage while also hiding the | secrecy with respect to password leakage while also hiding the | |||
password from the server, even during password registration. OPAQUE | password from the server, even during password registration. OPAQUE | |||
allows applications to increase the difficulty of offline dictionary | allows applications to increase the difficulty of offline dictionary | |||
attacks via iterated hashing or other key stretching schemes. OPAQUE | attacks via iterated hashing or other key-stretching schemes. OPAQUE | |||
is also extensible, allowing clients to safely store and retrieve | is also extensible, allowing clients to safely store and retrieve | |||
arbitrary application data on servers using only their password. | arbitrary application data on servers using only their password. | |||
OPAQUE is defined and proven as the composition of three | OPAQUE is defined and proven as the composition of three | |||
functionalities: an oblivious pseudorandom function (OPRF), a key | functionalities: an oblivious pseudorandom function (OPRF), a key | |||
recovery mechanism, and an authenticated key exchange (AKE) protocol. | recovery mechanism, and an authenticated key exchange (AKE) protocol. | |||
It can be seen as a "compiler" for transforming any suitable AKE | It can be seen as a "compiler" for transforming any suitable AKE | |||
protocol into a secure aPAKE protocol. (See Section 10 for | protocol into a secure aPAKE protocol. (See Section 10 for | |||
requirements of the OPRF and AKE protocols.) This document specifies | requirements of the OPRF and AKE protocols.) This document specifies | |||
one OPAQUE instantiation based on [TripleDH]. Other instantiations | one OPAQUE instantiation based on [TripleDH]. Other instantiations | |||
skipping to change at page 5, line 20 ¶ | skipping to change at page 5, line 20 ¶ | |||
OPAQUE consists of two stages: registration and authenticated key | OPAQUE consists of two stages: registration and authenticated key | |||
exchange. In the first stage, a client registers its password with | exchange. In the first stage, a client registers its password with | |||
the server and stores information used to recover authentication | the server and stores information used to recover authentication | |||
credentials on the server. Recovering these credentials can only be | credentials on the server. Recovering these credentials can only be | |||
done with knowledge of the client password. In the second stage, a | done with knowledge of the client password. In the second stage, a | |||
client uses its password to recover those credentials and | client uses its password to recover those credentials and | |||
subsequently uses them as input to an AKE protocol. This stage has | subsequently uses them as input to an AKE protocol. This stage has | |||
additional mechanisms to prevent an active attacker from interacting | additional mechanisms to prevent an active attacker from interacting | |||
with the server to guess or confirm clients registered via the first | with the server to guess or confirm clients registered via the first | |||
phase. Servers can use this mechanism to safeguard registered | phase. Servers can use this mechanism to safeguard registered | |||
clients against this type of enumeration attack; see Section 10.10 | clients against this type of enumeration attack; see Section 10.9 for | |||
for more discussion. | more discussion. | |||
The name OPAQUE is a homonym of O-PAKE where O is for Oblivious. The | The name OPAQUE is a homonym of O-PAKE where O is for Oblivious. The | |||
name OPAKE was taken. | name OPAKE was taken. | |||
This draft complies with the requirements for PAKE protocols set | This draft complies with the requirements for PAKE protocols set | |||
forth in [RFC8125]. | forth in [RFC8125]. | |||
1.1. Requirements Notation | 1.1. Requirements Notation | |||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
skipping to change at page 7, line 4 ¶ | skipping to change at page 7, line 4 ¶ | |||
Nseed bytes, respectively, where Nn = Nseed = 32. | Nseed bytes, respectively, where Nn = Nseed = 32. | |||
2.1. Oblivious Pseudorandom Function | 2.1. Oblivious Pseudorandom Function | |||
An Oblivious Pseudorandom Function (OPRF) is a two-party protocol | An Oblivious Pseudorandom Function (OPRF) is a two-party protocol | |||
between client and server for computing a PRF, where the PRF key is | between client and server for computing a PRF, where the PRF key is | |||
held by the server and the input to the function is provided by the | held by the server and the input to the function is provided by the | |||
client. The client does not learn anything about the PRF other than | client. The client does not learn anything about the PRF other than | |||
the obtained output and the server learns nothing about the client's | the obtained output and the server learns nothing about the client's | |||
input or the function output. This specification depends on the | input or the function output. This specification depends on the | |||
prime-order OPRF construction specified in [OPRF], draft version -21, | prime-order OPRF construction specified in [RFC9497], using the OPRF | |||
using the OPRF mode (0x00) from [OPRF], Section 3.1. | mode (0x00) from [RFC9497], Section 3.1. | |||
The following OPRF client APIs are used: | The following OPRF client APIs are used: | |||
* Blind(element): Create and output (blind, blinded_element), | * Blind(element): Create and output (blind, blinded_element), | |||
consisting of a blinded representation of input element, denoted | consisting of a blinded representation of input element, denoted | |||
blinded_element, along with a value to revert the blinding | blinded_element, along with a value to revert the blinding | |||
process, denoted blind. | process, denoted blind. | |||
* Finalize(element, blind, evaluated_element): Finalize the OPRF | * Finalize(element, blind, evaluated_element): Finalize the OPRF | |||
evaluation using input element, random inverter blind, and | evaluation using input element, random inverter blind, and | |||
evaluation output evaluated_element, yielding output oprf_output. | evaluation output evaluated_element, yielding output oprf_output. | |||
Moreover, the following OPRF server APIs are used: | Moreover, the following OPRF server APIs are used: | |||
* BlindEvaluate(k, blinded_element): Evaluate blinded input element | * BlindEvaluate(k, blinded_element): Evaluate blinded input element | |||
blinded_element using input key k, yielding output element | blinded_element using input key k, yielding output element | |||
evaluated_element. This is equivalent to the BlindEvaluate | evaluated_element. This is equivalent to the BlindEvaluate | |||
function described in [OPRF], Section 3.3.1, where k is the | function described in [RFC9497], Section 3.3.1, where k is the | |||
private key parameter. | private key parameter. | |||
* DeriveKeyPair(seed, info): Create and output (sk, pk), consisting | * DeriveKeyPair(seed, info): Create and output (sk, pk), consisting | |||
of a private and public key derived deterministically from a seed | of a private and public key derived deterministically from a seed | |||
and info parameter, as described in [OPRF], Section 3.2. | and info parameter, as described in [RFC9497], Section 3.2. | |||
Finally, this specification makes use of the following shared APIs | Finally, this specification makes use of the following shared APIs | |||
and parameters: | and parameters: | |||
* SerializeElement(element): Map input element to a fixed-length | * SerializeElement(element): Map input element to a fixed-length | |||
byte array. | byte array. | |||
* DeserializeElement(buf): Attempt to map input byte array buf to an | * DeserializeElement(buf): Attempt to map input byte array buf to an | |||
OPRF group element. This function can raise a DeserializeError | OPRF group element. This function can raise a DeserializeError | |||
upon failure; see [OPRF], Section 2.1 for more details. | upon failure; see [RFC9497], Section 2.1 for more details. | |||
* Noe: The size of a serialized OPRF group element output from | * Noe: The size of a serialized OPRF group element output from | |||
SerializeElement. | SerializeElement. | |||
* Nok: The size of an OPRF private key as output from DeriveKeyPair. | * Nok: The size of an OPRF private key as output from DeriveKeyPair. | |||
2.2. Key Derivation Function and Message Authentication Code | 2.2. Key Derivation Function and Message Authentication Code | |||
A Key Derivation Function (KDF) is a function that takes some source | A Key Derivation Function (KDF) is a function that takes some source | |||
of initial keying material and uses it to derive one or more | of initial keying material and uses it to derive one or more | |||
skipping to change at page 8, line 15 ¶ | skipping to change at page 8, line 15 ¶ | |||
* Extract(salt, ikm): Extract a pseudorandom key of fixed length Nx | * Extract(salt, ikm): Extract a pseudorandom key of fixed length Nx | |||
bytes from input keying material ikm and an optional byte string | bytes from input keying material ikm and an optional byte string | |||
salt. | salt. | |||
* Expand(prk, info, L): Expand a pseudorandom key prk using the | * Expand(prk, info, L): Expand a pseudorandom key prk using the | |||
optional string info into L bytes of output keying material. | optional string info into L bytes of output keying material. | |||
* Nx: The output size of the Extract() function in bytes. | * Nx: The output size of the Extract() function in bytes. | |||
This specification also makes use of a random-key robust Message | This specification also makes use of a random-key robust Message | |||
Authentication Code (MAC). See Section 10.7 for more details on this | Authentication Code (MAC). See Section 10.6 for more details on this | |||
property. The API and parameters for the random-key robust MAC are | property. The API and parameters for the random-key robust MAC are | |||
as follows: | as follows: | |||
* MAC(key, msg): Compute a message authentication code over input | * MAC(key, msg): Compute a message authentication code over input | |||
msg with key key, producing a fixed-length output of Nm bytes. | msg with key key, producing a fixed-length output of Nm bytes. | |||
* Nm: The output size of the MAC() function in bytes. | * Nm: The output size of the MAC() function in bytes. | |||
2.3. Hash Functions | 2.3. Hash Functions | |||
skipping to change at page 9, line 13 ¶ | skipping to change at page 9, line 13 ¶ | |||
mutually authenticated key exchange. | mutually authenticated key exchange. | |||
3.1. Setup | 3.1. Setup | |||
Prior to both stages, the client and server agree on a configuration | Prior to both stages, the client and server agree on a configuration | |||
that fully specifies the cryptographic algorithm dependencies | that fully specifies the cryptographic algorithm dependencies | |||
necessary to run the protocol; see Section 7 for details. The server | necessary to run the protocol; see Section 7 for details. The server | |||
chooses a pair of keys (server_private_key and server_public_key) for | chooses a pair of keys (server_private_key and server_public_key) for | |||
the AKE, and chooses a seed (oprf_seed) of Nh bytes for the OPRF. | the AKE, and chooses a seed (oprf_seed) of Nh bytes for the OPRF. | |||
The server can use server_private_key and server_public_key with | The server can use server_private_key and server_public_key with | |||
multiple clients. The server can also opt to use different seeds for | multiple clients. The server can also opt to use a different seed | |||
each client, so long as they are maintained across the registration | for each client (i.e. each client can be assigned a single seed), so | |||
and online AKE stages, and kept consistent for each client (since an | long as they are maintained across the registration and online AKE | |||
inconsistent mapping of clients to seeds could leak information as | stages, and kept consistent for each client (since an inconsistent | |||
described in Section 10.10). | mapping of clients to seeds could leak information as described in | |||
Section 10.9). | ||||
3.2. Offline Registration | 3.2. Registration | |||
Registration is the only stage in OPAQUE that requires a server- | Registration is the only stage in OPAQUE that requires a server- | |||
authenticated channel with confidentiality and integrity: either | authenticated channel with confidentiality and integrity: either | |||
physical, out-of-band, PKI-based, etc. | physical, out-of-band, PKI-based, etc. | |||
The client inputs its credentials, which include its password and | The client inputs its credentials, which include its password and | |||
user identifier, and the server inputs its parameters, which include | user identifier, and the server inputs its parameters, which include | |||
its private key and other information. | its private key and other information. | |||
The client output of this stage is a single value export_key that the | The client output of this stage is a single value export_key that the | |||
skipping to change at page 12, line 14 ¶ | skipping to change at page 12, line 14 ¶ | |||
* server_public_key: The encoded server public key for the AKE | * server_public_key: The encoded server public key for the AKE | |||
protocol. | protocol. | |||
* client_identity: The client identity. This is an application- | * client_identity: The client identity. This is an application- | |||
specific value, e.g., an e-mail address or an account name. If | specific value, e.g., an e-mail address or an account name. If | |||
not specified, it defaults to the client's public key. | not specified, it defaults to the client's public key. | |||
* server_identity: The server identity. This is typically a domain | * server_identity: The server identity. This is typically a domain | |||
name, e.g., example.com. If not specified, it defaults to the | name, e.g., example.com. If not specified, it defaults to the | |||
server's public key. See Section 10.4 for information about this | server's public key. See Section 10.3 for information about this | |||
identity. | identity. | |||
A subset of these credential values are used in the | A subset of these credential values are used in the | |||
CleartextCredentials structure as follows: | CleartextCredentials structure as follows: | |||
struct { | struct { | |||
uint8 server_public_key[Npk]; | uint8 server_public_key[Npk]; | |||
uint8 server_identity<1..2^16-1>; | uint8 server_identity<1..2^16-1>; | |||
uint8 client_identity<1..2^16-1>; | uint8 client_identity<1..2^16-1>; | |||
} CleartextCredentials; | } CleartextCredentials; | |||
skipping to change at page 15, line 39 ¶ | skipping to change at page 15, line 39 ¶ | |||
cleartext_credentials = CreateCleartextCredentials(server_public_key, | cleartext_credentials = CreateCleartextCredentials(server_public_key, | |||
client_public_key, server_identity, client_identity) | client_public_key, server_identity, client_identity) | |||
expected_tag = MAC(auth_key, concat(envelope.nonce, cleartext_credentials)) | expected_tag = MAC(auth_key, concat(envelope.nonce, cleartext_credentials)) | |||
If !ct_equal(envelope.auth_tag, expected_tag) | If !ct_equal(envelope.auth_tag, expected_tag) | |||
raise EnvelopeRecoveryError | raise EnvelopeRecoveryError | |||
return (client_private_key, cleartext_credentials, export_key) | return (client_private_key, cleartext_credentials, export_key) | |||
In the case of EnvelopeRecoveryError being raised, all previously- | In the case of EnvelopeRecoveryError being raised, all previously- | |||
computed intermediary values in this function MUST be deleted. | computed intermediary values in this function MUST be deleted. | |||
5. Offline Registration | 5. Registration | |||
The registration process proceeds as follows. The client inputs the | The registration process proceeds as follows. The client inputs the | |||
following values: | following values: | |||
* password: The client's password. | * password: The client's password. | |||
* creds: The client credentials, as described in Section 4. | * creds: The client credentials, as described in Section 4. | |||
The server inputs the following values: | The server inputs the following values: | |||
skipping to change at page 16, line 46 ¶ | skipping to change at page 16, line 46 ¶ | |||
Section 5.1 describes the formats for the above messages, and | Section 5.1 describes the formats for the above messages, and | |||
Section 5.2 describes details of the functions and the corresponding | Section 5.2 describes details of the functions and the corresponding | |||
parameters referenced above. | parameters referenced above. | |||
At the end of this interaction, the server stores the record object | At the end of this interaction, the server stores the record object | |||
as the credential file for each client along with the associated | as the credential file for each client along with the associated | |||
credential_identifier and client_identity (if different). Note that | credential_identifier and client_identity (if different). Note that | |||
the values oprf_seed and server_private_key from the server's setup | the values oprf_seed and server_private_key from the server's setup | |||
phase must also be persisted. The oprf_seed value SHOULD be used for | phase must also be persisted. The oprf_seed value SHOULD be used for | |||
all clients; see Section 10.10. The server_private_key may be unique | all clients; see Section 10.9. The server_private_key may be unique | |||
for each client. | for each client. | |||
Both client and server MUST validate the other party's public key | Both client and server MUST validate the other party's public key | |||
before use. See Section 10.8 for more details. Upon completion, the | before use. See Section 10.7 for more details. Upon completion, the | |||
server stores the client's credentials for later use. Moreover, the | server stores the client's credentials for later use. Moreover, the | |||
client MAY use the output export_key for further application-specific | client MAY use the output export_key for further application-specific | |||
purposes; see Section 10.5. | purposes; see Section 10.4. | |||
5.1. Registration Messages | 5.1. Registration Messages | |||
This section contains definitions of the RegistrationRequest, | This section contains definitions of the RegistrationRequest, | |||
RegistrationResponse, and RegistrationRecord messages exchanged | RegistrationResponse, and RegistrationRecord messages exchanged | |||
between client and server during registration. | between client and server during registration. | |||
struct { | struct { | |||
uint8 blinded_message[Noe]; | uint8 blinded_message[Noe]; | |||
} RegistrationRequest; | } RegistrationRequest; | |||
skipping to change at page 18, line 9 ¶ | skipping to change at page 18, line 9 ¶ | |||
5.2. Registration Functions | 5.2. Registration Functions | |||
This section contains definitions of the functions used by client and | This section contains definitions of the functions used by client and | |||
server during registration, including CreateRegistrationRequest, | server during registration, including CreateRegistrationRequest, | |||
CreateRegistrationResponse, and FinalizeRegistrationRequest. | CreateRegistrationResponse, and FinalizeRegistrationRequest. | |||
5.2.1. CreateRegistrationRequest | 5.2.1. CreateRegistrationRequest | |||
To begin the registration flow, the client executes the following | To begin the registration flow, the client executes the following | |||
function. This function can fail with an InvalidInputError error | function. This function can fail with an InvalidInputError error | |||
with negligibile probability. A different input password is | with negligible probability. A different input password is necessary | |||
necessary in the event of this error. | in the event of this error. | |||
CreateRegistrationRequest | CreateRegistrationRequest | |||
Input: | Input: | |||
- password, an opaque byte string containing the client's password. | - password, an opaque byte string containing the client's password. | |||
Output: | Output: | |||
- request, a RegistrationRequest structure. | - request, a RegistrationRequest structure. | |||
- blind, an OPRF scalar value. | - blind, an OPRF scalar value. | |||
skipping to change at page 18, line 34 ¶ | skipping to change at page 18, line 34 ¶ | |||
def CreateRegistrationRequest(password): | def CreateRegistrationRequest(password): | |||
(blind, blinded_element) = Blind(password) | (blind, blinded_element) = Blind(password) | |||
blinded_message = SerializeElement(blinded_element) | blinded_message = SerializeElement(blinded_element) | |||
Create RegistrationRequest request with blinded_message | Create RegistrationRequest request with blinded_message | |||
return (request, blind) | return (request, blind) | |||
5.2.2. CreateRegistrationResponse | 5.2.2. CreateRegistrationResponse | |||
To process the client's registration request, the server executes the | To process the client's registration request, the server executes the | |||
following function. This function can fail with a DeriveKeyPairError | following function. This function can fail with a DeriveKeyPairError | |||
error with negligible probability. In this case, application can | error with negligible probability. In this case, applications can | |||
choose a new credential_identifier for this registration record and | choose a new credential_identifier for this registration record and | |||
re-run this function. | re-run this function. | |||
CreateRegistrationResponse | CreateRegistrationResponse | |||
Input: | Input: | |||
- request, a RegistrationRequest structure. | - request, a RegistrationRequest structure. | |||
- server_public_key, the server's public key. | - server_public_key, the server's public key. | |||
- credential_identifier, an identifier that uniquely represents the credential. | - credential_identifier, an identifier that uniquely represents the credential. | |||
- oprf_seed, the seed of Nh bytes used by the server to generate an oprf_key. | - oprf_seed, the seed of Nh bytes used by the server to generate an oprf_key. | |||
skipping to change at page 21, line 40 ¶ | skipping to change at page 21, line 40 ¶ | |||
client's registration. | client's registration. | |||
* credential_identifier: An identifier that uniquely represents the | * credential_identifier: An identifier that uniquely represents the | |||
credential. | credential. | |||
* oprf_seed: The seed used to derive per-client OPRF keys. | * oprf_seed: The seed used to derive per-client OPRF keys. | |||
The client receives two outputs: a session secret and an export key. | The client receives two outputs: a session secret and an export key. | |||
The export key is only available to the client and may be used for | The export key is only available to the client and may be used for | |||
additional application-specific purposes, as outlined in | additional application-specific purposes, as outlined in | |||
Section 10.5. Clients and servers MUST NOT use the output export_key | Section 10.4. Clients MUST NOT use the output export_key before | |||
before authenticating the peer in the authenticated key exchange | authenticating the peer in the authenticated key exchange protocol. | |||
protocol. See Appendix B for more details about this requirement. | See Appendix B for more details about this requirement. The server | |||
The server receives a single output: a session secret matching the | receives a single output: a session secret matching the client's. | |||
client's. | ||||
The protocol runs as shown below: | The protocol runs as shown below: | |||
Client Server | Client Server | |||
------------------------------------------------------ | ------------------------------------------------------ | |||
ke1 = GenerateKE1(password) | ke1 = GenerateKE1(password) | |||
ke1 | ke1 | |||
-------------------------> | -------------------------> | |||
skipping to change at page 28, line 10 ¶ | skipping to change at page 28, line 10 ¶ | |||
This section describes the CreateCredentialRequest, | This section describes the CreateCredentialRequest, | |||
CreateCredentialResponse, and RecoverCredentials functions used for | CreateCredentialResponse, and RecoverCredentials functions used for | |||
credential retrieval. | credential retrieval. | |||
6.3.2.1. CreateCredentialRequest | 6.3.2.1. CreateCredentialRequest | |||
The CreateCredentialRequest is used by the client to initiate the | The CreateCredentialRequest is used by the client to initiate the | |||
credential retrieval process, and it produces a CredentialRequest | credential retrieval process, and it produces a CredentialRequest | |||
message and OPRF state. Like CreateRegistrationRequest, this | message and OPRF state. Like CreateRegistrationRequest, this | |||
function can fail with an InvalidInputError error with negligibile | function can fail with an InvalidInputError error with negligible | |||
probability. However, this should not occur since registration (via | probability. However, this should not occur since registration (via | |||
CreateRegistrationRequest) will fail when provided the same password | CreateRegistrationRequest) will fail when provided the same password | |||
input. | input. | |||
CreateCredentialRequest | CreateCredentialRequest | |||
Input: | Input: | |||
- password, an opaque byte string containing the client's password. | - password, an opaque byte string containing the client's password. | |||
Output: | Output: | |||
skipping to change at page 32, line 43 ¶ | skipping to change at page 32, line 43 ¶ | |||
Section 7, as well as groups covered by test vectors in Appendix D, | Section 7, as well as groups covered by test vectors in Appendix D, | |||
are described in the following sections. | are described in the following sections. | |||
6.4.1.1. 3DH ristretto255 | 6.4.1.1. 3DH ristretto255 | |||
This section describes the implementation of the Diffie-Hellman key | This section describes the implementation of the Diffie-Hellman key | |||
exchange functions based on ristretto255, as defined in [RISTRETTO]. | exchange functions based on ristretto255, as defined in [RISTRETTO]. | |||
* DeriveDiffieHellmanKeyPair(seed): This function is implemented as | * DeriveDiffieHellmanKeyPair(seed): This function is implemented as | |||
DeriveKeyPair(seed, "OPAQUE-DeriveDiffieHellmanKeyPair"), where | DeriveKeyPair(seed, "OPAQUE-DeriveDiffieHellmanKeyPair"), where | |||
DeriveKeyPair is as specified in [OPRF], Section 3.2. The public | DeriveKeyPair is as specified in [RFC9497], Section 3.2. The | |||
value from DeriveKeyPair is encoded using SerializeElement from | public value from DeriveKeyPair is encoded using SerializeElement | |||
Section 2.1 of [OPRF]. | from Section 2.1 of [RFC9497]. | |||
* DiffieHellman(k, B): Implemented as scalar multiplication as | * DiffieHellman(k, B): Implemented as scalar multiplication as | |||
described in Section 4 of [RISTRETTO] after decoding B from its | described in Section 4 of [RISTRETTO] after decoding B from its | |||
encoded input using the Decode function in Section 4.3.1 of | encoded input using the Decode function in Section 4.3.1 of | |||
[RISTRETTO]. The output is then encoded using the | [RISTRETTO]. The output is then encoded using the | |||
SerializeElement function of the OPRF group described in [OPRF], | SerializeElement function of the OPRF group described in | |||
Section 2.1. | [RFC9497], Section 2.1. | |||
6.4.1.2. 3DH P-256 | 6.4.1.2. 3DH P-256 | |||
This section describes the implementation of the Diffie-Hellman key | This section describes the implementation of the Diffie-Hellman key | |||
exchange functions based on NIST P-256, as defined in [NISTCurves]. | exchange functions based on NIST P-256, as defined in [NISTCurves]. | |||
* DeriveDiffieHellmanKeyPair(seed): This function is implemented as | * DeriveDiffieHellmanKeyPair(seed): This function is implemented as | |||
DeriveKeyPair(seed, "OPAQUE-DeriveDiffieHellmanKeyPair"), where | DeriveKeyPair(seed, "OPAQUE-DeriveDiffieHellmanKeyPair"), where | |||
DeriveKeyPair is as specified in [OPRF], Section 3.2. The public | DeriveKeyPair is as specified in [RFC9497], Section 3.2. The | |||
value from DeriveKeyPair is encoded using SerializeElement from | public value from DeriveKeyPair is encoded using SerializeElement | |||
Section 2.1 of [OPRF]. | from Section 2.1 of [RFC9497]. | |||
* DiffieHellman(k, B): Implemented as scalar multiplication as | * DiffieHellman(k, B): Implemented as scalar multiplication as | |||
described in [NISTCurves], after decoding B from its encoded input | described in [NISTCurves], after decoding B from its encoded input | |||
using the compressed Octet-String-to-Elliptic-Curve-Point method | using the compressed Octet-String-to-Elliptic-Curve-Point method | |||
according to [NISTCurves]. The output is then encoded using the | according to [NISTCurves]. The output is then encoded using the | |||
SerializeElement function of the OPRF group described in [OPRF], | SerializeElement function of the OPRF group described in | |||
Section 2.1. | [RFC9497], Section 2.1. | |||
6.4.1.3. 3DH Curve25519 | 6.4.1.3. 3DH Curve25519 | |||
This section describes the implementation of the Diffie-Hellman key | This section describes the implementation of the Diffie-Hellman key | |||
exchange functions based on Curve25519, as defined in [Curve25519]. | exchange functions based on Curve25519, as defined in [Curve25519]. | |||
* DeriveDiffieHellmanKeyPair(seed): This function is implemented by | * DeriveDiffieHellmanKeyPair(seed): This function is implemented by | |||
returning the private key k based on seed (of length Nseed = 32 | returning the private key k based on seed (of length Nseed = 32 | |||
bytes), as described in Section 5 of [Curve25519], as well as the | bytes), as described in Section 5 of [Curve25519], as well as the | |||
result of DiffieHellman(k, B), where B is the base point of | result of DiffieHellman(k, B), where B is the base point of | |||
skipping to change at page 39, line 29 ¶ | skipping to change at page 39, line 29 ¶ | |||
def AuthServerFinalize(ke3): | def AuthServerFinalize(ke3): | |||
if !ct_equal(ke3.client_mac, state.expected_client_mac): | if !ct_equal(ke3.client_mac, state.expected_client_mac): | |||
raise ClientAuthenticationError | raise ClientAuthenticationError | |||
return state.session_key | return state.session_key | |||
7. Configurations | 7. Configurations | |||
An OPAQUE-3DH configuration is a tuple (OPRF, KDF, MAC, Hash, KSF, | An OPAQUE-3DH configuration is a tuple (OPRF, KDF, MAC, Hash, KSF, | |||
Group, Context) such that the following conditions are met: | Group, Context) such that the following conditions are met: | |||
* The OPRF protocol uses the "base mode" variant of [OPRF] and | * The OPRF protocol uses the "base mode" variant of [RFC9497] and | |||
implements the interface in Section 2. Examples include | implements the interface in Section 2. Examples include | |||
ristretto255-SHA512 and P256-SHA256. | ristretto255-SHA512 and P256-SHA256. | |||
* The KDF, MAC, and Hash functions implement the interfaces in | * The KDF, MAC, and Hash functions implement the interfaces in | |||
Section 2. Examples include HKDF [RFC5869] for the KDF, HMAC | Section 2. Examples include HKDF [RFC5869] for the KDF, HMAC | |||
[RFC2104] for the MAC, and SHA-256 and SHA-512 for the Hash | [RFC2104] for the MAC, and SHA-256 and SHA-512 for the Hash | |||
functions. If an extensible output function such as SHAKE128 | functions. If an extensible output function such as SHAKE128 | |||
[FIPS202] is used then the output length Nh MUST be chosen to | [FIPS202] is used then the output length Nh MUST be chosen to | |||
align with the target security level of the OPAQUE configuration. | align with the target security level of the OPAQUE configuration. | |||
For example, if the target security parameter for the | For example, if the target security parameter for the | |||
skipping to change at page 41, line 23 ¶ | skipping to change at page 41, line 23 ¶ | |||
* Client and server identities: As described in Section 4, clients | * Client and server identities: As described in Section 4, clients | |||
and servers are identified with their public keys by default. | and servers are identified with their public keys by default. | |||
However, applications may choose alternate identities that are | However, applications may choose alternate identities that are | |||
pinned to these public keys. For example, servers may use a | pinned to these public keys. For example, servers may use a | |||
domain name instead of a public key as their identifier. Absent | domain name instead of a public key as their identifier. Absent | |||
alternate notions of identity, applications SHOULD set these | alternate notions of identity, applications SHOULD set these | |||
identities to nil and rely solely on public key information. | identities to nil and rely solely on public key information. | |||
* Configuration and envelope updates: Applications may wish to | * Configuration and envelope updates: Applications may wish to | |||
update or change their configuration or other parameters which | update or change their configuration or other parameters that | |||
affect the client's RegistrationRecord over time. Some reasons | affect the client's RegistrationRecord over time. Some reasons | |||
for changing these are to use different cryptographic algorithms, | for changing these are to use different cryptographic algorithms, | |||
e.g., a different KSF with improved parameters, or to update key | e.g., a different KSF with improved parameters, or to update key | |||
material that is cryptographically bound to the | material that is cryptographically bound to the | |||
RegistrationRecord, such as the server's public key | RegistrationRecord, such as the server's public key | |||
(server_public_key). Any such change will require users to re- | (server_public_key). Any such change will require users to re- | |||
register to create a new RegistrationRecord. Supporting these | register to create a new RegistrationRecord. Supporting these | |||
types of updates can be helpful for applications which anticipate | types of updates can be helpful for applications that anticipate | |||
such changes in their deployment setting. | such changes in their deployment setting. | |||
* Password hardening parameters: Key stretching is done to help | * Password hardening parameters: Key stretching is done to help | |||
prevent password disclosure in the event of server compromise; see | prevent password disclosure in the event of server compromise; see | |||
Section 10.9. There is no ideal or default set of parameters, | Section 10.8. There is no ideal or default set of parameters, | |||
though relevant specifications for KSFs give some reasonable | though relevant specifications for KSFs give some reasonable | |||
defaults. | defaults. | |||
* Enumeration prevention: As described in Section 6.3.2.2, if | * Enumeration prevention: As described in Section 6.3.2.2, if | |||
servers receive a credential request for a non-existent client, | servers receive a credential request for a non-existent client, | |||
they SHOULD respond with a "fake" response to prevent active | they SHOULD respond with a "fake" response to prevent active | |||
client enumeration attacks. Servers that implement this | client enumeration attacks. Servers that implement this | |||
mitigation SHOULD use the same configuration information (such as | mitigation SHOULD use the same configuration information (such as | |||
the oprf_seed) for all clients; see Section 10.10. In settings | the oprf_seed) for all clients; see Section 10.9. In settings | |||
where this attack is not a concern, servers may choose to not | where this attack is not a concern, servers may choose to not | |||
support this functionality. | support this functionality. | |||
* Handling password changes: In the event of a password change, the | * Handling password changes: In the event of a password change, the | |||
client and server can run the offline registration phase using the | client and server can run the registration phase using the new | |||
new password as a fresh instance (ensuring to resample all random | password as a fresh instance (ensuring to resample all random | |||
values). The resulting registration record can then replace the | values). The resulting registration record can then replace the | |||
previous record corresponding to the client's old password | previous record corresponding to the client's old password | |||
registration. | registration. | |||
9. Implementation Considerations | 9. Implementation Considerations | |||
This section documents considerations for OPAQUE implementations. | This section documents considerations for OPAQUE implementations. | |||
This includes implementation safeguards and error handling | This includes implementation safeguards and error handling | |||
considerations. | considerations. | |||
skipping to change at page 44, line 44 ¶ | skipping to change at page 44, line 44 ¶ | |||
property defined in Section 2.2 is only needed for the MAC | property defined in Section 2.2 is only needed for the MAC | |||
function. This change was made for two reasons. First, it | function. This change was made for two reasons. First, it | |||
reduces the number of bytes stored in envelopes, which is a | reduces the number of bytes stored in envelopes, which is a | |||
helpful improvement for large applications of OPAQUE with many | helpful improvement for large applications of OPAQUE with many | |||
registered users. Second, it removes the need for client | registered users. Second, it removes the need for client | |||
applications to generate private keys during registration. | applications to generate private keys during registration. | |||
Instead, this responsibility is handled by OPAQUE, thereby | Instead, this responsibility is handled by OPAQUE, thereby | |||
simplifying the client interface to the protocol. | simplifying the client interface to the protocol. | |||
* Envelopes are masked with a per-user masking key as a way of | * Envelopes are masked with a per-user masking key as a way of | |||
preventing client enumeration attacks. See Section 10.10 for more | preventing client enumeration attacks. See Section 10.9 for more | |||
details. This extension is not needed for the security of OPAQUE | details. This extension is not needed for the security of OPAQUE | |||
as an aPAKE but only used to provide a defense against enumeration | as an aPAKE but only used to provide a defense against enumeration | |||
attacks. In the analysis, the masking key can be simulated as a | attacks. In the analysis, the masking key can be simulated as a | |||
(pseudo) random key. This change was made to support real-world | (pseudo) random key. This change was made to support real-world | |||
use cases where client or user enumeration is a security (or | use cases where client or user enumeration is a security (or | |||
privacy) risk. | privacy) risk. | |||
* Per-user OPRF keys are derived from a client identity and cross- | * Per-user OPRF keys are derived from a client identity and cross- | |||
user PRF seed as a mitigation against client enumeration attacks. | user PRF seed as a mitigation against client enumeration attacks. | |||
See Section 10.10 for more details. The analysis of OPAQUE | See Section 10.9 for more details. The analysis of OPAQUE assumes | |||
assumes OPRF keys of different users are independently random or | OPRF keys of different users are independently random or | |||
pseudorandom. Deriving these keys via a single PRF (i.e., with a | pseudorandom. Deriving these keys via a single PRF (i.e., with a | |||
single cross-user key) applied to users' identities satisfies this | single cross-user key) applied to users' identities satisfies this | |||
assumption. This change was made to support real-world use cases | assumption. This change was made to support real-world use cases | |||
where client or user enumeration is a security (or privacy) risk. | where client or user enumeration is a security (or privacy) risk. | |||
Note that the derivation of the OPRF key via a PRF keyed by | ||||
oprf_seed and applied to the unique credential_identifier ensures | ||||
the critical requirement of the per-user OPRF keys being unique | ||||
per client. | ||||
* The protocol outputs an export key for the client in addition to a | * The protocol outputs an export key for the client in addition to a | |||
shared session key that can be used for application-specific | shared session key that can be used for application-specific | |||
purposes. This key is a pseudorandom value derived from the | purposes. This key is a pseudorandom value derived from the | |||
client password (among other values) and has no influence on the | client password (among other values) and has no influence on the | |||
security analysis (it can be simulated with a random output). | security analysis (it can be simulated with a random output). | |||
This change was made to support more application use cases for | This change was made to support more application use cases for | |||
OPAQUE, such as the use of OPAQUE for end-to-end encrypted | OPAQUE, such as the use of OPAQUE for end-to-end encrypted | |||
backups; see [WhatsAppE2E]. | backups; see [WhatsAppE2E]. | |||
* The protocol admits optional application-layer client and server | * The protocol admits optional application-layer client and server | |||
identities. In the absence of these identities, the client and | identities. In the absence of these identities, the client and | |||
server are authenticated against their public keys. Binding | server are authenticated against their public keys. Binding | |||
authentication to identities is part of the AKE part of OPAQUE. | authentication to identities is part of the AKE part of OPAQUE. | |||
The type of identities and their semantics are application | The type of identities and their semantics are application- | |||
dependent and independent of the protocol analysis. This change | dependent and independent of the protocol analysis. This change | |||
was made to simplify client and server interfaces to the protocol | was made to simplify client and server interfaces to the protocol | |||
by removing the need to specify additional identities alongside | by removing the need to specify additional identities alongside | |||
their corresponding public authentication keys when not needed. | their corresponding public authentication keys when not needed. | |||
* The protocol admits application-specific context information | * The protocol admits application-specific context information | |||
configured out-of-band in the AKE transcript. This allows domain | configured out-of-band in the AKE transcript. This allows domain | |||
separation between different application uses of OPAQUE. This is | separation between different application uses of OPAQUE. This is | |||
a mechanism for the AKE component and is best practice for domain | a mechanism for the AKE component and is best practice for domain | |||
separation between different applications of the protocol. This | separation between different applications of the protocol. This | |||
skipping to change at page 46, line 15 ¶ | skipping to change at page 46, line 26 ¶ | |||
* [JKX18] comments on a defense against offline dictionary attacks | * [JKX18] comments on a defense against offline dictionary attacks | |||
upon server compromise or honest-but-curious servers. The authors | upon server compromise or honest-but-curious servers. The authors | |||
suggest implementing the OPRF phase as a threshold OPRF [TOPPSS], | suggest implementing the OPRF phase as a threshold OPRF [TOPPSS], | |||
effectively forcing an attacker to act online or to control at | effectively forcing an attacker to act online or to control at | |||
least t key shares (among the total n), where t is the threshold | least t key shares (among the total n), where t is the threshold | |||
number of shares necessary to recombine the secret OPRF key, and | number of shares necessary to recombine the secret OPRF key, and | |||
only then be able to run an offline dictionary attack. This | only then be able to run an offline dictionary attack. This | |||
implementation only affects the server and changes nothing for the | implementation only affects the server and changes nothing for the | |||
client. Furthermore, if the threshold OPRF servers holding these | client. Furthermore, if the threshold OPRF servers holding these | |||
keys are separate from the authentication server, then recovering | keys are separate from the authentication server, then recovering | |||
all n shares would still not suffice to run an offline dictionnary | all n shares would still not suffice to run an offline dictionary | |||
attack without access to the client record database. However, | attack without access to the client record database. However, | |||
this mechanism is out of scope for this document. | this mechanism is out of scope for this document. | |||
The following list enumerates notable differences and refinements | The following list enumerates notable differences and refinements | |||
from the original cryptographic design in [JKX18] and the | from the original cryptographic design in [JKX18] and the | |||
corresponding CFRG document [I-D.krawczyk-cfrg-opaque-03] that were | corresponding CFRG document [I-D.krawczyk-cfrg-opaque-03] that were | |||
made to make this specification suitable for interoperable | made to make this specification suitable for interoperable | |||
implementations. | implementations. | |||
* [JKX18] used a generic prime-order group for the DH-OPRF and HMQV | * [JKX18] used a generic prime-order group for the DH-OPRF and HMQV | |||
operations, and includes necessary prime-order subgroup checks | operations, and includes necessary prime-order subgroup checks | |||
when receiving attacker-controlled values over the wire. This | when receiving attacker-controlled values over the wire. This | |||
specification instantiates the prime-order group used for 3DH | specification instantiates the prime-order group used for 3DH | |||
using prime-order groups based on elliptic curves, as described in | using prime-order groups based on elliptic curves, as described in | |||
[I-D.irtf-cfrg-voprf], Section 2.1. This specification also | [RFC9497], Section 2.1. This specification also delegates OPRF | |||
delegates OPRF group choice and operations to | group choice and operations to [RFC9497]. As such, the prime- | |||
[I-D.irtf-cfrg-voprf]. As such, the prime-order group as used in | order group as used in the OPRF and 3DH as specified in this | |||
the OPRF and 3DH as specified in this document both adhere to the | document both adhere to the requirements as [JKX18]. | |||
requirements as [JKX18]. | ||||
* [JKX18] specified DH-OPRF (see Appendix B) to instantiate the OPRF | * [JKX18] specified DH-OPRF (see Appendix B) to instantiate the OPRF | |||
functionality in the protocol. A critical part of DH-OPRF is the | functionality in the protocol. A critical part of DH-OPRF is the | |||
hash-to-group operation, which was not instantiated in the | hash-to-group operation, which was not instantiated in the | |||
original analysis. However, the requirements for this operation | original analysis. However, the requirements for this operation | |||
were included. This specification instantiates the OPRF | were included. This specification instantiates the OPRF | |||
functionality based on the [I-D.irtf-cfrg-voprf], which is | functionality based on the [RFC9497], which is identical to the | |||
identical to the DH-OPRF functionality in [JKX18] and, concretely, | DH-OPRF functionality in [JKX18] and, concretely, uses the hash- | |||
uses the hash-to-curve functions in [I-D.irtf-cfrg-hash-to-curve]. | to-curve functions in [RFC9380]. All hash-to-curve methods in | |||
All hash-to-curve methods in [I-D.irtf-cfrg-hash-to-curve] are | [RFC9380] are compliant with the requirement in [JKX18], namely, | |||
compliant with the requirement in [JKX18], namely, that the output | that the output be a member of the prime-order group. | |||
be a member of the prime-order group. | ||||
* [JKX18] and [I-D.krawczyk-cfrg-opaque-03] both used HMQV as the | * [JKX18] and [I-D.krawczyk-cfrg-opaque-03] both used HMQV as the | |||
AKE for the protocol. However, this document fully specifies 3DH | AKE for the protocol. However, this document fully specifies 3DH | |||
instead of HMQV (though a sketch for how to instantiate OPAQUE | instead of HMQV (though a sketch for how to instantiate OPAQUE | |||
using HMQV is included in Appendix C.1). Since 3DH satisfies the | using HMQV is included in Appendix C.1). Since 3DH satisfies the | |||
essential requirements for the AKE as described in [JKX18] and | essential requirements for the AKE as described in [JKX18] and | |||
[I-D.krawczyk-cfrg-opaque-03], as recalled in Section 10.2, this | [I-D.krawczyk-cfrg-opaque-03], as recalled in Section 10.2, this | |||
change preserves the overall security of the protocol. 3DH was | change preserves the overall security of the protocol. 3DH was | |||
chosen for its simplicity and ease of implementation. | chosen for its simplicity and ease of implementation. | |||
* The DH-OPRF and HMQV instantiation of OPAQUE in [JKX18], Figure 12 | * The DH-OPRF and HMQV instantiation of OPAQUE in [JKX18], Figure 12 | |||
uses a different transcript than that which is described in this | uses a different transcript than that which is described in this | |||
specification. In particular, the key exchange transcript | specification. In particular, the key exchange transcript | |||
specified in Section 6.4 is a superset of the transcript as | specified in Section 6.4 is a superset of the transcript as | |||
defined in [JKX18]. This was done to align with best practices, | defined in [JKX18]. This was done to align with best practices, | |||
such as is done for key exchange protocols like TLS 1.3 [RFC8446]. | such as is done for key exchange protocols like TLS 1.3 [RFC8446]. | |||
skipping to change at page 47, line 41 ¶ | skipping to change at page 47, line 49 ¶ | |||
OPAQUE's design builds on a line of work initiated in the seminal | OPAQUE's design builds on a line of work initiated in the seminal | |||
paper of Ford and Kaliski [FK00] and is based on the HPAKE protocol | paper of Ford and Kaliski [FK00] and is based on the HPAKE protocol | |||
of Xavier Boyen [Boyen09] and the (1,1)-PPSS protocol from Jarecki et | of Xavier Boyen [Boyen09] and the (1,1)-PPSS protocol from Jarecki et | |||
al. [JKKX16]. None of these papers considered security against pre- | al. [JKKX16]. None of these papers considered security against pre- | |||
computation attacks or presented a proof of aPAKE security (not even | computation attacks or presented a proof of aPAKE security (not even | |||
in a weak model). | in a weak model). | |||
The KCI property required from AKE protocols for use with OPAQUE | The KCI property required from AKE protocols for use with OPAQUE | |||
states that knowledge of a party's private key does not allow an | states that knowledge of a party's private key does not allow an | |||
attacker to impersonate others to that party. This is an important | attacker to impersonate others to that party. This is an important | |||
security property achieved by most public-key based AKE protocols, | security property achieved by most public-key-based AKE protocols, | |||
including protocols that use signatures or public key encryption for | including protocols that use signatures or public key encryption for | |||
authentication. It is also a property of many implicitly | authentication. It is also a property of many implicitly | |||
authenticated protocols, e.g., HMQV, but not all of them. We also | authenticated protocols, e.g., HMQV, but not all of them. We also | |||
note that key exchange protocols based on shared keys do not satisfy | note that key exchange protocols based on shared keys do not satisfy | |||
the KCI requirement, hence they are not considered in the OPAQUE | the KCI requirement, hence they are not considered in the OPAQUE | |||
setting. We note that KCI is needed to ensure a crucial property of | setting. We note that KCI is needed to ensure a crucial property of | |||
OPAQUE: even upon compromise of the server, the attacker cannot | OPAQUE: even upon compromise of the server, the attacker cannot | |||
impersonate the client to the server without first running an | impersonate the client to the server without first running an | |||
exhaustive dictionary attack. Another essential requirement from AKE | exhaustive dictionary attack. Another essential requirement from AKE | |||
protocols for use in OPAQUE is to provide forward secrecy (against | protocols for use in OPAQUE is to provide forward secrecy (against | |||
skipping to change at page 48, line 15 ¶ | skipping to change at page 48, line 24 ¶ | |||
In [JKX18], security is proven for one instance (i.e., one key) of | In [JKX18], security is proven for one instance (i.e., one key) of | |||
the OPAQUE protocol, and without batching. There is currently no | the OPAQUE protocol, and without batching. There is currently no | |||
security analysis available for the OPAQUE protocol described in this | security analysis available for the OPAQUE protocol described in this | |||
document in a setting with multiple server keys or batching. | document in a setting with multiple server keys or batching. | |||
As stated in Section 9.1, incorporating client_identity adds domain | As stated in Section 9.1, incorporating client_identity adds domain | |||
separation, in particular against servers that choose the same OPRF | separation, in particular against servers that choose the same OPRF | |||
key for multiple clients. The client_identity as input to the OPRF | key for multiple clients. The client_identity as input to the OPRF | |||
also acts as a key identifier that would be required for a proof of | also acts as a key identifier that would be required for a proof of | |||
the protocol in the multi-key setting; the OPAQUE analysis in [JKX18] | the protocol in the multi-key setting; the OPAQUE analysis in [JKX18] | |||
assumes single server-key instances. Adding server_identityto the | assumes single server-key instances. Adding server_identity to the | |||
OPRF input provides domain separation for clients that reuse the | OPRF input provides domain separation for clients that reuse the same | |||
sameclient_identity` across different server instantiations. | client_identity across different server instantiations. | |||
10.3. Related Protocols | ||||
Despite the existence of multiple designs for (PKI-free) aPAKE | ||||
protocols, none of these protocols are secure against pre-computation | ||||
attacks. This includes protocols that have recent analyses in the UC | ||||
model such as AuCPace [AuCPace] and SPAKE2+ [SPAKE2plus]. In | ||||
particular, none of these protocols can use the standard technique | ||||
against pre-computation that combines secret random values ("salt") | ||||
into the one-way password mappings. Either these protocols do not | ||||
use a salt at all or, if they do, they transmit the salt from server | ||||
to client in the clear, hence losing the secrecy of the salt and its | ||||
defense against pre-computation. | ||||
We note that as shown in [JKX18], these protocols, and any aPAKE in | ||||
the model from [GMR06], can be converted into an aPAKE secure against | ||||
pre-computation attacks at the expense of an additional OPRF | ||||
execution. | ||||
Beyond AuCPace and SPAKE2+, the most widely deployed PKI-free aPAKE | ||||
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. | ||||
10.4. Identities | 10.3. Identities | |||
AKE protocols generate keys that need to be uniquely and verifiably | AKE protocols generate keys that need to be uniquely and verifiably | |||
bound to a pair of identities. In the case of OPAQUE, those | bound to a pair of identities. In the case of OPAQUE, those | |||
identities correspond to client_identity and server_identity. Thus, | identities correspond to client_identity and server_identity. Thus, | |||
it is essential for the parties to agree on such identities, | it is essential for the parties to agree on such identities, | |||
including an agreed bit representation of these identities as needed. | including an agreed bit representation of these identities as needed. | |||
Note that the method of transmission of client_identity from client | Note that the method of transmission of client_identity from client | |||
to server is outside the scope of this protocol, and it is up to an | to server is outside the scope of this protocol, and it is up to an | |||
application to choose how this identity should be delivered (for | application to choose how this identity should be delivered (for | |||
skipping to change at page 50, line 5 ¶ | skipping to change at page 49, line 32 ¶ | |||
protected by the authentication from the envelope. Then, the client | protected by the authentication from the envelope. Then, the client | |||
can verify that the client_identity and server_identity contained in | can verify that the client_identity and server_identity contained in | |||
its envelope match the client_identity and server_identity supplied | its envelope match the client_identity and server_identity supplied | |||
by the server. | by the server. | |||
However, if this extra layer of verification is unnecessary for the | However, if this extra layer of verification is unnecessary for the | |||
application, then simply leaving client_identity and server_identity | application, then simply leaving client_identity and server_identity | |||
unspecified (and using client_public_key and server_public_key | unspecified (and using client_public_key and server_public_key | |||
instead) is acceptable. | instead) is acceptable. | |||
10.5. Export Key Usage | 10.4. Export Key Usage | |||
The export key can be used (separately from the OPAQUE protocol) to | The export key can be used (separately from the OPAQUE protocol) to | |||
provide confidentiality and integrity to other data which only the | provide confidentiality and integrity to other data which only the | |||
client should be able to process. For instance, if the client wishes | client should be able to process. For instance, if the client wishes | |||
to store secrets with a third party, then this export key can be used | to store secrets with a third party, then this export key can be used | |||
by the client to encrypt these secrets so that they remain hidden | by the client to encrypt these secrets so that they remain hidden | |||
from a passive adversary that does not have access to the server's | from a passive adversary that does not have access to the server's | |||
secret keys or the client's password. | secret keys or the client's password. | |||
10.6. Static Diffie-Hellman Oracles | 10.5. Static Diffie-Hellman Oracles | |||
While one can expect the practical security of the OPRF function | While one can expect the practical security of the OPRF function | |||
(namely, the hardness of computing the function without knowing the | (namely, the hardness of computing the function without knowing the | |||
key) to be in the order of computing discrete logarithms or solving | key) to be in the order of computing discrete logarithms or solving | |||
Diffie-Hellman, Brown and Gallant [BG04] and Cheon [Cheon06] show an | Diffie-Hellman, Brown and Gallant [BG04] and Cheon [Cheon06] show an | |||
attack that slightly improves on generic attacks. For typical | attack that slightly improves on generic attacks. For typical | |||
curves, the attack requires an infeasible number of calls to the OPRF | curves, the attack requires an infeasible number of calls to the OPRF | |||
or results in insignificant security loss; see [OPRF] for more | or results in insignificant security loss; see [RFC9497] for more | |||
information. For OPAQUE, these attacks are particularly impractical | information. For OPAQUE, these attacks are particularly impractical | |||
as they translate into an infeasible number of failed authentication | as they translate into an infeasible number of failed authentication | |||
attempts directed at individual users. | attempts directed at individual users. | |||
10.7. Random-Key Robust MACs | 10.6. Random-Key Robust MACs | |||
The random-key robustness property for a MAC states that, given two | The random-key robustness property for a MAC states that, given two | |||
random keys k1 and k2, it is infeasible to find a message m such that | random keys k1 and k2, it is infeasible to find a message m such that | |||
MAC(k1, m) = MAC(k2, m). Note that in general, not every MAC | MAC(k1, m) = MAC(k2, m). Note that in general, not every MAC | |||
function is key-robust. In particular, GMAC (which underlies GCM) | function is key-robust. In particular, GMAC (which underlies GCM) | |||
does not satisfy key-robustness, whereas HMAC with a collision- | does not satisfy key-robustness, whereas HMAC with a collision- | |||
resistant hash function does satisfy key-robustness. | resistant hash function does satisfy key-robustness. | |||
An application can choose to use a non-key-robust MAC within the AKE | An application can choose to use a non-key-robust MAC within the AKE | |||
portion of the protocol described in Section 6.4, but it MUST use a | portion of the protocol described in Section 6.4, but it MUST use a | |||
key-robust MAC for the creation of the auth_tag parameter in | key-robust MAC for the creation of the auth_tag parameter in | |||
Section 4.1.2. | Section 4.1.2. | |||
10.8. Input Validation | 10.7. Input Validation | |||
Both client and server MUST validate the other party's public key(s) | Both client and server MUST validate the other party's public key(s) | |||
used for the execution of OPAQUE. This includes the keys shared | used for the execution of OPAQUE. This includes the keys shared | |||
during the offline registration phase, as well as any keys shared | during the registration phase, as well as any keys shared during the | |||
during the online key agreement phase. The validation procedure | online key agreement phase. The validation procedure varies | |||
varies depending on the type of key. For example, for OPAQUE | depending on the type of key. For example, for OPAQUE instantiations | |||
instantiations using 3DH with P-256, P-384, or P-521 as the | using 3DH with P-256, P-384, or P-521 as the underlying group, | |||
underlying group, validation is as specified in Section 5.6.2.3.4 of | validation is as specified in Section 5.6.2.3.4 of [keyagreement]. | |||
[keyagreement]. This includes checking that the coordinates are in | This includes checking that the coordinates are in the correct range, | |||
the correct range, that the point is on the curve, and that the point | that the point is on the curve, and that the point is not the point | |||
is not the point at infinity. Additionally, validation MUST ensure | at infinity. Additionally, validation MUST ensure the Diffie-Hellman | |||
the Diffie-Hellman shared secret is not the point at infinity. | shared secret is not the point at infinity. | |||
10.9. OPRF Key Stretching | 10.8. OPRF Key Stretching | |||
Applying a key stretching function to the output of the OPRF greatly | Applying a key stretching function to the output of the OPRF greatly | |||
increases the cost of an offline attack upon the compromise of the | increases the cost of an offline attack upon the compromise of the | |||
credential file at the server. Applications SHOULD select parameters | credential file on the server. Applications SHOULD select parameters | |||
for the KSF that balance cost and complexity across different client | for the KSF that balance cost and complexity across different client | |||
implementations and deployments. Note that in OPAQUE, the key | implementations and deployments. Note that in OPAQUE, the key | |||
stretching function is executed by the client, as opposed to the | stretching function is executed by the client, as opposed to the | |||
server in traditional password hashing scenarios. This means that | server in traditional password hashing scenarios. This means that | |||
applications must consider a tradeoff between the performance of the | applications must consider a tradeoff between the performance of the | |||
protocol on clients (specifically low-end devices) and protection | protocol on clients (specifically low-end devices) and protection | |||
against offline attacks after a server compromise. | against offline attacks after a server compromise. | |||
10.10. Client Enumeration | 10.9. Client Enumeration | |||
Client enumeration refers to attacks where the attacker tries to | Client enumeration refers to attacks where the attacker tries to | |||
learn whether a given user identity is registered with a server or | learn whether a given user identity is registered with a server or | |||
whether a re-registration or change of password was performed for | whether a re-registration or change of password was performed for | |||
that user. OPAQUE counters these attacks by requiring servers to act | that user. OPAQUE counters these attacks by requiring servers to act | |||
with unregistered client identities in a way that is | with unregistered client identities in a way that is | |||
indistinguishable from their behavior with existing registered | indistinguishable from their behavior with existing registered | |||
clients. Servers do this by simulating a fake CredentialResponse as | clients. Servers do this by simulating a fake CredentialResponse as | |||
specified in Section 6.3.2.2 for unregistered users, and also | specified in Section 6.3.2.2 for unregistered users, and also | |||
encrypting CredentialResponse using a masking key. In this way, real | encrypting CredentialResponse using a masking key. In this way, real | |||
skipping to change at page 51, line 43 ¶ | skipping to change at page 51, line 28 ¶ | |||
leakage (e.g., timing attacks) from helping differentiate these | leakage (e.g., timing attacks) from helping differentiate these | |||
operations from a regular server response. Note that this may | operations from a regular server response. Note that this may | |||
introduce possible abuse vectors since the server's cost of | introduce possible abuse vectors since the server's cost of | |||
generating a CredentialResponse is less than that of the client's | generating a CredentialResponse is less than that of the client's | |||
cost of generating a CredentialRequest. Server implementations may | cost of generating a CredentialRequest. Server implementations may | |||
choose to forego the construction of a simulated credential response | choose to forego the construction of a simulated credential response | |||
message for an unregistered client if these client enumeration | message for an unregistered client if these client enumeration | |||
attacks can be mitigated through other application-specific means or | attacks can be mitigated through other application-specific means or | |||
are otherwise not applicable for their threat model. | are otherwise not applicable for their threat model. | |||
OPAQUE does not prevent against this type of attack during the | OPAQUE does not prevent this type of attack during the registration | |||
registration flow. Servers necessarily react differently during the | flow. Servers necessarily react differently during the registration | |||
registration flow between registered and unregistered clients. This | flow between registered and unregistered clients. This allows an | |||
allows an attacker to use the server's response during registration | attacker to use the server's response during registration as an | |||
as an oracle for whether a given client identity is registered. | oracle for whether a given client identity is registered. | |||
Applications should mitigate against this type of attack by rate | Applications should mitigate against this type of attack by rate | |||
limiting or otherwise restricting the registration flow. | limiting or otherwise restricting the registration flow. | |||
10.11. Protecting the Registration Masking Key | 10.10. Protecting the Registration Masking Key | |||
The user enumeration prevention method described in this document | The user enumeration prevention method described in this document | |||
uses a symmetric encryption key, masking_key, generated and sent to | uses a symmetric encryption key, masking_key, generated and sent to | |||
the server by the client during registration. This requires a | the server by the client during registration. This requires a | |||
confidential channel between client and server during registration, | confidential channel between client and server during registration, | |||
e.g., using TLS [RFC8446]. If the channel is only authenticated | e.g., using TLS [RFC8446]. If the channel is only authenticated | |||
(this is a requirement for correct identification of the parties), a | (this is a requirement for correct identification of the parties), a | |||
confidential channel can be established using public-key encryption, | confidential channel can be established using public-key encryption, | |||
e.g., with HPKE [RFC9180]. However, the details of this mechanism | e.g., with HPKE [RFC9180]. However, the details of this mechanism | |||
are out of scope of this document. | are out of scope for this document. | |||
10.12. Password Salt and Storage Implications | 10.11. Password Salt and Storage Implications | |||
In OPAQUE, the OPRF key acts as the secret salt value that ensures | In OPAQUE, the OPRF key acts as the secret salt value that ensures | |||
the infeasibility of pre-computation attacks. No extra salt value is | the infeasibility of pre-computation attacks. No extra salt value is | |||
needed. Also, clients never disclose their passwords to the server, | needed. Also, clients never disclose their passwords to the server, | |||
even during registration. Note that a corrupted server can run an | even during registration. Note that a corrupted server can run an | |||
exhaustive offline dictionary attack to validate guesses for the | exhaustive offline dictionary attack to validate guesses for the | |||
client's password; this is inevitable in any (single-server) aPAKE | client's password; this is inevitable in any (single-server) aPAKE | |||
protocol. It can be avoided in the case of OPAQUE by resorting to a | protocol. It can be avoided in the case of OPAQUE by resorting to a | |||
multi-server threshold OPRF implementation, e.g., [TOPPSS]. | multi-server threshold OPRF implementation, e.g., [TOPPSS]. | |||
Furthermore, if the server does not sample the PRF seed with | Furthermore, if the server does not sample the PRF seed with | |||
sufficiently high entropy, or if it is not kept hidden from an | sufficiently high entropy, or if it is not kept hidden from an | |||
adversary, then any derivatives from the client's password may also | adversary, then any derivatives from the client's password may also | |||
be susceptible to an offline dictionary attack to recover the | be susceptible to an offline dictionary attack to recover the | |||
original password. | original password. | |||
Some applications may require learning the client's password for | Some applications may require learning the client's password to | |||
enforcing password rules. Doing so invalidates this important | enforce password rules. Doing so invalidates this important security | |||
security property of OPAQUE and is NOT RECOMMENDED, unless it is not | property of OPAQUE and is NOT RECOMMENDED, unless it is not possible | |||
possible for applications to move such checks to the client. Note | for applications to move such checks to the client. Note that | |||
that limited checks at the server are possible to implement, e.g., | limited checks at the server are possible to implement, e.g., | |||
detecting repeated passwords upon re-registrations or password | detecting repeated passwords upon re-registrations or password | |||
change. | change. | |||
In general, passwords should be selected with sufficient entropy to | In general, passwords should be selected with sufficient entropy to | |||
avoid being susceptible to recovery through dictionary attacks, both | avoid being susceptible to recovery through dictionary attacks, both | |||
online and offline. | online and offline. | |||
10.13. AKE Private Key Storage | 10.12. AKE Private Key Storage | |||
Server implementations of OPAQUE do not need access to the raw AKE | Server implementations of OPAQUE do not need access to the raw AKE | |||
private key. They only require the ability to compute shared secrets | private key. They only require the ability to compute shared secrets | |||
as specified in Section 6.4.2. Thus, applications may store the | as specified in Section 6.4.2. Thus, applications may store the | |||
server AKE private key in a Hardware Security Module (HSM) or | server AKE private key in a Hardware Security Module (HSM) or | |||
similar. Upon compromise of the OPRF seed and client envelopes, this | similar. Upon compromise of the OPRF seed and client envelopes, this | |||
would prevent an attacker from using this data to mount a server | would prevent an attacker from using this data to mount a server | |||
spoofing attack. Supporting implementations need to consider | spoofing attack. Supporting implementations need to consider | |||
allowing separate AKE and OPRF algorithms in cases where the HSM is | allowing separate AKE and OPRF algorithms in cases where the HSM is | |||
incompatible with the OPRF algorithm. | incompatible with the OPRF algorithm. | |||
10.13. Client Authentication Using Credentials | ||||
For scenarios in which the client has access to private state that | ||||
can be persisted across registration and login, the client can back | ||||
up the randomized_password variable (as computed in Section 5.2.3) so | ||||
that upon a future login attempt, the client can authenticate to the | ||||
server using randomized_password instead of the original password. | ||||
This can be achieved by supplying an arbitrary password as input to | ||||
CreateCredentialRequest in the login phase, and then using | ||||
randomized_password from the backup in RecoverCredentials (invoked by | ||||
GenerateKE3) rather than computing it from the password. | ||||
This provides an advantage over the regular authentication flow for | ||||
login in that if randomized_password is compromised, an adversary | ||||
cannot use this value to successfully impersonate the server to the | ||||
client during login. The drawback is that it is only applicable to | ||||
settings where randomized_password can be treated as a credential | ||||
which can be stored securely after registration and retrieved upon | ||||
login. | ||||
11. IANA Considerations | 11. IANA Considerations | |||
This document makes no IANA requests. | This document makes no IANA requests. | |||
12. References | 12. References | |||
12.1. Normative References | 12.1. Normative References | |||
[I-D.irtf-cfrg-voprf] | ||||
Davidson, A., Faz-Hernandez, A., Sullivan, N., and C. A. | ||||
Wood, "Oblivious Pseudorandom Functions (OPRFs) using | ||||
Prime-Order Groups", Work in Progress, Internet-Draft, | ||||
draft-irtf-cfrg-voprf-21, 21 February 2023, | ||||
<https://datatracker.ietf.org/doc/html/draft-irtf-cfrg- | ||||
voprf-21>. | ||||
[OPRF] Davidson, A., Faz-Hernandez, A., Sullivan, N., and C. A. | ||||
Wood, "Oblivious Pseudorandom Functions (OPRFs) using | ||||
Prime-Order Groups", Work in Progress, Internet-Draft, | ||||
draft-irtf-cfrg-voprf-21, 21 February 2023, | ||||
<https://datatracker.ietf.org/doc/html/draft-irtf-cfrg- | ||||
voprf-21>. | ||||
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- | [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- | |||
Hashing for Message Authentication", RFC 2104, | Hashing for Message Authentication", RFC 2104, | |||
DOI 10.17487/RFC2104, February 1997, | DOI 10.17487/RFC2104, February 1997, | |||
<https://www.rfc-editor.org/rfc/rfc2104>. | <https://www.rfc-editor.org/rfc/rfc2104>. | |||
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | |||
Requirement Levels", BCP 14, RFC 2119, | Requirement Levels", BCP 14, RFC 2119, | |||
DOI 10.17487/RFC2119, March 1997, | DOI 10.17487/RFC2119, March 1997, | |||
<https://www.rfc-editor.org/rfc/rfc2119>. | <https://www.rfc-editor.org/rfc/rfc2119>. | |||
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, | [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, | |||
"Randomness Requirements for Security", BCP 106, RFC 4086, | "Randomness Requirements for Security", BCP 106, RFC 4086, | |||
DOI 10.17487/RFC4086, June 2005, | DOI 10.17487/RFC4086, June 2005, | |||
<https://www.rfc-editor.org/rfc/rfc4086>. | <https://www.rfc-editor.org/rfc/rfc4086>. | |||
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC | [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC | |||
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, | 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, | |||
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>. | May 2017, <https://www.rfc-editor.org/rfc/rfc8174>. | |||
[RFC9497] Davidson, A., Faz-Hernandez, A., Sullivan, N., and C. A. | ||||
Wood, "Oblivious Pseudorandom Functions (OPRFs) Using | ||||
Prime-Order Groups", RFC 9497, DOI 10.17487/RFC9497, | ||||
December 2023, <https://www.rfc-editor.org/rfc/rfc9497>. | ||||
12.2. Informative References | 12.2. Informative References | |||
[ARGON2] Biryukov, A., Dinu, D., Khovratovich, D., and S. | [ARGON2] Biryukov, A., Dinu, D., Khovratovich, D., and S. | |||
Josefsson, "Argon2 Memory-Hard Function for Password | Josefsson, "Argon2 Memory-Hard Function for Password | |||
Hashing and Proof-of-Work Applications", RFC 9106, | Hashing and Proof-of-Work Applications", RFC 9106, | |||
DOI 10.17487/RFC9106, September 2021, | DOI 10.17487/RFC9106, September 2021, | |||
<https://www.rfc-editor.org/rfc/rfc9106>. | <https://www.rfc-editor.org/rfc/rfc9106>. | |||
[AuCPace] Haase, B. and B. Labrique, "AuCPace: Efficient verifier- | [AuCPace] Haase, B. and B. Labrique, "AuCPace: Efficient verifier- | |||
based PAKE protocol tailored for the IIoT", | based PAKE protocol tailored for the IIoT", | |||
skipping to change at page 55, line 8 ¶ | skipping to change at page 55, line 8 ¶ | |||
making password-based key exchange resilient to server | making password-based key exchange resilient to server | |||
compromise", CRYPTO , 2006. | compromise", CRYPTO , 2006. | |||
[HJKW23] Hesse, J., Jarecki, S., Krawczyk, H., and C. Wood, | [HJKW23] Hesse, J., Jarecki, S., Krawczyk, H., and C. Wood, | |||
"Password-Authenticated TLS via OPAQUE and Post-Handshake | "Password-Authenticated TLS via OPAQUE and Post-Handshake | |||
Authentication", EUROCRYPT , 2023. | Authentication", EUROCRYPT , 2023. | |||
[HMQV] Krawczyk, H., "HMQV: A high-performance secure Diffie- | [HMQV] Krawczyk, H., "HMQV: A high-performance secure Diffie- | |||
Hellman protocol", CRYPTO , 2005. | Hellman protocol", CRYPTO , 2005. | |||
[I-D.irtf-cfrg-hash-to-curve] | ||||
Faz-Hernandez, A., Scott, S., Sullivan, N., Wahby, R. S., | ||||
and C. A. Wood, "Hashing to Elliptic Curves", Work in | ||||
Progress, Internet-Draft, draft-irtf-cfrg-hash-to-curve- | ||||
16, 15 June 2022, <https://datatracker.ietf.org/doc/html/ | ||||
draft-irtf-cfrg-hash-to-curve-16>. | ||||
[I-D.krawczyk-cfrg-opaque-03] | [I-D.krawczyk-cfrg-opaque-03] | |||
"The OPAQUE Asymmetric PAKE Protocol", n.d., | "The OPAQUE Asymmetric PAKE Protocol", n.d., | |||
<https://datatracker.ietf.org/doc/html/draft-krawczyk- | <https://datatracker.ietf.org/doc/html/draft-krawczyk- | |||
cfrg-opaque-03>. | cfrg-opaque-03>. | |||
[JKKX16] Jarecki, S., Kiayias, A., Krawczyk, H., and J. Xu, | [JKKX16] Jarecki, S., Kiayias, A., Krawczyk, H., and J. Xu, | |||
"Highly-efficient and composable password-protected secret | "Highly-efficient and composable password-protected secret | |||
sharing (or: how to protect your bitcoin wallet online)", | sharing (or: how to protect your bitcoin wallet online)", | |||
IEEE European Symposium on Security and Privacy , 2016. | IEEE European Symposium on Security and Privacy , 2016. | |||
skipping to change at page 56, line 10 ¶ | skipping to change at page 55, line 48 ¶ | |||
[PAKE-Selection] | [PAKE-Selection] | |||
"CFRG PAKE selection process repository", n.d., | "CFRG PAKE selection process repository", n.d., | |||
<https://github.com/cfrg/pake-selection>. | <https://github.com/cfrg/pake-selection>. | |||
[PBKDF2] Kaliski, B., "PKCS #5: Password-Based Cryptography | [PBKDF2] Kaliski, B., "PKCS #5: Password-Based Cryptography | |||
Specification Version 2.0", RFC 2898, | Specification Version 2.0", RFC 2898, | |||
DOI 10.17487/RFC2898, September 2000, | DOI 10.17487/RFC2898, September 2000, | |||
<https://www.rfc-editor.org/rfc/rfc2898>. | <https://www.rfc-editor.org/rfc/rfc2898>. | |||
[RFC2945] Wu, T., "The SRP Authentication and Key Exchange System", | ||||
RFC 2945, DOI 10.17487/RFC2945, September 2000, | ||||
<https://www.rfc-editor.org/rfc/rfc2945>. | ||||
[RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand | [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand | |||
Key Derivation Function (HKDF)", RFC 5869, | Key Derivation Function (HKDF)", RFC 5869, | |||
DOI 10.17487/RFC5869, May 2010, | DOI 10.17487/RFC5869, May 2010, | |||
<https://www.rfc-editor.org/rfc/rfc5869>. | <https://www.rfc-editor.org/rfc/rfc5869>. | |||
[RFC8017] Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch, | [RFC8017] Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch, | |||
"PKCS #1: RSA Cryptography Specifications Version 2.2", | "PKCS #1: RSA Cryptography Specifications Version 2.2", | |||
RFC 8017, DOI 10.17487/RFC8017, November 2016, | RFC 8017, DOI 10.17487/RFC8017, November 2016, | |||
<https://www.rfc-editor.org/rfc/rfc8017>. | <https://www.rfc-editor.org/rfc/rfc8017>. | |||
skipping to change at page 56, line 36 ¶ | skipping to change at page 56, line 22 ¶ | |||
April 2017, <https://www.rfc-editor.org/rfc/rfc8125>. | April 2017, <https://www.rfc-editor.org/rfc/rfc8125>. | |||
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol | [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol | |||
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, | Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, | |||
<https://www.rfc-editor.org/rfc/rfc8446>. | <https://www.rfc-editor.org/rfc/rfc8446>. | |||
[RFC9180] Barnes, R., Bhargavan, K., Lipp, B., and C. Wood, "Hybrid | [RFC9180] Barnes, R., Bhargavan, K., Lipp, B., and C. Wood, "Hybrid | |||
Public Key Encryption", RFC 9180, DOI 10.17487/RFC9180, | Public Key Encryption", RFC 9180, DOI 10.17487/RFC9180, | |||
February 2022, <https://www.rfc-editor.org/rfc/rfc9180>. | February 2022, <https://www.rfc-editor.org/rfc/rfc9180>. | |||
[RFC9380] Faz-Hernandez, A., Scott, S., Sullivan, N., Wahby, R. S., | ||||
and C. A. Wood, "Hashing to Elliptic Curves", RFC 9380, | ||||
DOI 10.17487/RFC9380, August 2023, | ||||
<https://www.rfc-editor.org/rfc/rfc9380>. | ||||
[RISTRETTO] | [RISTRETTO] | |||
de Valence, H., Grigg, J., Hamburg, M., Lovecruft, I., | de Valence, H., Grigg, J., Hamburg, M., Lovecruft, I., | |||
Tankersley, G., and F. Valsorda, "The ristretto255 and | Tankersley, G., and F. Valsorda, "The ristretto255 and | |||
decaf448 Groups", Work in Progress, Internet-Draft, draft- | decaf448 Groups", Work in Progress, Internet-Draft, draft- | |||
irtf-cfrg-ristretto255-decaf448-08, 5 September 2023, | irtf-cfrg-ristretto255-decaf448-08, 5 September 2023, | |||
<https://datatracker.ietf.org/doc/html/draft-irtf-cfrg- | <https://datatracker.ietf.org/doc/html/draft-irtf-cfrg- | |||
ristretto255-decaf448-08>. | ristretto255-decaf448-08>. | |||
[SCRYPT] Percival, C. and S. Josefsson, "The scrypt Password-Based | [SCRYPT] Percival, C. and S. Josefsson, "The scrypt Password-Based | |||
Key Derivation Function", RFC 7914, DOI 10.17487/RFC7914, | Key Derivation Function", RFC 7914, DOI 10.17487/RFC7914, | |||
skipping to change at page 57, line 29 ¶ | skipping to change at page 57, line 20 ¶ | |||
WhatsApp, "Security of End-to-End Encrypted Backups", | WhatsApp, "Security of End-to-End Encrypted Backups", | |||
n.d., <https://www.whatsapp.com/security/ | n.d., <https://www.whatsapp.com/security/ | |||
WhatsApp_Security_Encrypted_Backups_Whitepaper.pdf>. | WhatsApp_Security_Encrypted_Backups_Whitepaper.pdf>. | |||
Appendix A. Acknowledgments | Appendix A. Acknowledgments | |||
We are indebted to the OPAQUE reviewers during CFRG's aPAKE selection | We are indebted to the OPAQUE reviewers during CFRG's aPAKE selection | |||
process, particularly Julia Hesse and Bjorn Tackmann. This draft has | process, particularly Julia Hesse and Bjorn Tackmann. This draft has | |||
benefited from comments by multiple people. Special thanks to | benefited from comments by multiple people. Special thanks to | |||
Richard Barnes, Dan Brown, Matt Campagna, Eric Crockett, Paul Grubbs, | Richard Barnes, Dan Brown, Matt Campagna, Eric Crockett, Paul Grubbs, | |||
Fredrik Kuivinen, Payman Mohassel, Jason Resch, Greg Rubin, and Nick | Fredrik Kuivinen, Stefan Marsiske, Payman Mohassel, Marta Mularczyk, | |||
Sullivan. Hugo Krawczyk wishes to thank his OPAQUE co-authors Stas | Jason Resch, Greg Rubin, and Nick Sullivan. Hugo Krawczyk wishes to | |||
Jarecki and Jiayu Xu without whom this work would have not been | thank his OPAQUE co-authors Stas Jarecki and Jiayu Xu without whom | |||
possible. | this work would have not been possible. | |||
Appendix B. Alternate Key Recovery Mechanisms | Appendix B. Alternate Key Recovery Mechanisms | |||
Client authentication material can be stored and retrieved using | Client authentication material can be stored and retrieved using | |||
different key recovery mechanisms. Any key recovery mechanism that | different key recovery mechanisms. Any key recovery mechanism that | |||
encrypts data in the envelope MUST use an authenticated encryption | encrypts data in the envelope MUST use an authenticated encryption | |||
scheme with random key-robustness (or key-committing). Deviating | scheme with random key-robustness (or key-committing). Deviating | |||
from the key-robustness requirement may open the protocol to attacks, | from the key-robustness requirement may open the protocol to attacks, | |||
e.g., [LGR20]. This specification enforces this property by using a | e.g., [LGR20]. This specification enforces this property by using a | |||
MAC over the envelope contents. | MAC over the envelope contents. | |||
skipping to change at page 58, line 31 ¶ | skipping to change at page 58, line 18 ¶ | |||
derived from it) with a quantum-safe encryption function. However, | derived from it) with a quantum-safe encryption function. However, | |||
the only effect of a break of the OPRF by a future quantum attacker | the only effect of a break of the OPRF by a future quantum attacker | |||
would be the ability of this attacker to run at that time an | would be the ability of this attacker to run at that time an | |||
exhaustive dictionary attack against the old user's password and only | exhaustive dictionary attack against the old user's password and only | |||
for users whose envelopes were harvested while in use (in the case of | for users whose envelopes were harvested while in use (in the case of | |||
OPAQUE run over a TLS channel with the server, harvesting such | OPAQUE run over a TLS channel with the server, harvesting such | |||
envelopes requires targeted active attacks). | envelopes requires targeted active attacks). | |||
C.1. HMQV Instantiation Sketch | C.1. HMQV Instantiation Sketch | |||
An HMQV instantiation would work similar to OPAQUE-3DH, differing | An HMQV instantiation would work similarly to OPAQUE-3DH, differing | |||
primarily in the key schedule [HMQV]. First, the key schedule | primarily in the key schedule [HMQV]. First, the key schedule | |||
preamble value would use a different constant prefix -- "HMQV" | preamble value would use a different constant prefix -- "HMQV" | |||
instead of "3DH" -- as shown below. | instead of "3DH" -- as shown below. | |||
preamble = concat("HMQV", | preamble = concat("HMQV", | |||
I2OSP(len(client_identity), 2), client_identity, | I2OSP(len(client_identity), 2), client_identity, | |||
KE1, | KE1, | |||
I2OSP(len(server_identity), 2), server_identity, | I2OSP(len(server_identity), 2), server_identity, | |||
KE2.credential_response, | KE2.credential_response, | |||
KE2.auth_response.server_nonce, | KE2.auth_response.server_nonce, | |||
skipping to change at page 59, line 25 ¶ | skipping to change at page 59, line 13 ¶ | |||
Likewise, s would be computed as follows: | Likewise, s would be computed as follows: | |||
hashInput = concat(I2OSP(len(epkS), 2), epkS, | hashInput = concat(I2OSP(len(epkS), 2), epkS, | |||
I2OSP(len(info), 2), info, | I2OSP(len(info), 2), info, | |||
I2OSP(len("server"), 2), "server") | I2OSP(len("server"), 2), "server") | |||
s = Hash(hashInput) mod L | s = Hash(hashInput) mod L | |||
Hash is the same hash function used in the main OPAQUE protocol for | Hash is the same hash function used in the main OPAQUE protocol for | |||
key derivation. Its output length (in bits) must be at least L. | key derivation. Its output length (in bits) must be at least L. | |||
Both parties should perform validation (as in Section 10.8) on each | Both parties should perform validation (as in Section 10.7) on each | |||
other's public keys before computing the above parameters. | other's public keys before computing the above parameters. | |||
C.2. SIGMA-I Instantiation Sketch | C.2. SIGMA-I Instantiation Sketch | |||
A [SIGMA-I] instantiation differs more drastically from OPAQUE-3DH | A [SIGMA-I] instantiation differs more drastically from OPAQUE-3DH | |||
since authentication uses digital signatures instead of Diffie- | since authentication uses digital signatures instead of Diffie- | |||
Hellman. In particular, both KE2 and KE3 would carry a digital | Hellman. In particular, both KE2 and KE3 would carry a digital | |||
signature, computed using the server and client private keys | signature, computed using the server and client private keys | |||
established during registration, respectively, as well as a MAC, | established during registration, respectively, as well as a MAC, | |||
where the MAC is computed as in OPAQUE-3DH. | where the MAC is computed as in OPAQUE-3DH. | |||
skipping to change at page 60, line 13 ¶ | skipping to change at page 60, line 8 ¶ | |||
computed during the authentication of an unknown or unregistered | computed during the authentication of an unknown or unregistered | |||
user. Note that masking_key, client_private_key, and | user. Note that masking_key, client_private_key, and | |||
client_public_key are used as additional inputs as described in | client_public_key are used as additional inputs as described in | |||
Section 6.3.2.2. client_public_key is used as the fake record's | Section 6.3.2.2. client_public_key is used as the fake record's | |||
public key, and masking_key for the fake record's masking key | public key, and masking_key for the fake record's masking key | |||
parameter. | parameter. | |||
All values are encoded in hexadecimal strings. The configuration | All values are encoded in hexadecimal strings. The configuration | |||
information includes the (OPRF, Hash, KSF, KDF, MAC, Group, Context) | information includes the (OPRF, Hash, KSF, KDF, MAC, Group, Context) | |||
tuple, where the Group matches that which is used in the OPRF. These | tuple, where the Group matches that which is used in the OPRF. These | |||
test vectors were generated using draft-21 of [OPRF]. The KSF used | test vectors were generated using [RFC9497]. The KSF used for each | |||
for each test vector is the identity function (denoted Identity), | test vector is the identity function (denoted Identity), which | |||
which returns as output the input message supplied to the function | returns as output the input message supplied to the function without | |||
without any modification, i.e., msg = Stretch(msg). | any modification, i.e., msg = Stretch(msg). | |||
D.1. Real Test Vectors | D.1. Real Test Vectors | |||
D.1.1. OPAQUE-3DH Real Test Vector 1 | D.1.1. OPAQUE-3DH Real Test Vector 1 | |||
D.1.1.1. Configuration | D.1.1.1. Configuration | |||
OPRF: ristretto255-SHA512 | OPRF: ristretto255-SHA512 | |||
Hash: SHA512 | Hash: SHA512 | |||
KSF: Identity | KSF: Identity | |||
End of changes. 75 change blocks. | ||||
190 lines changed or deleted | 169 lines changed or added | |||
This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |