Skip to content

Commit

Permalink
Script updating gh-pages from dc9031d. [ci skip]
Browse files Browse the repository at this point in the history
  • Loading branch information
ID Bot committed Sep 26, 2024
1 parent e560f1e commit 35f4bf4
Show file tree
Hide file tree
Showing 2 changed files with 83 additions and 68 deletions.
61 changes: 33 additions & 28 deletions draft-irtf-cfrg-cpace.html
View file
Original file line number Diff line number Diff line change
Expand Up @@ -1034,7 +1034,7 @@
</tr></thead>
<tfoot><tr>
<td class="left">Abdalla, et al.</td>
<td class="center">Expires 29 March 2025</td>
<td class="center">Expires 30 March 2025</td>
<td class="right">[Page]</td>
</tr></tfoot>
</table>
Expand All @@ -1047,12 +1047,12 @@
<dd class="internet-draft">draft-irtf-cfrg-cpace-latest</dd>
<dt class="label-published">Published:</dt>
<dd class="published">
<time datetime="2024-09-25" class="published">25 September 2024</time>
<time datetime="2024-09-26" class="published">26 September 2024</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="2025-03-29">29 March 2025</time></dd>
<dd class="expires"><time datetime="2025-03-30">30 March 2025</time></dd>
<dt class="label-authors">Authors:</dt>
<dd class="authors">
<div class="author">
Expand Down Expand Up @@ -1109,7 +1109,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 29 March 2025.<a href="#section-boilerplate.1-4" class="pilcrow"></a></p>
This Internet-Draft will expire on 30 March 2025.<a href="#section-boilerplate.1-4" class="pilcrow"></a></p>
</section>
</div>
<div id="copyright">
Expand Down Expand Up @@ -1676,7 +1676,7 @@ <h3 id="name-outline-of-this-document">
functions defined for CPace in the appendix.<a href="#section-1.1-1.5.1" class="pilcrow"></a></p>
</li>
</ul>
<p id="section-1.1-2">As this document is primarily written for implementers and application designers, we would like to refer the theory-inclined reader to the scientific paper <span>[<a href="#AHH21" class="cite xref">AHH21</a>]</span> which covers the detailed security analysis of the different CPace instantiations as defined in this document via the cipher suites.<a href="#section-1.1-2" class="pilcrow"></a></p>
<p id="section-1.1-2">As this document is primarily written for implementers and application designers, we would like to refer the theory-inclined reader to the scientific papers <span>[<a href="#AHH21" class="cite xref">AHH21</a>]</span> which covers the detailed security analysis of the different CPace instantiations as defined in this document via the cipher suites.<a href="#section-1.1-2" class="pilcrow"></a></p>
</section>
</div>
</section>
Expand Down Expand Up @@ -1711,39 +1711,42 @@ <h3 id="name-optional-cpace-inputs">
<p id="section-3.1-1">For accomodating different application settings, CPace offers the following OPTIONAL inputs, i.e. inputs which MAY also be the empty string:<a href="#section-3.1-1" class="pilcrow"></a></p>
<ul class="normal">
<li class="normal" id="section-3.1-2.1">
<p id="section-3.1-2.1.1">Party identities (A,B).
In CPace each party should best be given a party identity string, which
might be a device name a user name or an URL. The advantage of using party identity identifiers is
that these will become authenticated in the course of the protocol run if integrated.
If party identity strings are available, an application should include identity strings. This is done best
as part of the channel identifier CI or, alternatively, if they are not available for both parties at the beginning of the
protocol run as part of the the associated data fields.<a href="#section-3.1-2.1.1" class="pilcrow"></a></p>
<p id="section-3.1-2.1.1">Party identity strings (A,B).
In CPace each party can be be given a party identity string which
might be a device name a user name or an URL.
CPace offers two alternative options for authenticating the party identifiers in the course of the protocol run.
The preferred option is the integration of both, A and B into the channel identifier string CI. This is preferred as A and B will be kept
confidential and as this provides security advantages (see <a href="#sec-quantum-annoying" class="auto internal xref">Section 9.11</a>).
Integrating A,B into CI requires that both parties know the party identity string of the communication partner
before starting the protocol. If this requirement is not fullfilled in an application setting then CPace offers the alternative of
integrating A as part of the optional input ADa and B as part of the optional input ADb.<a href="#section-3.1-2.1.1" class="pilcrow"></a></p>
</li>
<li class="normal" id="section-3.1-2.2">
<p id="section-3.1-2.2.1">Channel identifier (CI).
CI can be used to bind a session key exchanged with CPace to a specific networking channel which interconnects the protocol parties.
CI could for instance include networking addresses of both parties or party identity strings.
Both parties are required to have the same view of CI. CI will not be publicly sent on the wire and may also include confidential
information. If both parties have an expected party identity field of the
communication partner available before starting the protocol, it is
RECOMMENDED to include the party identifiers as part of the CI string.<a href="#section-3.1-2.2.1" class="pilcrow"></a></p>
information. Both parties will only establish a common session key if they initiated the protocol with the same view of CI.<a href="#section-3.1-2.2.1" class="pilcrow"></a></p>
</li>
<li class="normal" id="section-3.1-2.3">
<p id="section-3.1-2.3.1">Associated data fields (ADa and ADb).
These fields can be used to authenticate public associated data alongside the CPace protocol.
The values ADa (and ADb, respectively) are guaranteed to be authenticated
in case both parties agree on a common key. ADa and ADb will be send publicly on the wire.<a href="#section-3.1-2.3.1" class="pilcrow"></a></p>
These fields can be used to authenticate associated data alongside the CPace protocol.
The ADa and ADb will be sent in clear text as part of the protocol messages.
ADa and ADb will become authenticated in a CPace protocol run as
both parties will only agree on a common key if they have the same view on ADa and ADb.<a href="#section-3.1-2.3.1" class="pilcrow"></a></p>
<p id="section-3.1-2.3.2">
If party identities are not encoded as part of CI, party identities (A,B) SHOULD be included in ADa and ADb instead
(see <a href="#sec-considerations-ids" class="auto internal xref">Section 9.1</a>).
If an application cannot integrate the party identities as part of CI, party identities (A,B) SHOULD be included in ADa and ADb instead
(see <a href="#sec-considerations-ids" class="auto internal xref">Section 9.1</a>).<a href="#section-3.1-2.3.2" class="pilcrow"></a></p>
<p id="section-3.1-2.3.3">
In a setting with clear initiator and responder roles, identity information in ADa
sent by the initiator can be used by the responder for choosing the right PRS string (respectively password) for this identity.
ADa and ADb could also include protocol version information of an application protocol (e.g. to avoid downgrade attacks).<a href="#section-3.1-2.3.2" class="pilcrow"></a></p>
sent by the initiator can be used by the responder for choosing the matching PRS string (respectively password) for this identity.
ADa and ADb could also include application protocol version information of an application protocol (e.g. to avoid downgrade attacks).<a href="#section-3.1-2.3.3" class="pilcrow"></a></p>
</li>
<li class="normal" id="section-3.1-2.4">
<p id="section-3.1-2.4.1">Session identifier (sid).
If both parties have access to the same unique string sid being specific for a communication session before starting the protocol,
it is RECOMMENDED to use this sid value as an additional input for the protocol.
See <a href="#sec-considerations-ids" class="auto internal xref">Section 9.1</a> on how presence or absence of sid affects the "quantum annoying" property of CPace.<a href="#section-3.1-2.4.1" class="pilcrow"></a></p>
it is RECOMMENDED to forward this sid value as an additional input for the protocol as this provides security advantages
and will bind the CPace run to this communication session (see <a href="#sec-considerations" class="auto internal xref">Section 9</a>).<a href="#section-3.1-2.4.1" class="pilcrow"></a></p>
</li>
</ul>
</section>
Expand All @@ -1754,7 +1757,7 @@ <h3 id="name-optional-cpace-output">
<a href="#section-3.2" class="section-number selfRef">3.2. </a><a href="#name-optional-cpace-output" class="section-name selfRef">Optional CPace output</a>
</h3>
<p id="section-3.2-1">If a session identifier is not available as input at protocol start CPace can optionally produce a session identifier sid_output
as output that might be helpful for actions subsequent to the CPace protocol step (see <a href="#sec-sid-output" class="auto internal xref">Section 9.6</a>).<a href="#section-3.2-1" class="pilcrow"></a></p>
as output that might be helpful for the application for actions subsequent to the CPace protocol step (see <a href="#sec-sid-output" class="auto internal xref">Section 9.6</a>).<a href="#section-3.2-1" class="pilcrow"></a></p>
</section>
</div>
<div id="responsibilities-of-the-application-layer">
Expand Down Expand Up @@ -2582,7 +2585,7 @@ <h3 id="name-side-channel-attacks">
sampling and scalar multiplication should be protected from side-channels.<a href="#section-9.10-3" class="pilcrow"></a></p>
</section>
</div>
<div id="quantum-computers">
<div id="sec-quantum-annoying">
<section id="section-9.11">
<h3 id="name-quantum-computers">
<a href="#section-9.11" class="section-number selfRef">9.11. </a><a href="#name-quantum-computers" class="section-name selfRef">Quantum computers</a>
Expand All @@ -2593,7 +2596,9 @@ <h3 id="name-quantum-computers">
Still, even in case that LSQC emerge, it is reasonable to assume that discrete-logarithm computations will remain costly. CPace with ephemeral pre-established session id values
sid forces the adversary to solve one computational Diffie-Hellman problem per password guess <span>[<a href="#ES21" class="cite xref">ES21</a>]</span>.
If party identifiers are included as part of CI then the adversary is forced to solve one computational Diffie-Hellman problem per password
guess and party identifier pair.<a href="#section-9.11-1" class="pilcrow"></a></p>
guess and party identifier pair.
For this reason it is RECOMMENDED to use the optional inputs sid if available in an application setting.
For the same reason it is RECOMMENDED to integrate party identity strings A,B into CI.<a href="#section-9.11-1" class="pilcrow"></a></p>
<p id="section-9.11-2">In this sense, using the wording suggested by Steve Thomas on the CFRG mailing list, CPace is "quantum-annoying".<a href="#section-9.11-2" class="pilcrow"></a></p>
</section>
</div>
Expand Down Expand Up @@ -2697,7 +2702,7 @@ <h3 id="name-informative-references">
<dd class="break"></dd>
<dt id="REFIMP">[REFIMP]</dt>
<dd>
<span class="refTitle">"CPace reference implementation (sage)"</span>, <span>n.d.</span>, <span>&lt;<a href="https://github.com/cfrg/draft-irtf-cfrg-cpace/tree/master/poc">https://github.com/cfrg/draft-irtf-cfrg-cpace/tree/master/poc</a>&gt;</span>. </dd>
<span class="refTitle">"CPace reference implementation (sage)"</span>, <time datetime="2024-09" class="refDate">September 2024</time>, <span>&lt;<a href="https://github.com/cfrg/draft-irtf-cfrg-cpace/tree/master/poc">https://github.com/cfrg/draft-irtf-cfrg-cpace/tree/master/poc</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC2104">[RFC2104]</dt>
<dd>
Expand Down
90 changes: 50 additions & 40 deletions draft-irtf-cfrg-cpace.txt
View file
Original file line number Diff line number Diff line change
Expand Up @@ -5,10 +5,10 @@
Network Working Group M. Abdalla
Internet-Draft Nexus - San Francisco
Intended status: Informational B. Haase
Expires: 29 March 2025 Endress + Hauser Liquid Analysis - Gerlingen
Expires: 30 March 2025 Endress + Hauser Liquid Analysis - Gerlingen
J. Hesse
IBM Research Europe - Zurich
25 September 2024
26 September 2024


