Hi Philipp,
Thank you for the excellent suggestion. I have added the text to my submission and revved it. 11-26/1163r4 is on mentor, please take a look.
Regarding Mark’s question in the chat in today’s teleconference, yes 1163 does address CID 42. I have added that to r4 as well. On a related note, the CID spreadsheet, 11-26/0853r3 has CID 42 assigned to me (thanks!) but has the submission
as 11-26/0912. That is a powerpoint presentation on my signature-based PQC exchange. Mark, can you update the database to mention 11-26/1163 as the submission addressing this comment? Much appreciated.
If anyone else has any comments on this submission, please send them here.
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 6/30/26, 8:54 AM, "Philipp Ebbecke" <00005e958b5c5855-dmarc-request@xxxxxxxxxxxxxxxxx>
wrote:
Dear Dan,
regarding my comment on adding normative text for handling of ephemeral material (DHss / MLKEMss), this is my proposal.
In the section "12.16.8.3 IEEE 802.1X" of 11-26/1163r3, in the subsection that starts with
"If the first Authentication frame is not rejected, the responder shall:" and continues with
"If the responder is performing a PQC protocol,": Add sth. like this at the end of the bullet list (after
the bullet that starts with "Use the ephemeral ML-KEM encapsulation key [...]"):
"• The responder shall retain DHss (if present) and MLKEMss until PTK derivation is performed following successful completion of EAP
authentication"
and mirroring this for the originator, in the subsection that starts with "After receiving the second Authentication frame" and continues
with "If the Authentication algorithm is <ANA1> or
<ANA2>": Add sth. like this at the end of the bullet list (after the bullet that starts with "If the public key is required by [...]"):
"• The originator shall retain DHss (if present) and MLKEMss until PTK derivation is performed following successful completion of EAP
authentication."
This is just to ensure that the normative text says that these secrets persist across the EAP exchange.
Regards,
Philipp
Gesendet:
Dienstag, 23. Juni 2026 um 19:16
Von:
"Harkins, Dan" <00003862fd143b8a-dmarc-request@xxxxxxxxxxxxxxxxx>
An:
STDS-802-11-TGBT@xxxxxxxxxxxxxxxxx
Betreff:
[STDS-802-11-TGBT] 11-26/1163r3
Hello,
I’ve updated my “fields not elements” proposal. Based on discussion with Jay I have modified the behavior of the 802.1X procedure to ensure that key exchanges are performed in the first two messages regardless of whether PMKSA
caching is being performed. A serendipitous result is that I have eliminated 2 extra messages from the exchange! So those concerned over the idea of splitting out PMKSA caching and EAPOL into separate exchanges, which results in 2 more messages in the off-chance
of a PMKSA cache miss, should be happy.
Please take a look and send comments to here. Please don’t wait until I present it again to bring up any substantive technical issues that you may find.
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