Skip to content

Commit

Permalink
Script updating gh-pages from 423b515. [ci skip]
Browse files Browse the repository at this point in the history
  • Loading branch information
ID Bot committed Sep 19, 2023
1 parent 44cfc61 commit 93d9c8d
Show file tree
Hide file tree
Showing 2 changed files with 57 additions and 41 deletions.
50 changes: 28 additions & 22 deletions draft-irtf-cfrg-opaque.html
View file
Original file line number Diff line number Diff line change
Expand Up @@ -1061,7 +1061,7 @@
</tr></thead>
<tfoot><tr>
<td class="left">Bourdrez, et al.</td>
<td class="center">Expires 16 March 2024</td>
<td class="center">Expires 22 March 2024</td>
<td class="right">[Page]</td>
</tr></tfoot>
</table>
Expand All @@ -1074,12 +1074,12 @@
<dd class="internet-draft">draft-irtf-cfrg-opaque-latest</dd>
<dt class="label-published">Published:</dt>
<dd class="published">
<time datetime="2023-09-13" class="published">13 September 2023</time>
<time datetime="2023-09-19" class="published">19 September 2023</time>
</dd>
<dt class="label-intended-status">Intended Status:</dt>
<dd class="intended-status">Informational</dd>
<dt class="label-expires">Expires:</dt>
<dd class="expires"><time datetime="2024-03-16">16 March 2024</time></dd>
<dd class="expires"><time datetime="2024-03-22">22 March 2024</time></dd>
<dt class="label-authors">Authors:</dt>
<dd class="authors">
<div class="author">
Expand Down Expand Up @@ -1139,7 +1139,7 @@ <h2 id="name-status-of-this-memo">
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."<a href="#section-boilerplate.1-3" class="pilcrow"></a></p>
<p id="section-boilerplate.1-4">
This Internet-Draft will expire on 16 March 2024.<a href="#section-boilerplate.1-4" class="pilcrow"></a></p>
This Internet-Draft will expire on 22 March 2024.<a href="#section-boilerplate.1-4" class="pilcrow"></a></p>
</section>
</div>
<div id="copyright">
Expand Down Expand Up @@ -1608,7 +1608,7 @@ <h3 id="name-oblivious-pseudorandom-func">
</ul>
<p id="section-2.1-6">Finally, this specification makes use of the following shared APIs and parameters:<a href="#section-2.1-6" class="pilcrow"></a></p>
<ul class="normal">
<li class="normal" id="section-2.1-7.1">SerializeElement(element): Map input <code>element</code> to a fixed-length byte array <code>buf</code>.<a href="#section-2.1-7.1" class="pilcrow"></a>
<li class="normal" id="section-2.1-7.1">SerializeElement(element): Map input <code>element</code> to a fixed-length byte array.<a href="#section-2.1-7.1" class="pilcrow"></a>
</li>
<li class="normal" id="section-2.1-7.2">DeserializeElement(buf): Attempt to map input byte array <code>buf</code> to an OPRF group element.
This function can raise a DeserializeError upon failure; see <span>[<a href="#OPRF" class="cite xref">OPRF</a>], <a href="https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-voprf-21#section-2.1" class="relref">Section 2.1</a></span>
Expand Down Expand Up @@ -1681,7 +1681,7 @@ <h3 id="name-hash-functions">
<h2 id="name-protocol-overview">
<a href="#section-3" class="section-number selfRef">3. </a><a href="#name-protocol-overview" class="section-name selfRef">Protocol Overview</a>
</h2>
<p id="section-3-1">OPAQUE consists of two stages: registration and authenticated key exchange.
<p id="section-3-1">OPAQUE consists of two stages: registration and authenticated key exchange (AKE).
In the first stage, a client registers its password with the server and stores
its credential file on the server. In the second stage (also called the
"login" stage), the client recovers its authentication material and uses it to
Expand Down Expand Up @@ -1712,8 +1712,8 @@ <h3 id="name-offline-registration">
identifier, and the server inputs its parameters, which include its private key
and other information.<a href="#section-3.2-2" class="pilcrow"></a></p>
<p id="section-3.2-3">The client output of this stage is a single value <code>export_key</code> that the client
may use for application-specific purposes, e.g., to encrypt additional
information for storage on the server. The server does not have access to this
may use for application-specific purposes, e.g., as a symmetric key used to encrypt
additional information for storage on the server. The server does not have access to this
<code>export_key</code>.<a href="#section-3.2-3" class="pilcrow"></a></p>
<p id="section-3.2-4">The server output of this stage is a record corresponding to the client's
registration that it stores in a credential file alongside other clients
Expand Down Expand Up @@ -1822,7 +1822,7 @@ <h2 id="name-client-credential-storage-a">
information about this identity.<a href="#section-4-4.5" class="pilcrow"></a>
</li>
</ul>
<p id="section-4-5">These credential values are used in the <code>CleartextCredentials</code> structure as follows:<a href="#section-4-5" class="pilcrow"></a></p>
<p id="section-4-5">A subset of these credential values are used in the <code>CleartextCredentials</code> structure as follows:<a href="#section-4-5" class="pilcrow"></a></p>
<div class="alignLeft art-text artwork" id="section-4-6">
<pre>
struct {
Expand Down Expand Up @@ -1882,7 +1882,7 @@ <h4 id="name-envelope-structure">
} Envelope;
</pre><a href="#section-4.1.1-2" class="pilcrow"></a>
</div>
<p id="section-4.1.1-3">nonce: A unique nonce of length <code>Nn</code>, used to protect this <code>Envelope</code>.<a href="#section-4.1.1-3" class="pilcrow"></a></p>
<p id="section-4.1.1-3">nonce: A randomly-sampled nonce of length <code>Nn</code>, used to protect this <code>Envelope</code>.<a href="#section-4.1.1-3" class="pilcrow"></a></p>
<p id="section-4.1.1-4">auth_tag: An authentication tag protecting the contents of the envelope, covering
the envelope nonce and <code>CleartextCredentials</code>.<a href="#section-4.1.1-4" class="pilcrow"></a></p>
</section>
Expand Down Expand Up @@ -1974,6 +1974,8 @@ <h4 id="name-envelope-recovery">
return (client_private_key, cleartext_credentials, export_key)
</pre><a href="#section-4.1.3-2" class="pilcrow"></a>
</div>
<p id="section-4.1.3-3">In the case of <code>EnvelopeRecoveryError</code> being raised, all previously-computed
intermediary values in this function MUST be deleted.<a href="#section-4.1.3-3" class="pilcrow"></a></p>
</section>
</div>
</section>
Expand Down Expand Up @@ -2102,7 +2104,7 @@ <h4 id="name-createregistrationrequest">
<a href="#section-5.2.1" class="section-number selfRef">5.2.1. </a><a href="#name-createregistrationrequest" class="section-name selfRef">CreateRegistrationRequest</a>
</h4>
<p id="section-5.2.1-1">To begin the registration flow, the client executes the following function. This function
can fail with a InvalidInputError error with negligibile probability. A different input
can fail with an <code>InvalidInputError</code> error with negligibile probability. A different input
password is necessary in the event of this error.<a href="#section-5.2.1-1" class="pilcrow"></a></p>
<div class="alignLeft art-text artwork" id="section-5.2.1-2">
<pre>
Expand Down Expand Up @@ -2535,7 +2537,7 @@ <h4 id="name-serverfinish">
</div>
<p id="section-6.2.4-3">This function MUST NOT return the <code>session_key</code> value if the client authentication
material is invalid, and may instead return an appropriate error message such as
ClientAuthenticationError, invoked from <code>AuthServerFinalize</code>.<a href="#section-6.2.4-3" class="pilcrow"></a></p>
<code>ClientAuthenticationError</code>, invoked from <code>AuthServerFinalize</code>.<a href="#section-6.2.4-3" class="pilcrow"></a></p>
</section>
</div>
</section>
Expand Down Expand Up @@ -2592,7 +2594,7 @@ <h5 id="name-createcredentialrequest">
</h5>
<p id="section-6.3.2.1-1">The <code>CreateCredentialRequest</code> is used by the client to initiate the credential
retrieval process, and it produces a <code>CredentialRequest</code> message and OPRF state.
Like <code>CreateRegistrationRequest</code>, this function can fail with a InvalidInputError
Like <code>CreateRegistrationRequest</code>, this function can fail with an <code>InvalidInputError</code>
error with negligibile probability. However, this should not occur since
registration (via <code>CreateRegistrationRequest</code>) will fail when provided the same
password input.<a href="#section-6.3.2.1-1" class="pilcrow"></a></p>
Expand Down Expand Up @@ -2687,7 +2689,7 @@ <h5 id="name-createcredentialresponse">
</li>
</ul>
<p id="section-6.3.2.2-7">It is RECOMMENDED that a fake client record is created once (e.g. as the first user record
of the application) and stored alongside legitimate client records. This allows servers to locate
of the application) and stored alongside legitimate client records. This allows servers to retrieve
the record in a time comparable to that of a legitimate client record.<a href="#section-6.3.2.2-7" class="pilcrow"></a></p>
<p id="section-6.3.2.2-8">Note that the responses output by either scenario are indistinguishable to an adversary
that is unable to guess the registered password for the client corresponding to <code>credential_identifier</code>.<a href="#section-6.3.2.2-8" class="pilcrow"></a></p>
Expand Down Expand Up @@ -3141,7 +3143,8 @@ <h2 id="name-configurations">
and SHA-256 and SHA-512 for the Hash functions. If an extensible output function
such as SHAKE128 <span>[<a href="#FIPS202" class="cite xref">FIPS202</a>]</span> is used then the output length <code>Nh</code> MUST be chosen
to align with the target security level of the OPAQUE configuration. For example,
if the target security parameter for the configuration is 128-bits, then <code>Nh</code> SHOULD be at least 32 bytes.<a href="#section-7-2.2" class="pilcrow"></a>
if the target security parameter for the configuration is 128 bits, then <code>Nh</code> SHOULD
be at least 32 bytes.<a href="#section-7-2.2" class="pilcrow"></a>
</li>
<li class="normal" id="section-7-2.3">The KSF is determined by the application and implements the interface in
<a href="#dependencies" class="auto internal xref">Section 2</a>. As noted, collision resistance is required. Examples for KSF
Expand All @@ -3168,17 +3171,18 @@ <h2 id="name-configurations">
<li class="normal" id="section-7-5.3">P256-SHA256, HKDF-SHA-256, HMAC-SHA-256, SHA-256, scrypt(N = 32768, r = 8, p = 1), P-256<a href="#section-7-5.3" class="pilcrow"></a>
</li>
</ul>
<p id="section-7-6">Future configurations may specify different combinations of dependent algorithms,
with the following considerations:<a href="#section-7-6" class="pilcrow"></a></p>
<ol start="1" type="1" class="normal type-1" id="section-7-7">
<li id="section-7-7.1">The size of AKE public and private keys -- <code>Npk</code> and <code>Nsk</code>, respectively -- must adhere
<p id="section-7-6">The above recommended configurations target 128-bit security.<a href="#section-7-6" class="pilcrow"></a></p>
<p id="section-7-7">Future configurations may specify different combinations of dependent algorithms,
with the following considerations:<a href="#section-7-7" class="pilcrow"></a></p>
<ol start="1" type="1" class="normal type-1" id="section-7-8">
<li id="section-7-8.1">The size of AKE public and private keys -- <code>Npk</code> and <code>Nsk</code>, respectively -- must adhere
to the output length limitations of the KDF Expand function. If HKDF is used, this means
Npk, Nsk &lt;= 255 * Nx, where Nx is the output size of the underlying hash function.
See <span>[<a href="#RFC5869" class="cite xref">RFC5869</a>]</span> for details.<a href="#section-7-7.1" class="pilcrow"></a>
See <span>[<a href="#RFC5869" class="cite xref">RFC5869</a>]</span> for details.<a href="#section-7-8.1" class="pilcrow"></a>
</li>
<li id="section-7-7.2">The output size of the Hash function SHOULD be long enough to produce a key for
<li id="section-7-8.2">The output size of the Hash function SHOULD be long enough to produce a key for
MAC of suitable length. For example, if MAC is HMAC-SHA256, then <code>Nh</code> could be
32 bytes.<a href="#section-7-7.2" class="pilcrow"></a>
32 bytes.<a href="#section-7-8.2" class="pilcrow"></a>
</li>
</ol>
</section>
Expand Down Expand Up @@ -3715,6 +3719,8 @@ <h3 id="name-password-salt-and-storage-i">
NOT RECOMMENDED. Applications should move such checks to the client. Note that
limited checks at the server are possible to implement, e.g., detecting repeated
passwords.<a href="#section-10.11-2" class="pilcrow"></a></p>
<p id="section-10.11-3">In general, passwords should be selected with sufficient entropy to avoid being susceptible
to recovery through dictionary attacks, both online and offline.<a href="#section-10.11-3" class="pilcrow"></a></p>
</section>
</div>
<div id="ake-private-key-storage">
Expand Down
48 changes: 29 additions & 19 deletions draft-irtf-cfrg-opaque.txt
View file
Original file line number Diff line number Diff line change
Expand Up @@ -5,12 +5,12 @@
Network Working Group D. Bourdrez
Internet-Draft
Intended status: Informational H. Krawczyk
Expires: 16 March 2024 Algorand Foundation
Expires: 22 March 2024 Algorand Foundation
K. Lewi
Meta
C. A. Wood
Cloudflare, Inc.
13 September 2023
19 September 2023