CPace, a balanced composable PAKE
Expand Down Expand Up @@ -48,7 +48,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 29 March 2025.
This Internet-Draft will expire on 30 March 2025.

Copyright Notice

Expand Down Expand Up @@ -282,7 +282,7 @@ Table of Contents

As this document is primarily written for implementers and
application designers, we would like to refer the theory-inclined
reader to the scientific paper [AHH21] which covers the detailed
reader to the scientific papers [AHH21] which covers the detailed
security analysis of the different CPace instantiations as defined in
this document via the cipher suites.

Expand Down Expand Up @@ -332,53 +332,60 @@ Table of Contents
following OPTIONAL inputs, i.e. inputs which MAY also be the empty
string:

* Party identities (A,B). In CPace each party should best be given
a party identity string, which might be a device name a user name
or an URL. The advantage of using party identity identifiers is
that these will become authenticated in the course of the protocol
run if integrated. If party identity strings are available, an
application should include identity strings. This is done best as
part of the channel identifier CI or, alternatively, if they are
not available for both parties at the beginning of the protocol
run as part of the the associated data fields.
* Party identity strings (A,B). In CPace each party can be be given
a party identity string which might be a device name a user name
or an URL. CPace offers two alternative options for
authenticating the party identifiers in the course of the protocol
run. The preferred option is the integration of both, A and B
into the channel identifier string CI. This is preferred as A and
B will be kept confidential and as this provides security
advantages (see Section 9.11). Integrating A,B into CI requires
that both parties know the party identity string of the
communication partner before starting the protocol. If this
requirement is not fullfilled in an application setting then CPace
offers the alternative of integrating A as part of the optional
input ADa and B as part of the optional input ADb.

