Script updating gh-pages from ff9c892. [ci skip]

draft-irtf-cfrg-opaque.html

@@ -2065,8 +2065,11 @@ <h2 id="name-registration-2">
 credential file for each client along with the associated <code>credential_identifier</code>
 and <code>client_identity</code> (if different). Note that the values <code>oprf_seed</code> and
 <code>server_private_key</code> from the server's setup phase must also be persisted.
-The <code>oprf_seed</code> value SHOULD be used for all clients; see <a href="#preventing-client-enumeration" class="auto internal xref">Section 10.9</a>.
-The <code>server_private_key</code> may be unique for each client.<a href="#section-5-8" class="pilcrow">¶</a></p>
+The <code>oprf_seed</code> value SHOULD be used for all clients; see <a href="#preventing-client-enumeration" class="auto internal xref">Section 10.9</a>
+for the justification behind this, along with a description of the exception in which
+applications may choose to avoid the use of a global <code>oprf_seed</code> value across clients
+and instead sample OPRF keys uniquely for each client. The <code>server_private_key</code> may
+be unique for each client.<a href="#section-5-8" class="pilcrow">¶</a></p>
 <p id="section-5-9">Both client and server MUST validate the other party's public key before use.
 See <a href="#validation" class="auto internal xref">Section 10.7</a> for more details. Upon completion, the server stores
 the client's credentials for later use. Moreover, the client MAY use the output
@@ -3768,6 +3771,11 @@ <h3 id="name-client-enumeration">
 response during registration as an oracle for whether a given client identity is
 registered. Applications should mitigate against this type of attack by rate
 limiting or otherwise restricting the registration flow.<a href="#section-10.9-2" class="pilcrow">¶</a></p>
+<p id="section-10.9-3">Finally, applications that do not require protection against
+client enumeration attacks can choose to derive independent OPRF keys for different
+clients. The advantage to using independently-derived OPRF keys is that the server
+avoids keeping the <code>oprf_seed</code> value across different clients, which if leaked would
+compromise the security for all clients reliant on <code>oprf_seed</code>, as noted in <span>[<a href="#DL24" class="cite xref">DL24</a>]</span>.<a href="#section-10.9-3" class="pilcrow">¶</a></p>
 </section>
 </div>
 <div id="protecting-the-registration-masking-key">
@@ -3920,6 +3928,10 @@ <h3 id="name-informative-references">
         <dd>
 <span class="refAuthor">Langley, A.</span>, <span class="refAuthor">Hamburg, M.</span>, and <span class="refAuthor">S. Turner</span>, <span class="refTitle">"Elliptic Curves for Security"</span>, <span class="seriesInfo">RFC 7748</span>, <span class="seriesInfo">DOI 10.17487/RFC7748</span>, <time datetime="2016-01" class="refDate">January 2016</time>, <span>&lt;<a href="https://www.rfc-editor.org/rfc/rfc7748">https://www.rfc-editor.org/rfc/rfc7748</a>&gt;</span>. </dd>
 <dd class="break"></dd>
+<dt id="DL24">[DL24]</dt>
+        <dd>
+<span class="refAuthor">Dayanikli, D.</span> and <span class="refAuthor">A. Lehmann</span>, <span class="refTitle">"(Strong) aPAKE Revisited: Capturing Multi-User Security and Salting"</span>, <span class="seriesInfo">https://eprint.iacr.org/2024/756 </span>, <time datetime="2024" class="refDate">2024</time>. </dd>
+<dd class="break"></dd>
 <dt id="FIPS202">[FIPS202]</dt>
         <dd>
 <span class="refAuthor">National Institute of Standards and Technology (NIST)</span>, <span class="refTitle">"SHA-3 Standard: Permutation-Based Hash and Extendable-Output Functions"</span>, <time datetime="2015-08" class="refDate">August 2015</time>, <span>&lt;<a href="https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.202.pdf">https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.202.pdf</a>&gt;</span>. </dd>

draft-irtf-cfrg-opaque.txt

@@ -708,8 +708,11 @@ def Recover(randomized_password, server_public_key, envelope,
    credential_identifier and client_identity (if different).  Note that
    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
-   all clients; see Section 10.9.  The server_private_key may be unique
-   for each client.
+   all clients; see Section 10.9 for the justification behind this,
+   along with a description of the exception in which applications may
+   choose to avoid the use of a global oprf_seed value across clients
+   and instead sample OPRF keys uniquely for each client.  The
+   server_private_key may be unique for each client.
 
    Both client and server MUST validate the other party's public key
    before use.  See Section 10.7 for more details.  Upon completion, the
@@ -2223,6 +2226,13 @@ def AuthServerRespond(cleartext_credentials, server_private_key, client_public_k
    Applications should mitigate against this type of attack by rate
    limiting or otherwise restricting the registration flow.
 
+   Finally, applications that do not require protection against client
+   enumeration attacks can choose to derive independent OPRF keys for
+   different clients.  The advantage to using independently-derived OPRF
+   keys is that the server avoids keeping the oprf_seed value across
+   different clients, which if leaked would compromise the security for
+   all clients reliant on oprf_seed, as noted in [DL24].
+
 10.10.  Protecting the Registration Masking Key
 
    The user enumeration prevention method described in this document
@@ -2359,6 +2369,10 @@ def AuthServerRespond(cleartext_credentials, server_private_key, client_public_k
               for Security", RFC 7748, DOI 10.17487/RFC7748, January
               2016, <https://www.rfc-editor.org/rfc/rfc7748>.
 
+   [DL24]     Dayanikli, D. and A. Lehmann, "(Strong) aPAKE Revisited:
+              Capturing Multi-User Security and Salting",
+              https://eprint.iacr.org/2024/756 , 2024.
+
    [FIPS202]  National Institute of Standards and Technology (NIST),
               "SHA-3 Standard: Permutation-Based Hash and Extendable-
               Output Functions", August 2015,