Summary

  • The LAKE working group's 28 September AuthKEM revision removes a four-message variant present in July's draft. That older variant placed the initiator's credential identifier in plaintext in the first message and expressly gave up its identity protection.
  • Revision 01 specifies five mandatory messages. The responder can authenticate the initiator and derive application keys after verifying message 5; the initiator has a different completion point after message 4 and creating message 5.
  • The proposed method is not automatically post-quantum. Its authors say quantum-resistant authentication follows when the method is instantiated with a post-quantum KEM. The method number is suggested, not an IANA assignment.

The revealing edit is a deletion. In July, section 6.3 of the AuthKEM Internet-Draft sketched a way to cut its five-message handshake to four. The initiator would send ID_CRED_I in the clear in message 1, allowing the responder to work with the initiator's static key earlier and dispensing with message 5. The draft itself named the price: the initiator's credential identity would lose protection. That was an optional design sketch, not a deployed failure or an IETF recommendation to expose identities.

The version dated 28 September no longer contains that four-message section. Its protocol overview instead declares message_1, message_2, message_3, message_4_KEM and message_5_KEM mandatory. This is not a claim that cryptographers can never design a shorter KEM exchange, nor evidence of why the editors removed the variant. It is a narrower, checkable statement about what this working-group text now proposes. The five-message architecture itself was already in the July draft; what changed is the absence of its visible privacy-reducing shortcut.

Why does the last message matter? With static KEM authentication, the owner of a private key must first receive a ciphertext encapsulated to its public key before it can prove possession of the corresponding secret. The draft says that dependency can add up to one round trip. In its flow, message 4 carries the responder's key confirmation and message 5 carries the initiator's. The initiator may derive application keys after it has processed message 4 and created message 5. The responder must verify message 5 before its own key derivation and authenticated application traffic.

The endpoints do not cross the same completion line at the same instant.

Credential privacy has another boundary. The draft requires the initiator to validate and accept the responder's credential under local policy before sending its own encrypted credential in message 3. This requirement was present in July too; it is not a September innovation. Its purpose in the proposed flow is to avoid handing the initiator's credential to a party with a cryptographically valid but unintended or untrusted identity. Encryption, peer validation and final mutual authentication are related but distinct checks.

The revision also narrows its registry request. July's text proposed COSE ML-KEM algorithm numbers, EDHOC cipher suites and an authentication-method number. September's section 7 proposes only a method-type value, 5 (suggested), while citing separate work on PQ KEM representation and quantum-resistant LAKE suites. Nothing in that edit proves those other proposals have been approved or that IANA has assigned value 5. The draft explicitly says its KEM method is independent of a particular KEM; the post-quantum claim holds when a suitable post-quantum KEM is selected, not whenever an implementer displays the method name.

For an operator testing constrained-device onboarding, the practical checklist is therefore not just a message count. It is whether the intended credential remains private in the chosen flow, whether the responder waits for message 5 before treating the peer as authenticated, which algorithm and suite were actually negotiated, and what an aborted exchange leaves behind. Those are Daniel Kade's evaluation questions, not a new IETF audit format. The current text is an active Internet-Draft, not an RFC, a registered deployment profile or proof that devices have adopted it.

Sources