Return-Path: X-Original-To: cfrg@mail2.ietf.org Delivered-To: cfrg@mail2.ietf.org Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id 6273F9B21CA6 for ; Mon, 15 Dec 2025 23:08:00 -0800 (PST) X-Virus-Scanned: amavisd-new at ietf.org X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5nYnjsxDZOz1 for ; Mon, 15 Dec 2025 23:07:58 -0800 (PST) Received: from mail-yx1-xb12f.google.com (mail-yx1-xb12f.google.com [IPv6:2607:f8b0:4864:20::b12f]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id 5160B9B21C8F for ; Mon, 15 Dec 2025 23:07:58 -0800 (PST) Received: by mail-yx1-xb12f.google.com with SMTP id 956f58d0204a3-644798bb299so3366375d50.3 for ; Mon, 15 Dec 2025 23:07:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1765868878; x=1766473678; darn=irtf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=mApC4lzlcZQ5RJO0N68A28pBQQt1IddPa7mJH81QuAs=; b=CsNQHiQB5e20Kn38qoJwN/Os5YmaWhTvVaOxBrAX8bWstxZw3AE7M0wCaghwdzH0jX binTUWtOiC1sJlVlmnEEdftan41BLIA+LpCOfinZe3ITaveK5aXOd3B9qjXJXCS1Bih1 E5xyIquX9GhD/oqdFmdj3BgvQ07tinZTxJ2w1+yILhRZm1FhP+bO0VJhSTYZwVFJVeY/ vl+qk01UiedMRMSHMDXbuZylL5yR2+AFZC4qgBevx8/iGV2OOyEl4KdLUgMA5+c3T+p9 FbD+YEXwPpyuXDBIF9x2leZGVNLiWB/JuNTVYyHdlR5kvxWVrrl6htdmyuNChhAGuxJb vr6g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1765868878; x=1766473678; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=mApC4lzlcZQ5RJO0N68A28pBQQt1IddPa7mJH81QuAs=; b=h8yeLWCavDWM9DIa9hf6w4JHArVzsSL4uBDiYyOWfZ0pSOVttrpOfXfAMNMyIwXJkJ 7CQvsEWnDHDNKUgC/CsfsxKP8UdBeNmD+nQ9maVz4lk8nEu8/1Wucj91yctN5xFtDw4F jxz0x4exgau45gcmqpMgEsmAGkt20+lnZCkQ6x0VTQ6VIu35Zbd1aMp2jyvguWvEgHTY Gx5kzp2/ciJG2IJfDlKvRgGayAK0zxoVk2wFqOCUcg0/lVni4aScPGRd5pZocSvvLCj9 8bNhmFdEfg9EWZQw3kp72Js/WKZ9KNuoZvP4cFfwX7d8T0mgyzOXLeYLZeoSOvmWChSs +5UA== X-Forwarded-Encrypted: i=1; AJvYcCWs++GJ5LJoJ/hmoEpy/kuxX7+vkC+aDEMuqlAfYx62VvPtA9uB1JoS25FxK+Fofa3WYIJS@irtf.org X-Gm-Message-State: AOJu0Yztv/PhcDAxh0ZXGBPvl7H4CPiFimmW9milB6/HSMdjZzftlgPK WNVYDUxJLaq+yBsPnChMzvzyiBgG94Ow4PeOIALKzteOIDzJhoYMXlLcHDF/0+tY835qrPrQFgZ EFSWVUTaFA3+OEjfgybwDK22GHVMyX9k= X-Gm-Gg: AY/fxX7aGxjBuzNy5JG+x7UkXne/p+EfUxb4v0uyKfK8pFkljGGJmwScrX7MQ4lSn89 9/6+a0VUBU223xO+urhaYCFmTV7ROVCOJMz1ocgcHI3HrOB4MRjcHqCq8PaC3t1mXaXQQ+NZB4r Q/+hVmszdaPdJHhSxUCgXoDfvdmkvLYxVHAzVsjUzK+P6HR/IQPYU7tzfnrdaYdIazb6lT6wwTO uxlR6bMkTStGREpxTHh59ywknZ2Dfw+jPYwO82k4d5YwKu9OoD3gYegsu+rAxOHYII8TgPU0mhc ACqb X-Google-Smtp-Source: AGHT+IHoWocT8N5zNuXV16bT9W1FkkNs8fb+U8Af9LWmCOlY3k5aq6NSuHJJrtHP3StHmVhuQvccKAzR4qrJd3Q/QXw= X-Received: by 2002:a05:690e:1345:b0:644:75d7:5f48 with SMTP id 956f58d0204a3-645555cddddmr10001921d50.12.1765868877648; Mon, 15 Dec 2025 23:07:57 -0800 (PST) MIME-Version: 1.0 References: <1e939670-7fe7-46db-b610-3e45a34f965f@web.de> <157382db-35bc-41c0-86ac-2da708f88c11@gmail.com> In-Reply-To: From: "Stanislav V. Smyshlyaev" Date: Tue, 16 Dec 2025 10:07:46 +0300 X-Gm-Features: AQt7F2pizQ-hdmzqeQmOTR0Nr1Nsoewjou13OsSUnjMjTnhT7qaWy_dlN047LlU Message-ID: To: Julia Hesse Content-Type: multipart/alternative; boundary="0000000000002c16f006460c63ba" Message-ID-Hash: AOJQRCRTGRS5YISGUGCOMDA7EIHMTUJU X-Message-ID-Hash: AOJQRCRTGRS5YISGUGCOMDA7EIHMTUJU X-MailFrom: smyshsv@gmail.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-cfrg.irtf.org-0; header-match-cfrg.irtf.org-1; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: =?UTF-8?B?QmrDtnJuIEhhYXNl?= , feng.hao=40warwick.ac.uk@dmarc.ietf.org, CFRG X-Mailman-Version: 3.3.9rc6 Precedence: list Subject: =?utf-8?q?=5BCFRG=5D_Re=3A_RGLC_on_draft-irtf-cfrg-cpace-15?= List-Id: Crypto Forum Research Group Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --0000000000002c16f006460c63ba Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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=E2=80=AFAM Julia Hesse 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 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=E2=80=AFPM Bj=C3=B6rn Haase > 40web.de@dmarc.ietf.org> 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 meaningful= ly >>> 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 w= hich >>> takes over more or less the role of the sid field. I fully agree with y= ou >>> here. We don't need identities but we need uniqueness for protecting th= e >>> 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 =E2=80=93 if mean= ingful >>> identities are to be kept confidential or if not available or not relia= bly >>> unique=E2=80=93 is an excellent suggestion and I was about to suggest e= xactly that >>> to Julia (when hearing that this was also what was in her mind) and Mic= hel. >>> >>> I whish you a nice weekend. >>> >>> Yours, >>> >>> Bj=C3=B6rn >>> *Gesendet: *Freitag, 12. Dezember 2025 um 13:28 >>> *Von: *"Hao, Feng" >>> *An: *"Bj=C3=B6rn Haase" , " >>> juliahesse2@gmail.com" , "cfrg@irtf.org" < >>> cfrg@irtf.org> >>> *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 identitie= s >>> such as "client" and "server" would suffice. In the peer-to-peer mode w= here >>> both devices can initiate the connection at the same time, even a rando= m >>> 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 th= e >>> 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=C3=B6rn Haase >>> *Sent:* Friday, December 12, 2025 08:30 >>> *To:* Hao, Feng ; juliahesse2@gmail.com < >>> juliahesse2@gmail.com>; cfrg@irtf.org >>> *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 actuall= y >>> 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 informatio= n 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 serv= er >>> shall be accepting any client knowing the password. >>> >>> I'd appreciate your feedback on the new revision 16. >>> >>> Yours, >>> >>> Bj=C3=B6rn >>> >>> *Gesendet: *Donnerstag, 11. Dezember 2025 um 17:43 >>> *Von: *"Hao, Feng" >>> *An: *"Julia Hesse" , "cfrg@irtf.org" < >>> cfrg@irtf.org> >>> *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 r= eused >>> over several key exchanges. So they are not unique and they do not p= rotect >>> against the unknown key share attack. Figure 4 in this reference als= o 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 extens= ion >>> 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 A= lice >>> to keep states of the concurrent sessions. Hashing the user identity >>> ("Alice") with the key exchange transcript is another way to distinguis= h >>> 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 threa= d. >>> 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 i= n >>> the spec. The revision of SPEKE in ISO/IEC 11770-4:2017 had an addition= al >>> consideration of maintaining the symmetry and the 1-round property as t= he >>> original SPEKE. >>> >>> Cheers, >>> Feng >>> >>> >>> ------------------------------ >>> *From:* Julia Hesse >>> *Sent:* Wednesday, December 10, 2025 21:54 >>> *To:* cfrg@irtf.org >>> *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. Le= t 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 th= e >>> name" of Bob, i.e., appending "Bob" to all his messages to Alice. So pa= rty >>> identifiers who are reused across key exchanges do not seem to help her= e, >>> 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 th= e >>> 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 use= r >>> 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 n= eed >>> to have a closer look at how this is fixed there. >>> >>> Cheers, >>> Feng >>> >>> ------------------------------ >>> *From:* Bj=C3=B6rn Haase >>> *Sent:* Monday, December 08, 2025 17:26 >>> *To:* Hao, Feng ; >>> bjoern.haase=3D40endress.com@dmarc.ietf.org >>> >>> ; bjoern.m.haase@web.de >>> ; cfrg@irtf.org >>> >>> *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 th= e >>> 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 onl= y >>> 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 quit= e >>> 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 secu= re >>> use ("Avoid cables longer than 10m and don't use the unit in fixed outd= oor >>> installation if you purchase the more accurate variant without surge >>> protection at the input cables.") >>> >>> Yours, >>> >>> Bj=C3=B6rn. >>> >>> >>> >>> *Gesendet: *Montag, 8. Dezember 2025 um 16:49 >>> *Von: *"Hao, Feng" >>> *An: *"Bj=C3=B6rn Haase" >>> , "Bj=C3=B6rn Haase" >>> , "cfrg@irtf.org" >>> >>> *Betreff: *RE: [CFRG] Re: RGLC on draft-irtf-cfrg-cpace-15 >>> >>> Hi, >>> >>> >>> >>> =C3=98 thank you for your feedback. So I=E2=80=99d like to summarize t= hat the >>> remaining aspect in our discussion is not a different view on the attac= ks >>> 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 designe= rs >>> and integrators. >>> >>> When the protocol spec says the user identity is optional, it implies >>> that the protocol is secure without it. But that=E2=80=99s 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 -- >>> cfrg@irtf.org To unsubscribe send an email to cfrg-leave@irtf.org >>> >>> >>> >>> >>> _______________________________________________ CFRG mailing list -- >>> cfrg@irtf.org To unsubscribe send an email to cfrg-leave@irtf.org >>> _______________________________________________ CFRG mailing list -- >>> cfrg@irtf.org To unsubscribe send an email to cfrg-leave@irtf.org >>> _______________________________________________ >>> CFRG mailing list -- cfrg@irtf.org >>> To unsubscribe send an email to cfrg-leave@irtf.org >>> >> --0000000000002c16f006460c63ba Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear Julia,

Thank you so much for your = reply and for your continuing=C2=A0efforts with this document.=C2=A0
<= div>
Best regards,
Stanislav (for chairs)

On Tue, Dec 16, 2025 at 10:00=E2=80=AFAM Julia Hesse <= juliahesse2@gmail.com> wrot= e:
Dear Stanislav,

we're= still planning to make changes based on Feng's comments. We're dis= cussing off list among the authors to reach a consensus before writing a su= mmary to the list.

Best,=
Julia=C2=A0



Stanislav V. Smyshlyaev <smyshsv@gmail.com> schrieb am Di.,= 16. Dez. 2025, 06:45:
Dear Bjoern, Julia and Feng,

Tha= nk you for the discussion and the changes made in the document in version -= 16.

Feng, do you have any remaining=C2=A0concerns=C2=A0or can we consider your=C2=A0iss= ues=C2=A0resolved?

Regards,
Stanislav (for chairs)



<= div class=3D"gmail_quote">
On Fri, Dec= 12, 2025 at 7:17=E2=80=AFPM Bj=C3=B6rn Haase <Bjoern.M.Haase=3D40= web.de@dmarc.ietf.org> wrote:
Dear Feng,

I would be= very unhappy if you leave this discussion in with bad feelings. This was n= ot my intention. In case that you felt offended by me please accept my apol= ogies. You have helped us.

I think we have now come to the po= int.

I now understand that we seem to have completely different unde= rstandings about what the concept of "identity" means and I now a= m convinced that we will find a solution where we can both agree on.
In my understanding the term "identity" will be an information w= hich is meaningfully characterizing a protocol partner and which also has s= ome clearly defined and possibly crucially important semantic to the actual= application using CPace outside of a concrete protocol run.

I alway= s understood that you would be aiming at ruling out application scenarios a= s 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 s= emantically meaningful for an application that needs to be checked my aim w= as always to advocate for integrating it in the generator (respectively CI)= whenever possible as then there is no risk for screwing up the possibly cr= ucial 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 CPac= e for against what you call "impersonation attack" and we would h= ave missed this without your help.

Julia, Michel and me will be disc= ussing the topic next week and I believe that mandating randomness for symm= etric CPace =E2=80=93 if meaningful identities are to be kept confidential = or if not available or not reliably unique=E2=80=93 is an excellent suggest= ion and I was about to suggest exactly that to Julia (when hearing that thi= s was also what was in her mind) and Michel.

I whish you a nice week= end.

Yours,

Bj=C3=B6rn

Gesendet: Freitag, 12. Dezember 2025 um 13:28
Von: "Hao, Feng" <Feng.Hao=3D40warwick.ac.uk@dmarc.ietf.org>
An: "Bj=C3=B6rn Haase" <Bjoern.M.Haase= =3D40web.de@dmarc.ietf.org>, "juliahesse2@gmail.com= " <juliahesse2@gmail.com>, "cfrg@irtf.org" <<= a href=3D"mailto:cfrg@irtf.org" rel=3D"noreferrer" target=3D"_blank">cfrg@i= rtf.org>
Betreff: [CFRG] Re: RGLC on draft-irtf-cfrg-cpace-15<= /div>
Dear Bjorn,
=C2=A0
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.
=C2=A0
  • I assume that such applic= ation scenarios are out of the scope that you typically are considering.
=C2=A0
In a client-serve= r mode where the client initiates the connection and the client and the ser= ver share exactly one password, generic identities such as "client&quo= t; and "server" would suffice. In the peer-to-peer mode where bot= h devices can initiate the connection at the same time, even a random ident= ifier for each device would work;=C2=A0 each device just needs to check tha= t the two identifiers are different, so the two devices are distinguished d= uring the key exchange session. All these are straightforward implementatio= n details. Of course, in the most common cases, an entity needs to inform t= he 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 identit= ies in the key exchange flows and clear specification on how these identiti= es are (or not) included in the key derivation function.
=C2=A0
I feel what I rai= sed was a simple, clear and easily addressable issue. But the discussions h= ave turned out to be long and difficult. I think I should leave it here. Ul= timately, it's the responsibility of the RFC authors to make sure the p= rotocol spec is unambiguously clear and is complete.=C2=A0
=C2=A0
Regards,
Feng
=C2=A0
From:=C2=A0Bj=C3=B6rn Haase <Bjoern.= M.Haase=3D40web.de@dmarc.ietf.org>
Sent:=C2= =A0Friday, December 12, 2025 08:30
To:=C2=A0Hao, Feng &= lt;Feng.Hao@warwick.ac.uk>; juliahesse2@gmail.com <= juliahesse2@gmail.com>; cfrg@irtf.org <cfrg@irtf.org>
Subject:=C2=A0Aw: [CFRG] Re: RGLC on draft-irtf-cfrg-cpace-15
=C2=A0
Dear Feng,

thank yo= u for the private mail discussion yesterday where I think that we establish= ed a common view. Also Michel and me had a discussion yesterday. I have jus= t uploaded a new revision 16 and I think that the newly uploaded revision a= ddresses your major concerns.

We are now giving much more detailed g= uidance on use of "user" identities and mandate inclusion of user= identities if an application relies on guarantees from CPace.

We al= so have added the reference to your ISO-SPEKE paper and also added a statem= ent 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 ide= ntity identifiers that are to be held confidential and may be available upo= n protocol start. Such settings may show up
specifically in use-cases wh= ere 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 p= rovided for
secure IoT onboarding on stickers of industrial devices. I a= ssume that such application scenarios are out of the scope that you typical= ly are considering.

IMHO we need offer applications that need confid= entially for identities on how to best use CPace in their setting.

A= lso IMHO we shall allow and give best possible guidance to users for applic= ations where identity strings are just not available or where identity chec= ks 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 a= ny client knowing the password.

I'd appreciate your feedback on = the new revision 16.

Yours,

Bj=C3=B6rn

Gesende= t: Donnerstag, 11. Dezember 2025 um 17:43
Von: "Hao, Feng" <Feng.Hao=3D40warwick.ac.uk@dmarc.ietf.org>
Betreff: [CFRG] Re: RGLC on draft-irtf-cfrg-cpace-15<= /div>
=C2=A0
Dear Julia,
=C2=A0
  • 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 agai= nst 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 h= onest. So maybe the situation can be summarized like this?
=C2=A0
You're correc= t that the user identities are unique to a user/client. However, when a use= r 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, Alic= e-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 excha= nge transcript is another way to distinguish the parallel sessions and is e= asier to implement. So we settled on that for the revision of SPEKE in ISO/= IEC 11770-4. Your summary of the situation is correct.=C2=A0
=C2=A0
  • Interestingly, we analyzed this here: https://eprint.iacr.org/2024/234. That = paper models UC PAKE without session identifiers, so really password-only P= AKE. 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.=C2=A0
=C2=A0
Putting both part= ies' identities and transcript in the key derivation function is essent= ially 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 crit= ical parameter which needs to be explicitly defined in the spec. The revisi= on of SPEKE in ISO/IEC 11770-4:2017 had an additional consideration of main= taining the symmetry and the 1-round property as the original SPEKE.=C2=A0<= /div>
=C2=A0
Cheers,
Feng
=C2=A0
From:=C2=A0Julia Hesse <juliahesse2@gmail.com>
Sent:=C2=A0Wednesday, December 10, 2025 21:54
To:=C2=A0c= frg@irtf.org <cf= rg@irtf.org>
Subject:=C2=A0[CFRG] Re: RGLC on dr= aft-irtf-cfrg-cpace-15
=C2=A0
Dear Feng,

thank you for looking into this and helping us impro= ve 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 no= t aware of it. Let me summarize the attack, to see whether I understand cor= rectly.

- Alice wants to exchange a key with Bob, and she is using f= (pw)^x
- Mallory grabs her message and starts *another* exchange with Al= ice concurrently, where she produces f(pw)^y
- Mallory crafts the respon= se messages to Alice such that the resulting DH key will be f(pw)^xyz in *b= oth* exchanges
- Mallory can relay key confirmation messages between pro= tocols such that Alice accepts both sessions, having computed the same key<= br>
Mallory achieved all this without knowing Alice's password.
<= br>At first sight, this attack seems to void two important PAKE security pr= operties:=C2=A0
- Whenever Alice starts a key exchange with another part= y 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 pro= tected against in the UC version of CPace by the uniqueness of session iden= tifiers - Alice would assign different session identifiers to both exchange= s, 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 th= oughts.
1) How does the inclusion of party identifiers help in fending o= ff the attack?=C2=A0In the above description, Mallory can just contact Alic= e "in the name" of Bob, i.e., appending "Bob" to all hi= s messages to Alice. So party identifiers who are reused across key exchang= es do not seem to help here, neither in the final hash nor in the computati= on of the generator.=C2=A0
2) Why does the attack not show in the BPR se= curity analysis in our CPace paper?=C2=A0Two options: either the model does= not capture them, or the proof is incorrect.

