[CFRG] Re: RGLC on draft-irtf-cfrg-cpace-15

["Hao, Feng" <[e-mail]>]

Hi Bjorn,

I am not sure if your change in the wording makes any difference. For security critical details, you need to define them unambiguously in a complete spec. The word “should” doesn’t help here.

As an example, see how the revised SPEKE was specified in ISO/IEC 11770-4 (Figure 4, p. 7,  https://arxiv.org/pdf/1802.04900) Besides the finite field, ISO/IEC 11770-4 also includes an elliptic curve version of the SPEKE.

A known problem with the finite field implementation is that the hash-to-group function uses safe primes as the modulus and hence the long exponents. The cost of exponentiation with a long exponent is very high (many times than the exponentiation with short exponents). Your spec completely avoids the finite field, and only focuses on EC. That’s OK. But you may want to make this clear.

For the elliptic curve version of SPEKE, a hash-to-curve function is required. The hash-to-curve function in ISO/IEC 11770-4 (following from IEEE P1363.2) works with any curve suitable for cryptography, but it’s not constant time. In your spec, you use different hash-to-curve functions that are custom-built for only selected curves.

When you say “All state-of-the art methods for realizing constant-time execution SHOULD be used”, this is ambiguous. If constant-time is regarded a security-critical feature, you may want to explicitly state that only constant-time H2C algorithms “shall” be used. Otherwise, there is no difference to the SPEKE spec in ISO/IEC 11770-4.

Cheers,
Feng

From: Björn Haase <bjoern.m.haase=[e-mail]>
Date: Friday, 5 December 2025 at 18:49
To: [e-mail] <[e-mail]>
Subject: [CFRG] Re: RGLC on draft-irtf-cfrg-cpace-15

You don't often get email from bjoern.m.haase=[e-mail]. Learn why this is important<https://aka.ms/LearnAboutSenderIdentification>

Dear Feng,

thank you for the constructive feedback. I agree with you in that we should probably use a more explicit phrasing regarding the recommendation of using
party identifiers. Please have a look at the following change suggestion.

https://author-tools.ietf.org/api/iddiff?doc_1=draft-irtf-cfrg-cpace&url_2=https://cfrg.github.io/draft-irtf-cfrg-cpace/draft-irtf-cfrg-cpace.txt

I have also added a sentence referring to the "loopback" version of the relay attack variant that you mentioned where messages from A are relayed back to A.

Yours,



Am 05.12.2025 um 16:32 schrieb Hao, Feng:
Hi,

I was only trying to raise the point that the user identity is one of the critical parameters in PAKE (and any authenticated key exchanges in general), and it needs to be defined explicitly.

When the user identity is optional, we may have the following attack scenario, where Alice and Bob share a password, but an attacker (who doesn’t know the password) can impersonate Bob to Alice and successfully pass the password authentication. See Figure 1 (https://eprint.iacr.org/2014/585.pdf) for the illustration of this attack. The original SPEKE spec in ISO/IEC 11770-4 has been revised to prevent this attack.

This impersonation attack exploits the confusion of the identity, and therefore is a form of the “unknown key share” attack. The “unknown key share” attack is an established, generic term, and there are many forms of it.

This attack is different from the “relay attack” you described. In the setting of your relay attack, three parties, A, B, and C share the same password. That is a less common scenario. The impersonation attack described above is between a victim user and an active attacker; it’s more practical.

Cheers,
Feng

From: Björn Haase <bjoern.haase=[e-mail]><mailto:bjoern.haase=[e-mail]>
Sent: 05 December 2025 11:52
To: Hao, Feng <[e-mail]><mailto:[e-mail]>; Stanislav V. Smyshlyaev <[e-mail]><mailto:[e-mail]>; CFRG <[e-mail]><mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: AW: [CFRG] Re: RGLC on draft-irtf-cfrg-cpace-15

Dear Feng,

before responding in detail I am having the following processural topic before responding
to each individual point brought up in your post.

When discussing a mature draft revision on the list I'd like to suggest that we all stick
to the naming/nomenclature and definition as used in the respective draft.

IMO using consistent nomenclature when discussing mature drafts is very important.
Without knowledge on the different nomenclature in the scientific literature for the same
topic a non-expert reader of our posts on the list might be mislead.
Inconsistent nomenclature might even be misused for nudging a reader to fearing
that an attack was overlooked in a draft by the authors and reviewers, while the exact
topic was actually considered in depth under a different name and heading.

For the CPace draft this is relevant as the "unknown key share attack" from [1,2] that you
are referring to in your post is explicitly discussed in the draft under the name of
"relay attacks".

For comparison I'd like to cite the definitions of the respective attacks from the
different sources:

"unknown key share attack", citing from [2] Section 3:
"The second attack assumes that the user shares the same password with two servers, say S1
and S2. By relaying the messages between the client and S2, the attacker may trick the
client into believing that she shares a key with S1, but actually the key is shared
with S2. The authors [of [1], Tang and Mitchell] call this an “unknown key-share” attack.
They suggest to address this attack by including the server’s identifier into the
computation of g."

"relay attack", citing from draft-irtf-cfrg-cpace-15 Section 9.1:
"Incorporating party identifier strings is important for fending off relay attacks. Such
attacks become relevant in a setting where several parties, say, A, B and C, share the same
password PRS. An adversary might relay messages from an honest user A, who aims at
interacting with user B, to a party C instead. If no party identifier strings are
used and B and C share the same PRS value then A might be using CPace for establishing a
common ISK key with C while assuming to interact with party B."


Now regarding your comment and your "technical concerns" I have the following feedback:

>CPace (as defined in the original 2019 paper) differs from the original SPEKE
>protocol (proposed by Jablon in 1996) in that it adds session IDs to the key
>exchange process. As a result of this change, completing the 2019 CPace
>protocol in 1 round or two passes is impossible. By now, this should be
>clear to everyone.
>
>The CPace protocol in draft-15 has removed the session IDs as mandatory data.
>
>CPace in draft-15 has also removed the party identity as mandatory data. From
>Section 3.1, the party identity is optional; it “MAY also be the empty string”.
>
>These changes essentially revert CPace to SPEKE in 1996 . However, the 1996 SPEKE
>is known to suffer from an unknown key-share attack due to the missing user
>identities. With the explicit specification of the user identity as OPTIONAL
>in draft-15, it seems that CPace would suffer from the same attack.
>See [1] for more details.

Your wording seems to suggest, that you believe that the CFRG community might have overlooked
a known "unknown key share" attack from the literature when writing the draft.
In fact the respective aspect is discussed in depth in the draft in section 9.1.
"Party identifiers and relay attacks". Because of the relevance the reader's attention in section
3.1. is explicitly drawn to the details discussed in section 9.1.

You moreover seem to claim that the one and only way to address the topic of relay attacks
is the method that you have been developping for SPEKE in the ISO/IEC process in [3]:
>Fixing this attack requires making party identities mandatory and including them in-flow
>during the key exchange.
>In order to maintain one-round efficiency, the only solution is to include the party
>identities in the key derivation function in a clearly defined lexicographic order. This is
>exactly what has been done in ISO/IEC to fix this issue. See [2] for more details. The revised
> SPEKE protocol, based on [2], has been standardized in ISO/IEC 11770-4.

In fact at least two independent secure ways for authenticating party identifiers alongside
with the protocol are known from the literature for fending off the relay attack.
- Firstly there is the approach of [4] (proof for the UC model) (following the approach of [1]
  for SPEKE) of integrating the identities in the calculation of the generator.
- Secondly there is the method exposed in Section B.1 of [4] ("real or random" game-based
  proof) which corresponds to what you are suggesting in [3].

Both options are presented and discussed in section 9.1. of the draft together with the
respective advantages and drawbacks. We advise the application designer to give preference
to the first option with the respective reasons stated in section 9.1 and 9.11 and 3. and
alternatively recommend the second approach if the preferred first option could not be chosen
due to application constraints.

>I would recommend the CPace authors make the party identities mandatory, and explicitly
>include them in the key derivation function as done above.

I believe that our common objective at CFRG should be to fill the gap between theory and
application and give guidance on how to best integrate cryptographic protocols and primitives
in the respective application scenario. The CPace draft was requested to serve the application
scenarios that come up for the balanced PAKE use cases.

For the CPace draft this implies that CPace should not be considered to form a standalone
protocol but rather a building block which aims at being integrateable in different application
scenarios.

One objective of the CPace design was to allow for security analysis for such integration by
closely following the semantics used for proofs in the UC framework. This comes at the cost
of offering the option of hardening the protocol with the help of a unique session id.

Regarding application scenarios different settings were identified:
- For some application scenarios authenticating both party identities might be important. This
  seems to be the only viable "PAKE" application that you are having in mind.
- A second set of applications exist where it is only needed to make sure that both parties
  share the same PRS string. One of the example of this group is the use case discussed on
  this list for the "Magic Wormhole" application setting
  (see https://mailarchive.ietf.org/arch/msg/cfrg/BBQ2gwCECu5ouTJjE_CE6d9Rg-0/ ).
- In a third set of applications authentication of only one out of the server and client identity
  might be of relevance. One example might be a WIFI-Router login application where the client
  wants to authenticate the name of a WIFI hot-spot but the server might be willing to give
  access to any client in possesion of the password. This seems also be the application context
  considered in [1].
- Moreover for an application confidentiality of party identifiers might be important and sending
  party identities in clear-text alongside with the protocol messages might not be an option (e.g.
  as in the PAKE use-case targeted by PACE for identity cards).
- Some application's might want to facilitate UC security analysis by reducing the gap between
  the UC framework and the real-world protocol by explicitly deriving session ids. Some might
  not want to pay the additional price of a possibly required additional round.

Ultimately there are various decisions and requirements cannot be addressed on the CPace level but
as part of the assessment for the larger application setting.
The CPace draft does so by offering the application layer a small set of alternative approaches with
a clear guidance on how to best use this flexibility and which advantages and drawbacks come with
either option (Sections 3.1 to 3.3 and 9).

The alternative of doing so would have been to either leave people such as Brian Warner
(in https://mailarchive.ietf.org/arch/msg/cfrg/BBQ2gwCECu5ouTJjE_CE6d9Rg-0/) without any guidance
or to issuing one specific RFC for all distinct "symmetric" PAKE use-cases which would result
in *many* specification documents.

In this context it is also worth noting that I have had a discussion off-the-list with Steve Thomas
end of November regarding the CPace draft. Steve suggested to additionally impose the requirement
to the CPace protocol that the PRS input string should never be memorized in persistent storage and
shall be ephemeral and password stretching for deriving PRS should not be considered.
I responded that in the the specific application use-case that Steve had in mind this additional
constraint would be indeed a good idea, but that there were other application scenarios where
different choices might be appropriate.

IMO the challenge for the CFRG is to find a good compromise in between the options of ruling
out important application scenarios on the one extreme or for adding excessive complexity
that comes with security pitfalls. IMO there is just no right or wrong regarding this
topic.

I believe that the CPace draft as-is does implement an appropriate choice by leaving a small set of
options that come with clear guidance on how to best use them.
Specifically Brain Warner's use case has shown that there are valid applications where
identity-binding is a "non-issue" and I see our objective at CFRG to give guidance regarding PAKE
usage also for this set of application designers.

Actually IMO this aspect has been at the core of the feedback during the crypto review panel
reviews and considered during the process.

Yours,

Björn

[1] Q. Tang, C. Mitchell, “On the security of some password-based key agreement
schemes,” International conference on Computational Intelligence and Security
(CIS), LNCS Vol. 3802, pp. 149-154, 2005

[2] Feng Hao, Siamak F. Shahandashti, "The SPEKE Protocol Revisited"
https://eprint.iacr.org/2014/585.pdf

[3] Feng Hao, Roberto Metere, Siamak F. Shahandashti and Changyu Dong,
“Analysing and Patching SPEKE in ISO/IEC” https://arxiv.org/pdf/1802.04900

[4] Abdalla, M., Haase, B., and J. Hesse, "Security analysis of CPace",
n.d., https://eprint.iacr.org/2021/114.





Mit freundlichen Grüßen | Best Regards

Dr. Björn Haase

________________________________

Senior Expert Electronics | TGREH Electronics Hardware

Endress+Hauser Liquid Analysis

Endress+Hauser Conducta GmbH+Co. KG | Dieselstrasse 24 | 70839 Gerlingen | Germany
Phone: [phone]
[e-mail]<mailto:[e-mail]> | www.ehla.endress.com<http://www.ehla.endress.com/>

________________________________

Endress+Hauser Conducta GmbH+Co.KG
Amtsgericht Stuttgart HRA 201908
Sitz der Gesellschaft: Gerlingen
Persönlich haftende Gesellschafterin:
Endress+Hauser Conducta
Verwaltungsgesellschaft mbH
Sitz der Gesellschaft: Gerlingen
Amtsgericht Stuttgart HRA 201929
Geschäftsführer: Dr. Thomas Buer

________________________________

Gemäss Datenschutzgrundverordnung sind wir verpflichtet, Sie zu informieren, wenn wir personenbezogene Daten von Ihnen erheben.

Dieser Informationspflicht kommen wir mit folgendem Datenschutzhinweis<https://www.de.endress.com/de/cookies-endress+hauser-website> nach.

________________________________



Disclaimer:

The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged
material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities
other than the intended recipient is prohibited. If you receive this in error, please contact the sender and delete the material from any computer.
This e-mail does not constitute a contract offer, a contract amendment, or an acceptance of a contract offer unless explicitly and conspicuously designated or stated as such.


Von: Hao, Feng <Feng.Hao=[e-mail]<mailto:Feng.Hao=[e-mail]>>
Gesendet: Donnerstag, 4. Dezember 2025 22:37
An: Stanislav V. Smyshlyaev <[e-mail]<mailto:[e-mail]>>; CFRG <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Betreff: [CFRG] Re: RGLC on draft-irtf-cfrg-cpace-15

Hi,

I have a few comments and a technical concern about draft-15.

CPace (as defined in the original 2019 paper) differs from the original SPEKE protocol (proposed by Jablon in 1996) in that it adds session IDs to the key exchange process. As a result of this change, completing the 2019 CPace protocol in 1 round or two passes is impossible. By now, this should be clear to everyone.

The CPace protocol in draft-15 has removed the session IDs as mandatory data.

CPace in draft-15 has also removed the party identity as mandatory data. From Section 3.1, the party identity is optional; it “MAY also be the empty string”.

These changes essentially revert CPace to SPEKE in 1996 . However, the 1996 SPEKE is known to suffer from an unknown key-share attack due to the missing user identities. With the explicit specification of the user identity as OPTIONAL in draft-15, it seems that CPace would suffer from the same attack. See [1] for more details.

Fixing this attack requires making party identities mandatory and including them in-flow during the key exchange. In order to maintain one-round efficiency, the only solution is to include the party identities in the key derivation function in a clearly defined lexicographic order. This is exactly what has been done in ISO/IEC to fix this issue. See [2] for more details. The revised SPEKE protocol, based on [2], has been standardized in ISO/IEC 11770-4.

I would recommend the CPace authors make the party identities mandatory, and explicitly include them in the key derivation function as done above.

[1] “The SPEKE Protocol Revisited” https://eprint.iacr.org/2014/585
[2] “Analysing and Patching SPEKE in ISO/IEC” https://arxiv.org/pdf/1802.04900

Regards,
Feng

From: Stanislav V. Smyshlyaev <[e-mail]<mailto:[e-mail]>>
Sent: 01 December 2025 12:02
To: CFRG <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: [CFRG] Re: RGLC on draft-irtf-cfrg-cpace-15

Dear CFRG,

We have received only one response, so we've decided to extend the RGLC.
It will end on December 15th 2025.

If you've read the document and think that it is ready (or not ready) for publication as an RFC, please send a message in reply to this email.

Regards,
Stanislav, Nick, Alexey (CFRG chairs)


On Mon, Nov 10, 2025 at 8:57 AM Stanislav V. Smyshlyaev <[e-mail]<mailto:[e-mail]>> wrote:
Dear CFRG participants,

This message is starting a 3-week RGLC on draft-irtf-cfrg-cpace-15 ("CPace, a balanced composable PAKE"), https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-cpace, that will end on December 1st 2025. If you've read the document and think that it is ready (or not ready) for publication as an RFC, please send a message in reply to this email or directly to CFRG chairs ([e-mail]<mailto:[e-mail]>). If you have detailed comments, these would also be very helpful at this point.

The CPace protocol was selected as a result of the PAKE selection process in CFRG in 2019; there were a lot of reviews of the protocol and the early versions of the draft, see https://github.com/cfrg/pake-selection

We've also got a review for a recent version of the draft from Karthikeyan Bhargavan on behalf of the Crypto Review Panel:
https://mailarchive.ietf.org/arch/msg/crypto-panel/995IVSGk1jSRKvKS4gH2iu66eUc/
The authors were later addressing the concerns in the further versions of the draft.

Thank you,
Stanislav, for CFRG chairs


_______________________________________________
CFRG mailing list -- [e-mail]<mailto:[e-mail]>
To unsubscribe send an email to [e-mail]<mailto:[e-mail]>


[https://s-install.avcdn.net/ipm/preview/icons/icon-envelope-tick-green-avg-v1.png]<http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient>
Virenfrei.www.avg.com<http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient>