Summary

  • Revision 01 of the LAKE KEM-authentication draft says the Initiator authenticates the Responder only after verifying message_4_KEM; the Responder authenticates the Initiator only after verifying message_5_KEM.
  • Message 3 can be confidential and integrity-protected without authenticating the Initiator. The draft delays final application-key use until mutual authentication, transcript integrity, credential authenticity and proof of key possession have all been established.

Three protected messages are not a completed handshake

The tempting implementation shortcut appears after message 3. An ephemeral KEM exchange has produced a shared secret. The Initiator has validated a Responder credential, encapsulated to its static public key and sent its own credential inside protected ciphertext. The Responder has decapsulated another secret and decrypted that payload. A dashboard could plausibly colour the session green.

That would be the wrong receipt.

Revision 01 of KEM-based Authentication for EDHOC, submitted on 28 September 2026, states that the key protecting message 3 cannot authenticate the Initiator. At that point the Responder has not yet emitted the MAC that will authenticate itself, and the Initiator has not yet emitted the MAC that will authenticate it. The proposal adds two messages because a KEM owner first needs a peer to encapsulate to its static public key before it can prove possession of the matching private key.

The Datatracker record identifies an active LAKE working-group Internet-Draft whose IESG state is only I-D Exists. Its text asks for Standards Track status, but it is not an RFC, an approved standard or evidence of implementation. The current wording is a design proposal and expires on 1 April 2027 unless replaced or advanced.

Authentication arrives twice

The flow begins with an ephemeral KEM public key in message 1. The Responder encapsulates to it and returns the ciphertext plus its credential identifier in message 2. Before disclosing its own credential, the Initiator must retrieve, validate and accept the Responder credential under local policy. The draft is explicit about the distinction: a credential can be cryptographically valid yet belong to an untrusted or unintended party.

The Initiator then encapsulates to the Responder's static KEM key and sends the resulting ciphertext with its protected credential material in message 3. The Responder decapsulates this value, but neither possession nor decryption closes the handshake. message_4_KEM carries the Responder's explicit MAC evidence. After verifying it, the Initiator may treat the Responder as authenticated and persist the derived application material.

The asymmetry remains. Only message_5_KEM, carrying the Initiator's MAC evidence, lets the Responder authenticate the Initiator. The draft says a potential misbinding attack may not be detected until the Initiator verifies message 4 and the Responder verifies message 5. External Authorization Data should therefore be treated as unprotected, and keying material should not be stored persistently, until completion.

This is not ceremony. A single Boolean labelled authenticated cannot represent a moment when one endpoint has verified its peer and the other has not. Nor can a successful decapsulation say which identity, credential policy, transcript or application permission the shared secret was meant to support.

Freshness is a property of the session, not the algorithm name

The proposed key schedule mixes one fresh ephemeral contribution with two secrets derived from static KEM keys. The security section requires fresh encapsulations to each static key for every session. ss_I, ss_R and their corresponding ciphertexts must not be reused. It also requires the KEM to provide IND-CCA2 security and to bind the derived secret cryptographically to the recipient public key; IND-CCA2 alone does not eliminate re-encapsulation and unknown-key-share risk.

RFC 9935 standardises ML-KEM, and NIST FIPS 203 specifies the algorithm. Neither source assigns an identity to a key. NIST SP 800-227 describes secure KEM use, while the LAKE draft supplies the transcript and credential context proposed for this protocol. RFC 9528 remains the EDHOC baseline; the new draft changes the authentication choreography rather than proving a deployment result.

The draft also denies a broader inference. Its KEM construction offers implicit proof of participation, not non-repudiation. An authenticated LAKE peer is not automatically authorised to change a route, operate a device, spend money or accept a software update. Application policy and observed effect remain separate records.

The operational ledger should preserve that separation. Record the proposed method and chosen suite; credential identifier and local validation outcome; transcript identifier; processing of messages 2 through 5; MAC_2 and MAC_3 verification; a non-secret session/freshness identifier; the exact transition that permits key persistence; application authorization; protected request and response; and the final effect. Do not store secrets, and do not backfill later success into an earlier stage.

BTW's earlier RFC 9668 analysis examined a different boundary: combining EDHOC message 3 with an OSCORE request does not prove application execution. This draft creates a prior boundary. In its KEM method, message 3 has not yet completed authentication itself.

Running-Code Primacy turns the claim into negative-path tests: interrupt messages 4 and 5, replay static-key ciphertexts, substitute credentials, mismatch suites and inspect what state survives. Minimum Initial Specification argues for a small common invariant—explicit completion states and fresh per-session encapsulations—while leaving credential policy local. Reality Layers explains why cryptographic possession, trusted identity, authorization and effect cannot borrow one another's authority.

Sources