* Channel identifier (CI). CI can be used to bind a session key
exchanged with CPace to a specific networking channel which
interconnects the protocol parties. Both parties are required to
have the same view of CI. CI will not be publicly sent on the
wire and may also include confidential information. If both
parties have an expected party identity field of the communication
partner available before starting the protocol, it is RECOMMENDED
to include the party identifiers as part of the CI string.
interconnects the protocol parties. CI could for instance include
networking addresses of both parties or party identity strings.
Both parties are required to have the same view of CI. CI will
not be publicly sent on the wire and may also include confidential
information. Both parties will only establish a common session
key if they initiated the protocol with the same view of CI.

* Associated data fields (ADa and ADb). These fields can be used to
authenticate public associated data alongside the CPace protocol.
The values ADa (and ADb, respectively) are guaranteed to be
authenticated in case both parties agree on a common key. ADa and
ADb will be send publicly on the wire.

If party identities are not encoded as part of CI, party
identities (A,B) SHOULD be included in ADa and ADb instead (see
Section 9.1). In a setting with clear initiator and responder
roles, identity information in ADa sent by the initiator can be
used by the responder for choosing the right PRS string
(respectively password) for this identity. ADa and ADb could also
include protocol version information of an application protocol
(e.g. to avoid downgrade attacks).
authenticate associated data alongside the CPace protocol. The
ADa and ADb will be sent in clear text as part of the protocol
messages. ADa and ADb will become authenticated in a CPace
protocol run as both parties will only agree on a common key if
they have the same view on ADa and ADb.