I would like to unders= tand 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,
=C2=A0
I suggest you read the= paper by Burton Kaliski on "An unknown key-share attack on the MQV ke= y agreement protocol" (ACM TISS, 2001): https://dl.acm.org/doi/ab= s/10.1145/501978.501981
=C2=A0
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 identitie= s in the key exchange process. The user identities are only included in the= explicit key confirmation process, but explicit key confirmation is option= al.=C2=A0
=C2=A0
Menezes (co-author of = MQV) later proposed to address this attack by explicitly include user ident= ities 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 an= d HMQV Key Agreement Protocols" (Menezes, Ustaoglu, 2006): h= ttps://link.springer.com/chapter/10.1007/11941378_11.=C2=A0
=C2=A0
The above is in the co= ntext of a public-key authenticated key exchange scheme, but the same probl= em and lesson apply to password-authenticated key exchange.
=C2=A0
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 d= efinition of user identity and is known to suffer from the same kind of unk= nown 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 i= s fixed there.
=C2=A0
Cheers,
Feng
=C2=A0
=C2=A0
Hello Feng,

what we tell the end user re= garding the security guarantees=C2=A0 in sectin 3 is :
"A and B will produce the sa= me ISK value if and only if both sides did initiate the =C2=A0 protocol usi= ng the same protocol inputs, specifically the same PRS =C2=A0 and the same = value for the optional input parameters CI, ADa, ADb and =C2=A0 sid that wi= ll be specified in section Section 3.1."
With respect = to this security guarantee there is nothing to fix.