The OPAQUE Asymmetric PAKE Protocol
Expand Down Expand Up @@ -49,7 +49,7 @@ Status of This Memo
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."

This Internet-Draft will expire on 16 March 2024.
This Internet-Draft will expire on 22 March 2024.

Copyright Notice

Expand Down Expand Up @@ -318,7 +318,7 @@ Table of Contents
and parameters:

* SerializeElement(element): Map input element to a fixed-length
byte array buf.
byte array.

* DeserializeElement(buf): Attempt to map input byte array buf to an
OPRF group element. This function can raise a DeserializeError
Expand Down Expand Up @@ -374,8 +374,8 @@ Table of Contents
3. Protocol Overview

OPAQUE consists of two stages: registration and authenticated key
exchange. In the first stage, a client registers its password with
the server and stores its credential file on the server. In the
exchange (AKE). In the first stage, a client registers its password
with the server and stores its credential file on the server. In the
second stage (also called the "login" stage), the client recovers its
authentication material and uses it to perform a mutually
authenticated key exchange.
Expand All @@ -402,9 +402,9 @@ Table of Contents
its private key and other information.

The client output of this stage is a single value export_key that the
client may use for application-specific purposes, e.g., to encrypt
additional information for storage on the server. The server does
not have access to this export_key.
client may use for application-specific purposes, e.g., as a
symmetric key used to encrypt additional information for storage on
the server. The server does not have access to this export_key.