If an application cannot integrate the party identities as part of
CI, party identities (A,B) SHOULD be included in ADa and ADb
instead (see Section 9.1).

In a setting with clear initiator and responder roles, identity
information in ADa sent by the initiator can be used by the
responder for choosing the matching PRS string (respectively
password) for this identity. ADa and ADb could also include
application protocol version information of an application
protocol (e.g. to avoid downgrade attacks).

* Session identifier (sid). If both parties have access to the same
unique string sid being specific for a communication session
before starting the protocol, it is RECOMMENDED to use this sid
value as an additional input for the protocol. See Section 9.1 on
how presence or absence of sid affects the "quantum annoying"
property of CPace.
before starting the protocol, it is RECOMMENDED to forward this
sid value as an additional input for the protocol as this provides
security advantages and will bind the CPace run to this
communication session (see Section 9).

3.2. Optional CPace output

If a session identifier is not available as input at protocol start
CPace can optionally produce a session identifier sid_output as
output that might be helpful for actions subsequent to the CPace
protocol step (see Section 9.6).
output that might be helpful for the application for actions
subsequent to the CPace protocol step (see Section 9.6).

3.3. Responsibilities of the application layer

Expand Down Expand Up @@ -1258,7 +1265,10 @@ Table of Contents
computational Diffie-Hellman problem per password guess [ES21]. If
party identifiers are included as part of CI then the adversary is
forced to solve one computational Diffie-Hellman problem per password
guess and party identifier pair.
guess and party identifier pair. For this reason it is RECOMMENDED
to use the optional inputs sid if available in an application
setting. For the same reason it is RECOMMENDED to integrate party
identity strings A,B into CI.

In this sense, using the wording suggested by Steve Thomas on the
CFRG mailing list, CPace is "quantum-annoying".
Expand Down Expand Up @@ -1346,7 +1356,7 @@ Table of Contents
<https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-
opaque-16>.

[REFIMP] "CPace reference implementation (sage)", n.d.,
[REFIMP] "CPace reference implementation (sage)", September 2024,
<https://github.com/cfrg/draft-irtf-cfrg-
cpace/tree/master/poc>.

Expand Down

0 comments on commit 35f4bf4

Please sign in to comment.