This clearly say= s: "if you are only using PRS and nothing else, the only thing that yo= u can rely on is that the remote side also knows the same PRS."
We moreover explicitly draw the attention of the reader to the consequence= s if no identity strings are added. So any reader of the specification is b= e well-informed.

What we should not be doing is *patronizing* the en= d 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 ind= ustrial measurement appliances does not mandate integration of surge protec= tion arrestors on all cable interfaces. But IEC61000 mandates to give clear= guidance for empowering the adult end user in the manual for secure use (&= quot;Avoid cables longer than 10m and don't use the unit in fixed outdo= or installation if you purchase the more accurate variant without surge pro= tection at the input cables.")

Yours,

Bj=C3=B6rn.


Gesendet: Montag, 8. Dezember 2025 um 16:49
An: "Bj=C3=B6rn Haase" <bjoern.ha= ase=3D40endress.com@dmarc.ietf.org>, "Bj=C3=B6rn Haase" <bjoern.m.haas= e@web.de>, "= ;cfrg@irtf.org" <cfrg@irtf.org>
Betreff: RE: [CFRG] Re: RGLC on draft-irtf-cfrg-cpace= -15

Hi,

=C2=A0

=C3=98=C2=A0 thank you for your feedback. So I=E2=80=99d like to sum= marize that the remaining aspect in our discussion is not a different view = on the attacks or possible vulnerabilities.
The key point in our discuss= ion seems to be a different point of =C2=A0view regarding which extend rema= ining freedom is left to application designers and integrators.

When the protocol spec says the user identi= ty is optional, it implies that the protocol is secure without it. But that= =E2=80=99s not the case, as shown by the impersonation attack. I think you = should consider updating the protocol spec in Section 6.1.

=C2=A0

=C2=A0

=C2=A0
_______________________________________________ CFRG mailing list -- <= a id=3D"m_311291505398720173m_-3920873534117066199m_-6256898222102827248OWA= 46758d0d-57cc-0331-6a42-ff2624927162" href=3D"mailto:cfrg@irtf.org" rel=3D"= noopener noreferrer noreferrer" target=3D"_blank"> cfrg@irtf.org=C2=A0T= o unsubscribe send an email to cfrg-leave@irtf.org
=C2=A0
=C2=A0
_______________________________________________ CFRG mailing list -- <= a href=3D"mailto:cfrg@irtf.org" rel=3D"noreferrer" target=3D"_blank">cfrg@i= rtf.org To unsubscribe send an email to cfrg-leave@irtf.org
_______________________________________________ CFRG mailing list -- cfrg@irtf.o= rg To unsubscribe send an email to cfrg-leave@irtf.org
_______________________________________________
CFRG mailing list -- cfrg@irtf.org
To unsubscribe send an email to cfrg-leave@irtf.org
--0000000000002c16f006460c63ba--