The server output of this stage is a record corresponding to the
client's registration that it stores in a credential file alongside
Expand Down Expand Up @@ -512,8 +512,8 @@ Table of Contents
server's public key. See Section 10.4 for information about this
identity.

These credential values are used in the CleartextCredentials
structure as follows:
A subset of these credential values are used in the
CleartextCredentials structure as follows:

struct {
uint8 server_public_key[Npk];
Expand Down Expand Up @@ -564,7 +564,8 @@ def CreateCleartextCredentials(server_public_key, client_public_key,
uint8 auth_tag[Nm];
} Envelope;

nonce: A unique nonce of length Nn, used to protect this Envelope.
nonce: A randomly-sampled nonce of length Nn, used to protect this
Envelope.

auth_tag: An authentication tag protecting the contents of the
envelope, covering the envelope nonce and CleartextCredentials.
Expand Down Expand Up @@ -644,6 +645,9 @@ def Recover(randomized_password, server_public_key, envelope,
raise EnvelopeRecoveryError
return (client_private_key, cleartext_credentials, export_key)

In the case of EnvelopeRecoveryError being raised, all previously-
computed intermediary values in this function MUST be deleted.

5. Offline Registration

The registration process proceeds as follows. The client inputs the
Expand Down Expand Up @@ -753,9 +757,9 @@ def Recover(randomized_password, server_public_key, envelope,
5.2.1. CreateRegistrationRequest

To begin the registration flow, the client executes the following
function. This function can fail with a InvalidInputError error with
negligibile probability. A different input password is necessary in
the event of this error.
function. This function can fail with an InvalidInputError error
with negligibile probability. A different input password is
necessary in the event of this error.

CreateRegistrationRequest

Expand Down Expand Up @@ -1176,7 +1180,7 @@ def GenerateKE3(client_identity, server_identity, ke2):
The CreateCredentialRequest is used by the client to initiate the
credential retrieval process, and it produces a CredentialRequest
message and OPRF state. Like CreateRegistrationRequest, this
function can fail with a InvalidInputError error with negligibile
function can fail with an InvalidInputError error with negligibile
probability. However, this should not occur since registration (via
CreateRegistrationRequest) will fail when provided the same password
input.
Expand Down Expand Up @@ -1264,8 +1268,8 @@ def CreateCredentialResponse(request, server_public_key, record,

It is RECOMMENDED that a fake client record is created once (e.g. as
the first user record of the application) and stored alongside
legitimate client records. This allows servers to locate the record
in a time comparable to that of a legitimate client record.
legitimate client records. This allows servers to retrieve the
record in a time comparable to that of a legitimate client record.

Note that the responses output by either scenario are
indistinguishable to an adversary that is unable to guess the
Expand Down Expand Up @@ -1650,7 +1654,7 @@ def AuthServerRespond(cleartext_credentials, server_private_key, client_public_k
[FIPS202] is used then the output length Nh MUST be chosen to
align with the target security level of the OPAQUE configuration.
For example, if the target security parameter for the
configuration is 128-bits, then Nh SHOULD be at least 32 bytes.
configuration is 128 bits, then Nh SHOULD be at least 32 bytes.

* The KSF is determined by the application and implements the
interface in Section 2. As noted, collision resistance is
Expand Down Expand Up @@ -1681,6 +1685,8 @@ def AuthServerRespond(cleartext_credentials, server_private_key, client_public_k
* P256-SHA256, HKDF-SHA-256, HMAC-SHA-256, SHA-256, scrypt(N =
32768, r = 8, p = 1), P-256

The above recommended configurations target 128-bit security.

Future configurations may specify different combinations of dependent
algorithms, with the following considerations:

Expand Down Expand Up @@ -2244,6 +2250,10 @@ def AuthServerRespond(cleartext_credentials, server_private_key, client_public_k
the server are possible to implement, e.g., detecting repeated
passwords.

In general, passwords should be selected with sufficient entropy to
avoid being susceptible to recovery through dictionary attacks, both
online and offline.

10.12. AKE Private Key Storage

Server implementations of OPAQUE do not need access to the raw AKE
Expand Down

0 comments on commit 93d9c8d

Please sign in to comment.