| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Hi Mathy, Switching the roles around in the aPAKE is an interesting take. The whole point of doing an aPAKE is to have some fallback security in the event of a hacked. The attractiveness of the server’s database is that it contains secrets for
all of the clients so that has, traditionally, been the thing an aPAKE focuses on.
If the server has the verifier then a hack of the server would mean that the server still has a guarantee that only legitimate clients can connect to its (hacked) network but the client has no assurance any longer that the network its
trying to connect to is not run by the attackers. If we switch that around so that the client has the verifier then when the server’s database is hacked it is reduced to a balanced PAKE. But you’re saying that what if it’s the client that gets hacked, not
the server. Well then the network has no assurance that the clients trying to connect are legitimate or not. The client will still have a strong assurance in the integrity of the network but the network has no idea who’s connecting anymore, and that is not
a good state to be in. Perhaps I’m biased in that I work for a vendor who creates the network-side of the Wi-Fi equation, not the STA side, but it seems to me that Wi-Fi security is to protect the *network*. Yes, clients want security too but that is
to give them the assurance that they’re connecting to the right network and all of the resources therein. It’s still protection of the network. So in my mind, any security benefit an aPAKE provides should benefit the network. I do agree with you that the first focus should be on a balanced PAKE. Hopefully the PAKE TTT will meet soon and we can discuss it in a medium that is more suited to discussion than this one. Regards, Dan. -- “the object of life is not to be on the side of the majority, but to escape finding oneself in the ranks of the insane.” – Marcus Aurelius On 10/31/26, 9:05 AM, "Mathy Vanhoef" <00006588701cd687-dmarc-request@xxxxxxxxxxxxxxxxx>
wrote: Hi all, At the moment, I don’t see a better alternative to CPaceOQUAKE(+). In an ideal world, we would pick the winner of a competition that evaluated PQC-PAKEs, similar to ML-KEM selection.
The CFRG held such a competition for classical PAKEs [1], but not for PQC-PAKEs. The second-best option is picking an already-standardized PQC-PAKE, but there is none. In the academic literature, there are 50+ PQC-PAKEs [2], but 802.11 isn't in a position
to review all these 50+ candidates. One remaining alternative, apart from waiting several years, is picking a PQC-PAKE which is also being discussed and proposed for standardization elsewhere, which only leaves CPaceOQUAKE(+). The main components of CPaceOQUAKE(+) have security proofs as Dan mentioned. It's arguably still a more recent protocol, but it's the only one also being proposed elsewhere, and several
groups have meanwhile studied its security, which increases confidence. Some clarifications regarding the augmented CPaceOQUAKE+ variant: - If one is okay with giving the plaintext password to both the client and server, a secure channel is not needed for registration. The server can generate the verifier on its own
and subsequently remove the plaintext password from its memory. See Section 8.1.1.2 of draft-vos-cfrg-pqpake-03. This comes at the cost of 1 or 2 extra messages because the server needs to inform the client of the salt value it used to construct the verifier. - The augmented protocol could also be instantiated such that the STA acts as the 'server' and the AP acts as the 'client'. That is, the STA can hold the verifier while the AP holds
the password. That way, if an insecure STA gets compromised, which can arguably be more likely than the AP being compromised, some security is still retained. (I'm not necessarily saying we should do this, but it is a possibility). - When including key confirmation, the augmented CPaceOQUAKE+ variant requires 5 messages, and the balanced CPaceOQUAKE variant requires 4 messages. This is because augmented CPaceOQUAKE+
already includes key confirmation in its 5 messages. For balanced CPaceOQUAKE, an extra key confirmation message is needed, making it 4 messages. I'd personally first focus on the balanced variant of CPaceOQUAKE since it has less overhead and is arguably a simpler protocol and therefore easier to standardize. Supporting the
augmented variant can be a second step. Best regards, Mathy [1] S. Smyshlyaev, "Results of the PAKE selection process", CFRG mailing list, 20 March 2020.
https://mailarchive.ietf.org/arch/msg/cfrg/LKbwodpa5yXo6VuNDU66vt_Aca8/ [2] Alnahawi et al., "SoK: PQC PAKEs - Design, Security and Performance".
https://eprint.iacr.org/2025/119 Van: Harkins, Dan <00003862fd143b8a-dmarc-request@xxxxxxxxxxxxxxxxx>
Hi Sigurd, On 10/30/26, 10:20 AM, "Sigurd Schelstraete" <0000147fea1cee5c-dmarc-request@xxxxxxxxxxxxxxxxx>
wrote: Hi all, Thanks to the experts for trying to address the issue of the missing PQC PAKE in 802.11bt. For those of us who are not security experts, can someone clarify the following:
1.
The IRTF response mentioned ongoing discussions on draft-vos over the reflector. Can someone summarize the discussion points? Are there any identified fundamental shortcomings? There have been requests on the CFRG mailing list to do a call for adoption. The IETF is the week after the IEEE and I do expect this topic to come up. CFRG has 2 meeting slots. I will be attending and will let
the TG know what happens. The CPaceOQuake draft is also dependent on another CFRG draft (which *is* a RG document) called kemeleon and there are 2 pull requests (from Mathy Vanhoef) on the kemeleon github repository to make the encoding
and decoding work in constant time. I’m confident those will be accepted.
2.
If I understand correctly, CPACEOQUAKE comes with a formal security proof. Is this proof generally accepted by the cryptographic community, or are there aspects of the proof that remain
under discussion? CPaceOQuake itself does not have a formal security proof. CPace has a security proof. It is based on classical cryptography and therefore is vulnerable to a cryptographically relevant quantum computer. It is “quantum
annoying” though the quantum attacker will be slowed down. The security of OQuake is discussed in section 11.2 of draft-vos. Here’s a link: https://datatracker.ietf.org/doc/html/draft-vos-cfrg-pqpake-03#name-security-against-quantum-at So UC is the gold standard of cryptographic proofs and OQuake does not realize UC functionality against certain quantum attackers but it does have a game-based security proof in the random oracle model.
The composite protocol has been analyzed by 3 different groups, as mentioned in the draft. So there is confidence in the construction of the hybrid protocol. There are some caveats: the identities are important
to the proof and OQuake needs to get a derived secret and not the raw password, but those are part of the CPaceOQuake draft already. Provided those are satisfied in a TGbt version of CPaceOQuake (and they are in 11-26/0089r7) I feel comfortable with the protocol.
I’m sure others will voice their opinions either way.
3.
With draft-vos being an individual contribution at this point, are there any alternatives for PQC PAKEs (at any stage of development) that could potentially be considered for use in
802.11? OQuake is very similar to NoIC which the security proof relies on but there’s no point in abandoning OQuake for NoIC because they’re essentially the same. And, as I mentioned, I’m
pretty sure that it will be accepted as a CFRG RG work item. So the individual contribution concern should go away. Looking at the discussion so far, I'd make the following observation and ask one additional question:
1.
It does not appear that publication as a finalized standard is, by itself, the deciding factor. Some participants appear comfortable using draft-vos as the starting point despite the
possibility of future changes, while others have raised concerns regarding its maturity or suitability. The key question therefore appears to be the maturity and confidence level of a proposal rather than on whether it has completed formal standardization. I think that’s a very fair summary. The draft is clear about what needs to happen to retain the security guarantees it is providing and we, TGbt, can propose a protocol that abides by those requirements and whether
it ends up being word-for-word identical to whatever RFC draft-vos becomes is, IMHO, irrelevant.
2.
Can we agree that any PQC PAKE proposal adopted in 802.11bt should be supported by a formal security analysis, with sufficient public review to provide confidence in its security properties?
By modern cryptographic standards, that appears to be a pretty basic expectation. I think that’s a great idea. First things first, though. We need a protocol in the TGbt draft that can be analyzed. Do you happen to know anyone who would analyze our protocol? Regards, Dan. -- “the object of life is not to be on the side of the majority, but to escape finding oneself in the ranks of the insane.” – Marcus Aurelius Regards, Sigurd From: Jay Yang <yang.zhijie@xxxxxxxxxx>
This email was sent from outside of MaxLinear. Hi Dan, Thank you for the further response. I also appreciate your pointing out the reference issue in my contribution. In the 3GPP specification (3GPP TS 23.261 (Rel-10)), the reference format of I-D is as follows: [8] IETF Internet-Draft, draft-ietf-mext-flow-binding-09.txt, "Flow Bindings in Mobile IPv6 and Nemo Basic Support", work in progress. [12] IETF Internet-Draft, draft-ietf-mext-binary-ts-04.txt, "Traffic Selectors for Flow Bindings", work in progress. I plan to remove the URLs from my contribution and correct the reference issue as follows: IETF Internet-Draft, draft-vos-cfrg-pqpake-03.txt,
"Hybrid Post-Quantum Password Authenticated Key Exchange", work in progress, 13 October 2026. Additionally, I will try to address as many as possible other issues pointed out in 26/1452r1 in the next revision before/after I arrive in
Bangkok. Let us continue the F2F discussion then and look forward to more cooperation. 杨志杰10343608 Thanks Best Regards Jay Yang (杨志杰)
Original From: Harkins,Dan <00003862fd143b8a-dmarc-request@xxxxxxxxxxxxxxxxx>
To: STDS-802-11-TGBT@xxxxxxxxxxxxxxxxx
<STDS-802-11-TGBT@xxxxxxxxxxxxxxxxx>; Date: 2026年10月30日
13:55 Subject: Re: [STDS-802-11-TGBT] Fw: IEEE 802.11 liaison communication to IRTF regarding draft-vos-cfrg-pqpake
Jay, Thanks for the rule dump. I’ll note the excerpt “IEEE 802 prefers that this be avoided if at all possible.” Can we avoid this? Yes, we absolutely can. It says that it is inappropriate to use an I-D as reference material and that is EXACTLY what you’re doing. You’re not citing it as
a work in progress, you’re using it directly as reference material because you’re including URLs to an I-D in your submission! What is inappropriate is this from11-26/1203r4: a)
Encapsulate
ut (part of upk) using 2-round Feistel encryption, producing
S and T, following the equations defined in subclause 8.2.1 (Initiation) :
https://datatracker.ietf.org/doc/draft-vos-cfrg-pqpake/02/. It’s a URL! This is not citing it as a work in progress. You’re
referring, directly and normatively, to an I-D, it is reference material. That is exactly what is deemed inappropriate. And while you say “/02”, the URL you’re pointing to, if anyone bothered to click on it, is actually the -01 version. To make this
even worse, there is no 8.2.1 in the -01 version of this I-D that you’re pointing to* so this section in your submission is not coherent. Anyone who tried to follow the URL you provide would be presented with something that didn’t exist—“follow the equations
in section 8.2.1 of this Internet-Draft that doesn’t have an 8.2.1 section.” This is not “a dated, versioned reference” as you try to portray it. Furthermore, this URL is already old! The current version is -03 and you’re referring to -01. So what do you propose? Constantly updating the TGbt draft to inappropriately refer to a URL and have the URL change
as the I-D changes? And hope that nothing changes in the URL-referenced document to break things in the TGbt draft? Well sorry, your submission has already been broken (assuming it could be updated to point to -03) because the + version of the protocol behaves
differently than the non-+ version in the response so your 12.17.6.2.3.2 doesn’t work using the (inappropriate) reference. Can you give any example of this sort of thing—a URL being inserted into a proposed amendment to the IEEE 802.11 standard to specify normative behavior—being done in any other TG in 802.11? As someone who implements 802.11 standards I can tell you this is not a realistic method of spec development. It would mean nothing could be implemented for at least 3 and probably more like 4+ years because
there’s no way to implement to a moving target. We cannot wait 4+ years to have an implementable PAKE in TGbt. You said my proposed model is “not a wise approach” but I described exactly how it works in practice and it works great. Our standard is not suffering today for practicing this model in the past. If you would
like to criticize the model of spec development I’m proposing then please directly address it as I have addressed your proposal for spec development. Dan. * I know you’re gonna try and fix this in an update to 11-26/1203 before the Bangkok meeting (after I pointed the problem out to you here) but it won’t matter because it illustrates the problem with the scheme
you are proposing. It’s broken. It doesn’t work. It’s not sustainable. -- “the object of life is not to be on the side of the majority, but to escape finding oneself in the ranks of the insane.” – Marcus Aurelius On 10/29/26, 4:59 PM, "Jay Yang" <yang.zhijie@xxxxxxxxxx> wrote: Hi Dan, Thanks for the response. Seems there is some misunderstanding on the I-D boilerplate: The boilerplate says it is inappropriate to cite a draft
other than as work in progress. Citing it
as work in progress — which is exactly what a dated, versioned reference does — is not prohibited by that text; it is the only use the boilerplate contemplates.
Status
of This Memo
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts.
The list of current Internet-Drafts is at
https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate
to use Internet-Drafts as reference material or to cite them other than as "work in progress." Also, according to the the Cross-Referencing rule(see highlight part below) between IETF and IEEE 802 defined in RFC 7241, it's allowed to
reference non-expired ID by IEEE 802. Correct? Welcome your further insights, and feel free to correct me if I make any mistake. 3.4 Cross-Referencing IETF and IEEE 802 each recognize the standards defined by the other organization. Standards produced by each organization can be used as references in standards produced by the other organization. IETF specifications may reference IEEE 802 work in progress, but these references should be labeled "Work in Progress". If the references are normative, this will block publication of the referring specification until the reference is available in a stable form. IEEE 802 standards may normatively reference non-expired Internet- Drafts, but IEEE 802 prefers that this be avoided if at all possible. Informative references in IEEE 802 standards are placed in a bibliography, so they may point to either approved IETF standards or IETF Internet-Drafts, if necessary. When an IEEE 802 standard is revised, it normally retains the same number and the date is updated. Therefore, IEEE 802 standards are dated with the year of approval, e.g., IEEE Std 802.1Q(TM)-2011. There are two ways of referencing IEEE 802 standards: undated and dated references. IEEE 802 practice allows undated reference to be used when referencing a whole standard. An undated reference indicates that the most recent version of the standard should be used. A dated reference refers to a specific revision of an IEEE 802 standard. Since clauses, subclauses, tables, figures, etc., may beDawkins, et al. Informational [Page 15] RFC 7241 IEEE 802/IETF Relationship July 2014 renumbered when a standard is revised, a dated reference should be used when citing specific items in a standard. IETF standards may be cited by RFC number, which would also be a dated reference. If an undated reference to an IETF Internet Standard is desired, a number is also assigned in the "STD" series [BCP9], and these references refer to the most recent version of an IETF Internet Standard. 杨志杰10343608 Thanks Best Regards Jay Yang (杨志杰)
Original From: Harkins,Dan <00003862fd143b8a-dmarc-request@xxxxxxxxxxxxxxxxx>
Date: 2026年10月28日
01:39 Subject: Re: [STDS-802-11-TGBT] Fw: IEEE 802.11 liaison communication to IRTF regarding draft-vos-cfrg-pqpake
Hi Jay, I would like to focus on just this one paragraph of yours: On 10/25/26, 11:01 PM, "Jay Yang" <yang.zhijie@xxxxxxxxxx> wrote: The key point is that the PQC PAKE protocol is merely a tool for 802.11. Why should we duplicate the entire protocol into the 802.11 draft?
In the event that a security issue arises within the Wi-Fi industry, who would be responsible for addressing it? Since the authors are part of CFRG, not 802.11, it is not a wise approach. I’m not sure what you mean by “merely a tool” and I don’t follow how that means we shouldn’t duplicate the protocol in the TGbt draft. I have been maintaining that the CFRG draft describes a tool—in fact several
tools—and not a protocol with on the wire (or over the air) specification. Therefore we can, and should, take as much of that draft as possible and incorporate it into our draft (that has over the air specification) so that we have something implementable. I will tell you why we should not refer to the draft. First of all, the I-D itself says in its boilerplate “It is inappropriate to use Internet-Drafts as reference material or to cite them other than as ‘work
in progress.’” So it is inappropriate to refer to drafts. We need to duplicate the parts of the draft we want if we don’t want to wait 4 years to have an implementable 802.11 PQC PAKE. If we were to ignore that and refer to the draft anyway, it would not
be implementable because that draft, as we have seen, is a moving target. It would not be possible to implement the TGbt draft if the draft just points to a moving target. I maintain it would be wrong for the group to not have anything implementable for
4 years, especially since we have told 2 external organizations that we’re working on a PQC PAKE. Therefore, we need something solid in the TGbt draft that can be implemented and we need it ASAP, not in 4 years. Regarding what happens if “a security issue arises within the Wi-Fi industry”. Well, the Wi-Fi industry, by whatever definition you use, should handle it. If someone in the CFRG identifies a flaw or an issue
in the CFRG draft (or even in an RFC) then the Wi-Fi industry should look at the issue, see if it applies to what we have and if so, address it in the recommended manner. There is precedence for this! Let me give you a little 802.11 history: SAE proposed a rejection sampling method method of PWE computation (euphemistically called “hunting-and-pecking”) because the alternative, Icart’s method, was patented. In 2019, the Dragonblood attack showed
that hunting-and-pecking was flawed. It could be done in constant time but it was fragile and wasteful and just about every implementation did it wrong. Serendipitously, around that time an unpatented way of hashing to an elliptic curve was being proposed
in… guess where… the CFRG. But it was a draft and it was inappropriate to just refer to it. We needed something in the standard that was implementable. The draft discussed several ways to hash to a curve for different types of elliptic curves. But we only
supported a few curves—the NIST ones and the brainpool ones, all Weierstrass curves—so I copied a part of the CFRG draft that did the Simplified Shallue-Woestijne-Ulas (SSWU) method with Weierstrass curves which became 11-19/1173. That eventually got put
into the TGm draft. SSWU uses a constant, z, which I calculated, and it became table 12-2 “Unique Curve Parameter”. After some time, someone on the CFRG list pointed out that the formula to calculate z might be patented. So the CFRG draft changed to come
up with a different formula to calculate z. So guess what we had to do? Change the formula in the the TGm draft! So I wrote 11-19/1817 which changed the formula and generated new values for z. And that’s what we have today. A copied subset of what ended
up becoming an RFC. Our standard diverges from the RFC but it doesn’t matter because what we have is secure and it works and it is not patented. When an issue arose with the CFRG draft we addressed it ourselves. This model works and we should do it in TGbt. We should take the parts of draft-vos that we need and specify a PQC PAKE in the TGbt draft. If any issue arises in draft-vos (or draft-irtf-cfrg-whatevernameitbecomes)
we should analyze the issue, and if it is applicable to what is in the TGbt draft we should change the TGbt draft in the manner recommended by those who came up with the issue. This is not a problem. It works and it is a wise approach. Regards, Dan. -- “the object of life is not to be on the side of the majority, but to escape finding oneself in the ranks of the insane.” – Marcus Aurelius To unsubscribe from the STDS-802-11-TGBT list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBT&A=1 To unsubscribe from the STDS-802-11-TGBT list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBT&A=1 To unsubscribe from the STDS-802-11-TGBT list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBT&A=1 To unsubscribe from the STDS-802-11-TGBT list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBT&A=1 To unsubscribe from the STDS-802-11-TGBT list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBT&A=1 To unsubscribe from the STDS-802-11-TGBT list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBT&A=1 To unsubscribe from the STDS-802-11-TGBT list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBT&A=1 To unsubscribe from the STDS-802-11-TGBT list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBT&A=1 |