Summary

  • The IETF LAKE Working Group opened a Last Call on draft-ietf-lake-authz-08 on 8 September 2026, with comments due 22 September. The Proposed Standard target remains an active draft, not an RFC or IESG decision.
  • In ELA’s regular flow, the device sends ID_CRED_I in EDHOC message 3. The gateway passes it to an enrollment server; the server’s voucher reaches the device in message 4.
  • The draft explicitly says the device reveals its identity to an authenticated gateway before it knows whether the authorization flow will complete, and suggests a separate onboarding identity as one mitigation.
  • Daniel Kade proposes an enrollment receipt that preserves the order and outcome of the two decisions without storing a reusable device identity. That receipt is editorial analysis, not an IETF requirement.

The Working Group Last Call asks LAKE participants to support the document or explain objections and possible remedies by 22 September. The Datatracker history records the move from WG Document to In WG Last Call on 8 September. It is a genuine process step, but not a declaration that the design is settled. The current document record still describes revision 08 as an Internet-Draft intended for the Standards Track.

The proposal is called Lightweight Authorization using EDHOC, or ELA. Its attraction is compression. A constrained device U and a domain authenticator V perform EDHOC while an enrollment server W, reachable on the less-constrained side of the network, supplies the information needed to authorize the join. Authorization and enrollment can happen in parallel with authentication rather than as a second, separate protocol tour.

Compression does not make the three actors interchangeable. Revision 08 assumes an explicit pre-existing relation between U and W: the device holds W’s public key and location. V and W have an implicit relation, possibly based on Web PKI. U and V need no prior relationship. The protocol is designed to establish that last relation while using the first two.

The identifier moves in message 3

After receiving EDHOC message 2, U has authenticated V’s credential through EDHOC. U then sends message 3. Its external authorization data contains the location of W and fresh key material for protecting the eventual voucher. Its protected authentication data also contains ID_CRED_I, the identifier for U’s credential.

V places that identifier in a voucher request to W alongside the selected cipher suite, H_12—a hash binding the first two EDHOC messages—fresh Diffie–Hellman or KEM material, and a flag saying whether V wants W to return U’s credential. W associates H_12 with the identifier, looks up the policy for U and enforces it. If the identifier is known but policy denies the join, W returns a denial. If policy permits it, W can return U’s credential and, when the application requires it, a voucher.

That voucher has a specific direction. It is W’s assertion to U that W has authorized V. Its authenticated data binds the assertion to the current handshake, U’s identifier and V’s credential. Optional scope is opaque to V but readable by U and W. V carries the voucher back in EDHOC message 4; U verifies it and aborts if verification fails. RFC 9528 makes message 4 optional in base EDHOC. ELA makes it mandatory in this regular flow because it carries the authorization evidence the device is waiting for.

Only after message 4 is processed does the draft say both U and V are authorized to interact. Before that point, V is authenticated to U, but W’s authorization of V has not yet reached U. Meanwhile, ID_CRED_I has already reached V and, through the voucher request, W.

Identity protection has a named limit

This is not a claim that EDHOC identity protection has failed. EDHOC encrypts and integrity-protects the initiator’s identity against outsiders and unauthenticated active parties. ELA’s stated boundary is narrower: the device shares its identity with an authenticated V before it knows whether the ELA authorization flow will finish successfully.

The draft says so directly in its security considerations. It also supplies a proportionate option: U may use an onboarding-only identity, then use a different identity for later operational communication inside the established secure channel. That choice matters because authentication and authorization answer different questions. Possession of V’s private key establishes who controls the credential presented by V. The later voucher establishes that W authorizes that V for this U and handshake. Neither decision retroactively prevents the earlier recipient from learning what U already disclosed.

The distinction is familiar from other bootstrapping work, but the artifact is not the same. RFC 8366 defines a manufacturer-signed voucher artifact for assigning a pledge to an owner and pinning a domain certificate. ELA says its voucher has a similar role while aiming to be considerably more compact; it does not transplant the RFC 8366 artifact format. RFC 8995 supplies the broader BRSKI pledge–registrar–MASA comparison and treats audit and privacy as explicit operational questions. RFC 9031 shows another constrained join setting. These are context for the trust shape, not substitutes for ELA’s message order.

A denial is also an information event

ELA’s denial path makes the sequence easier to see. W can know the identifier but reject the join because policy restricts identities, time windows or acceptable authenticators. It then returns HTTP 403 or CoAP 4.03. W may also encrypt actionable rejection information for U—such as another V to try—which V relays in an EDHOC Access denied error.

That is useful automation. It is also a completed disclosure without a completed enrollment. The system should be able to distinguish a device that was admitted, a device that was redirected, a device rejected before its credential was fetched, and a device rejected after W evaluated its identifier. A single “handshake failed” counter erases the information-order boundary.

The IETF 126 LAKE minutes record that the design retained separate ephemeral keys for EDHOC and ELA components, received some signs of WGLC readiness, and would proceed to Last Call. The current call is the venue for testing the remaining protocol and privacy trade-offs. The LAKE Working Group controls that standardization process. Operators still control whether a permanent identity is presented, how W’s policy is versioned and what evidence survives a failed join.

Preserve sequence without building a tracking log

A responsible enrollment receipt should be deliberately narrow. It could record a one-way handle for the onboarding attempt, a fingerprint of V’s credential, the W trust-anchor and endpoint version, H_12, the applicable policy version, whether U used an onboarding-only or operational identifier class, and a bounded outcome: voucher accepted, policy denied, redirected, credential verification failed or timed out.

If an onboarding identity is later replaced, the receipt should record the transition without retaining a portable map to the operational identity. A retention deadline and deletion result belong in the record. Raw ID_CRED_I, full certificates, voucher plaintext and reusable cross-domain identifiers do not. Aggregated denial counts and latency can support operations without becoming a device history.

That schema is Daniel Kade’s proposal, not text in revision 08. The draft standardizes the exchange and explicitly leaves authorization policy outside scope. This is precisely why deployment governance has work to do: protocol success, policy approval and privacy-preserving accountability are adjacent records, not one fact.

Sources