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

["Stanislav V. Smyshlyaev" <[e-mail]>]

Dear Julia,

Thank you so much for your reply and for your continuing efforts with this
document.

Best regards,
Stanislav (for chairs)

On Tue, Dec 16, 2025 at 10:00 AM Julia Hesse <[e-mail]> wrote:

> Dear Stanislav,
>
> we're still planning to make changes based on Feng's comments. We're
> discussing off list among the authors to reach a consensus before writing a
> summary to the list.
>
> Best,
> Julia
>
>
>
> Stanislav V. Smyshlyaev <[e-mail]> schrieb am Di., 16. Dez.
> 2025, 06:45:
>
>> Dear Bjoern, Julia and Feng,
>>
>> Thank you for the discussion and the changes made in the document in
>> version -16.
>>
>> Feng, do you have any remaining concerns or can we consider your issues
>>  resolved?
>>
>> Regards,
>> Stanislav (for chairs)
>>
>>
>>
>> On Fri, Dec 12, 2025 at 7:17 PM Björn Haase <Bjoern.M.Haase=
>> [e-mail]> wrote:
>>
>>> Dear Feng,
>>>
>>> I would be very unhappy if you leave this discussion in with bad
>>> feelings. This was not my intention. In case that you felt offended by me
>>> please accept my apologies. You have helped us.
>>>
>>> I think we have now come to the point.
>>>
>>> I now understand that we seem to have completely different
>>> understandings about what the concept of "identity" means and I now am
>>> convinced that we will find a solution where we can both agree on.
>>>
>>> In my understanding the term "identity" will be an information which is
>>> meaningfully characterizing a protocol partner and which also has some
>>> clearly defined and possibly crucially important semantic to the actual
>>> application using CPace outside of a concrete protocol run.
>>>
>>> I always understood that you would be aiming at ruling out application
>>> scenarios as unsuitable where party identifiers could not be meaningfully
>>> defined in a way that is guaranteed to be unique and that you were
>>> mandating to always publish them in clear-text.
>>>
>>> Also for identity information which is semantically meaningful for an
>>> application that needs to be checked my aim was always to advocate for
>>> integrating it in the generator (respectively CI) whenever possible as then
>>> there is no risk for screwing up the possibly crucial verification ("Am I
>>> really talking to the person I am expecting to talk with?") in the
>>> application code any more.
>>>
>>> What you are describing as a requirement "each device just needs to
>>> check that the two identifiers are different, so the two devices are
>>> distinguished during the key exchange session." seems to be a concept which
>>> takes over more or less the role of the sid field. I fully agree with you
>>> here. We don't need identities but we need uniqueness for protecting the
>>> symmetric CPace for against what you call "impersonation attack" and we
>>> would have missed this without your help.
>>>
>>> Julia, Michel and me will be discussing the topic next week and I
>>> believe that mandating randomness for symmetric CPace – if meaningful
>>> identities are to be kept confidential or if not available or not reliably
>>> unique– is an excellent suggestion and I was about to suggest exactly that
>>> to Julia (when hearing that this was also what was in her mind) and Michel.
>>>
>>> I whish you a nice weekend.
>>>
>>> Yours,
>>>
>>> Björn
>>> *Gesendet: *Freitag, 12. Dezember 2025 um 13:28
>>> *Von: *"Hao, Feng" <Feng.Hao=[e-mail]>
>>> *An: *"Björn Haase" <Bjoern.M.Haase=[e-mail]>, "
>>> [e-mail]" <[e-mail]>, "[e-mail]" <
>>> [e-mail]>
>>> *Betreff: *[CFRG] Re: RGLC on draft-irtf-cfrg-cpace-15
>>> Dear Bjorn,
>>>
>>> I notice that the protocol spec in 6.1 remains unchanged. Also, you
>>> don't seem to define exactly how the user identities and the transcript are
>>> included in the key derivation function. This should be part of the
>>> protocol spec.
>>>
>>>
>>>    - I assume that such application scenarios are out of the scope that
>>>    you typically are considering.
>>>
>>>
>>> In a client-server mode where the client initiates the connection and
>>> the client and the server share exactly one password, generic identities
>>> such as "client" and "server" would suffice. In the peer-to-peer mode where
>>> both devices can initiate the connection at the same time, even a random
>>> identifier for each device would work;  each device just needs to check
>>> that the two identifiers are different, so the two devices are
>>> distinguished during the key exchange session. All these are
>>> straightforward implementation details. Of course, in the most common
>>> cases, an entity needs to inform the other entity the identity so they know
>>> which shared password to use. All these can be captured by one unified
>>> spec, which involves the user identities in the key exchange flows and
>>> clear specification on how these identities are (or not) included in the
>>> key derivation function.
>>>
>>> I feel what I raised was a simple, clear and easily addressable issue.
>>> But the discussions have turned out to be long and difficult. I think I
>>> should leave it here. Ultimately, it's the responsibility of the RFC
>>> authors to make sure the protocol spec is unambiguously clear and is
>>> complete.
>>>
>>> Regards,
>>> Feng
>>>
>>> ------------------------------
>>> *From:* Björn Haase <Bjoern.M.Haase=[e-mail]>
>>> *Sent:* Friday, December 12, 2025 08:30
>>> *To:* Hao, Feng <[e-mail]>; [e-mail] <
>>> [e-mail]>; [e-mail] <[e-mail]>
>>> *Subject:* Aw: [CFRG] Re: RGLC on draft-irtf-cfrg-cpace-15
>>>
>>> Dear Feng,
>>>
>>> thank you for the private mail discussion yesterday where I think that
>>> we established a common view. Also Michel and me had a discussion
>>> yesterday. I have just uploaded a new revision 16 and I think that the
>>> newly uploaded revision addresses your major concerns.
>>>
>>> We are now giving much more detailed guidance on use of "user"
>>> identities and mandate inclusion of user identities if an application
>>> relies on guarantees from CPace.
>>>
>>> We also have added the reference to your ISO-SPEKE paper and also added
>>> a statement that draws the attention to the reader that what is actually
>>> needed as "identity" may vary from what is intuitively expected.
>>>
>>> We still may have different views specifically regarding authentication
>>> of identity identifiers that are to be held confidential and may be
>>> available upon protocol start. Such settings may show up
>>> specifically in use-cases where out-of-band-channels exist such as in
>>> the password use case for PACE or when for instance identity information is
>>> available by scanning QR codes provided for
>>> secure IoT onboarding on stickers of industrial devices. I assume that
>>> such application scenarios are out of the scope that you typically are
>>> considering.
>>>
>>> IMHO we need offer applications that need confidentially for identities
>>> on how to best use CPace in their setting.
>>>
>>> Also IMHO we shall allow and give best possible guidance to users for
>>> applications where identity strings are just not available or where
>>> identity checks can apply only in an unidirectional way, where in an
>>> applicatio a client may need to authenticate the server ID but the server
>>> shall be accepting any client knowing the password.
>>>
>>> I'd appreciate your feedback on the new revision 16.
>>>
>>> Yours,
>>>
>>> Björn
>>>
>>> *Gesendet: *Donnerstag, 11. Dezember 2025 um 17:43
>>> *Von: *"Hao, Feng" <Feng.Hao=[e-mail]>
>>> *An: *"Julia Hesse" <[e-mail]>, "[e-mail]" <
>>> [e-mail]>
>>> *Betreff: *[CFRG] Re: RGLC on draft-irtf-cfrg-cpace-15
>>>
>>> Dear Julia,
>>>
>>>
>>>    - Thanks for the pointer. Maybe we are using different terminology -
>>>    to me, user identities are unique to a user/client app, and can be reused
>>>    over several key exchanges. So they are not unique and they do not protect
>>>    against the unknown key share attack. Figure 4 in this reference also adds
>>>    the transcript to the key derivation, which is unique as long as one party
>>>    is honest. So maybe the situation can be summarized like this?
>>>
>>>
>>> You're correct that the user identities are unique to a user/client.
>>> However, when a user is engaged in parallel sessions, we need an extension
>>> of the identity to distinguish copies of self in multiple sessions. The
>>> solution we initially proposed in the 2014 paper uses the extended
>>> identities such as Alice, Alice-2 and so on if Alice is engaged in more
>>> than one key exchange session at the same time. That however requires Alice
>>> to keep states of the concurrent sessions. Hashing the user identity
>>> ("Alice") with the key exchange transcript is another way to distinguish
>>> the parallel sessions and is easier to implement. So we settled on that for
>>> the revision of SPEKE in ISO/IEC 11770-4. Your summary of the situation is
>>> correct.
>>>
>>>
>>>    - Interestingly, we analyzed this here:
>>>    https://eprint.iacr.org/2024/234. That paper models UC PAKE without
>>>    session identifiers, so really password-only PAKE. In UC, both relay
>>>    attacks and unknown key share attacks are ruled out by the security notion,
>>>    and we can show CPace to achieve that. We put both party identifiers and
>>>    transcript in the key derivation hash.
>>>
>>>
>>> Putting both parties' identities and transcript in the key derivation
>>> function is essentially what I proposed in my first email in this thread.
>>> This is how it was done in ISO/IEC 11770-4. As I tried to explain, the user
>>> identity is a critical parameter which needs to be explicitly defined in
>>> the spec. The revision of SPEKE in ISO/IEC 11770-4:2017 had an additional
>>> consideration of maintaining the symmetry and the 1-round property as the
>>> original SPEKE.
>>>
>>> Cheers,
>>> Feng
>>>
>>>
>>> ------------------------------
>>> *From:* Julia Hesse <[e-mail]> <[e-mail]>
>>> *Sent:* Wednesday, December 10, 2025 21:54
>>> *To:* [e-mail] <[e-mail]> <[e-mail]>
>>> *Subject:* [CFRG] Re: RGLC on draft-irtf-cfrg-cpace-15
>>>
>>> Dear Feng,
>>>
>>> thank you for looking into this and helping us improve the draft!
>>>
>>> I followed your pointer and read about the unknown key share attack in
>>> your '14 paper. This is quite interesting and I was not aware of it. Let me
>>> summarize the attack, to see whether I understand correctly.
>>>
>>> - Alice wants to exchange a key with Bob, and she is using f(pw)^x
>>> - Mallory grabs her message and starts *another* exchange with Alice
>>> concurrently, where she produces f(pw)^y
>>> - Mallory crafts the response messages to Alice such that the resulting
>>> DH key will be f(pw)^xyz in *both* exchanges
>>> - Mallory can relay key confirmation messages between protocols such
>>> that Alice accepts both sessions, having computed the same key
>>>
>>> Mallory achieved all this without knowing Alice's password.
>>>
>>> At first sight, this attack seems to void two important PAKE security
>>> properties:
>>> - Whenever Alice starts a key exchange with another party who does not
>>> share her password, she should output a fresh random key
>>> - If key confirmation succeeds, Alice can be sure to share a password
>>> (and also a key) with the party she talked to
>>>
>>> It seems this attack is protected against in the UC version of CPace by
>>> the uniqueness of session identifiers - Alice would assign different
>>> session identifiers to both exchanges, and hence would not compute the same
>>> key and the confirmation step fails.
>>>
>>> There is two things that puzzle me, and I'd appreciate your thoughts.
>>> 1) How does the inclusion of party identifiers help in fending off the
>>> attack? In the above description, Mallory can just contact Alice "in the
>>> name" of Bob, i.e., appending "Bob" to all his messages to Alice. So party
>>> identifiers who are reused across key exchanges do not seem to help here,
>>> neither in the final hash nor in the computation of the generator.
>>> 2) Why does the attack not show in the BPR security analysis in our
>>> CPace paper? Two options: either the model does not capture them, or the
>>> proof is incorrect.
>>>
>>> I would like to understand this better before issuing any opinion on
>>> what to do in the draft.
>>>
>>> Best,
>>> Julia
>>>
>>> Am 10.12.2025 um 11:43 schrieb Hao, Feng:
>>>
>>> Hi Bjorn,
>>>
>>> I suggest you read the paper by Burton Kaliski on "An unknown key-share
>>> attack on the MQV key agreement protocol" (ACM TISS, 2001):
>>> https://dl.acm.org/doi/abs/10.1145/501978.501981
>>>
>>> This attack on MQV was well known and understood by the community. It
>>> works because the MQV spec as defined in the then standards does not
>>> explicitly include user identities in the key exchange process. The user
>>> identities are only included in the explicit key confirmation process, but
>>> explicit key confirmation is optional.
>>>
>>> Menezes (co-author of MQV) later proposed to address this attack by
>>> explicitly include user identities in the key exchange and the key
>>> derivation function. See Section 2.2 of the paper "On the Importance of
>>> Public-Key Validation in the MQV and HMQV Key Agreement Protocols"
>>> (Menezes, Ustaoglu, 2006):
>>> https://link.springer.com/chapter/10.1007/11941378_11.
>>>
>>> The above is in the context of a public-key authenticated key exchange
>>> scheme, but the same problem and lesson apply to password-authenticated key
>>> exchange.
>>>
>>> As pointed out earlier, the CPace spec in draft-15 reverts to SPEKE in
>>> 1996 (standardized in IEEE 1363.2, and then followed by ISO/IEC 11770-4),
>>> which is ambiguous in the definition of user identity and is known to
>>> suffer from the same kind of unknown key-share attack. This has already
>>> been acknowledged and fixed in ISO/IEC 11770-4 since 2017. You really need
>>> to have a closer look at how this is fixed there.
>>>
>>> Cheers,
>>> Feng
>>>
>>> ------------------------------
>>> *From:* Björn Haase <[e-mail]> <[e-mail]>
>>> *Sent:* Monday, December 08, 2025 17:26
>>> *To:* Hao, Feng <[e-mail]> <[e-mail]>;
>>> bjoern.haase=[e-mail]
>>> <bjoern.haase=[e-mail]>
>>> <bjoern.haase=[e-mail]>; [e-mail]
>>> <[e-mail]> <[e-mail]>; [e-mail]
>>> <[e-mail]> <[e-mail]>
>>> *Subject:* Aw: RE: [CFRG] Re: RGLC on draft-irtf-cfrg-cpace-15
>>>
>>> Hello Feng,
>>>
>>> what we tell the end user regarding the security guarantees  in sectin 3
>>> is :
>>> "A and B will produce the same ISK value if and only if both sides did
>>> initiate the   protocol using the same protocol inputs, specifically the
>>> same PRS   and the same value for the optional input parameters CI, ADa,
>>> ADb and   sid that will be specified in section Section 3.1."
>>> With respect to this security guarantee there is nothing to fix.
>>>
>>> This clearly says: "if you are only using PRS and nothing else, the only
>>> thing that you can rely on is that the remote side also knows the same PRS."
>>>
>>> We moreover explicitly draw the attention of the reader to the
>>> consequences if no identity strings are added. So any reader of the
>>> specification is be well-informed.
>>>
>>> What we should not be doing is *patronizing* the end user.
>>>
>>> The adequate approach here is -- in my humble opinion -- to treat the
>>> reader of the specification not as an infant but as a responsible adult. An
>>> adult who should be given a component at hand being fit for the for the
>>> purpose and who should be empowered to make educated use of it.
>>>
>>> BTW this approach is nothing uncommon for standard documents. It's quite
>>> common for standards to allow for options. E.g. IEC 61000-4-5 for
>>> industrial measurement appliances does not mandate integration of surge
>>> protection arrestors on all cable interfaces. But IEC61000 mandates to give
>>> clear guidance for empowering the adult end user in the manual for secure
>>> use ("Avoid cables longer than 10m and don't use the unit in fixed outdoor
>>> installation if you purchase the more accurate variant without surge
>>> protection at the input cables.")
>>>
>>> Yours,
>>>
>>> Björn.
>>>
>>>
>>>
>>> *Gesendet: *Montag, 8. Dezember 2025 um 16:49
>>> *Von: *"Hao, Feng" <[e-mail]> <[e-mail]>
>>> *An: *"Björn Haase" <bjoern.haase=[e-mail]>
>>> <bjoern.haase=[e-mail]>, "Björn Haase"
>>> <[e-mail]> <[e-mail]>, "[e-mail]"
>>> <[e-mail]> <[e-mail]> <[e-mail]>
>>> *Betreff: *RE: [CFRG] Re: RGLC on draft-irtf-cfrg-cpace-15
>>>
>>> Hi,
>>>
>>>
>>>
>>> Ø  thank you for your feedback. So I’d like to summarize that the
>>> remaining aspect in our discussion is not a different view on the attacks
>>> or possible vulnerabilities.
>>> The key point in our discussion seems to be a different point of  view
>>> regarding which extend remaining freedom is left to application designers
>>> and integrators.
>>>
>>> When the protocol spec says the user identity is optional, it implies
>>> that the protocol is secure without it. But that’s not the case, as shown
>>> by the impersonation attack. I think you should consider updating the
>>> protocol spec in Section 6.1.
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________ CFRG mailing list --
>>> [e-mail] To unsubscribe send an email to [e-mail]
>>>
>>>
>>>
>>>
>>> _______________________________________________ CFRG mailing list --
>>> [e-mail] To unsubscribe send an email to [e-mail]
>>> _______________________________________________ CFRG mailing list --
>>> [e-mail] To unsubscribe send an email to [e-mail]
>>> _______________________________________________
>>> CFRG mailing list -- [e-mail]
>>> To unsubscribe send an email to [e-mail]
>>>
>>