[Lake] Re: WG Last Call: draft-ietf-lake-authz-08 (Ends 2026-09-22)

[Christian Amsüss <[e-mail]>]

Hello ELA authors, group,

On Tue, Sep 08, 2026 at 09:55:06AM -0700, Renzo Navas via Datatracker wrote:
> Please review and indicate your support or objection to proceed with the
> publication of this document by replying to this email keeping [e-mail]
> in copy.

thanks for your work on this document.

I've found a few points where I think the document needs improvement,
but none of them should stop the doument going forward, because they are
either formal/technical in nature (and can be fixed easily, such as
missing or mismatched IANA entries), or not crucial for being a correct
document (so while I'd appreciate applying them, the document will work
as is as well).

* This document introduces the use of info labels 2 and 3. If I get
  things right, those are values that should live in the EDHOC Exporter
  Label Registry, but the IANA considerations do not register those
  values.

* In 4.4.2.2, processing message 2 defers to RFC9528 Section 5.3.3,
  which states that "When and how to perform authentication is up to the
  application". While ELA is acting within that, it may be useful to
  readers to be reminded that "No authentication is performed at this
  stage; it is deferred to the processing of message 4."

* ELA in recent versions admits that the voucher can be optional (when
  U would join any network anyway and merely uses ELA to show its
  authorization).

  Section 4.4.3.1 states that TBD1 is used in negative (critical) use.
  From the point of view of a device that does not expect a voucher,
  that option is not critical -- representing the fact that it offers
  the voucher_info as a means of onboarding into less trusting networks,
  whereas it would be perfectly happy to onboard into an open network
  just as well (for which it would send CRED_I by value, which this
  protocol admits).

  This could be reflected in the text by replacing the last sentence
  with "The sign is usually negative, indicating that the EAD item is
  critical, see Section 3.8 of [RFC9528]; a positive sign (non-critical)
  is allowed when the voucher is optional."

  (Consequently in 4.4.3.2, with s/Since/If/, and in 4.7.2,
  s/critical.//, and in 4.7.2.1 and 4.7.2.2 s/critical/(usually
  critical)/)

* On the same note of things-to-change-now-that-voucher-is-optional,
  but independently of whether the previous suggesion is accepted: 6
  says that "EDHOC message_4 is mandatory since it carries the Voucher";
  s/since/if/ fixes this, and the sentece after it should
  s/ELA/vouchers in message 4/.

* How to look up ID_CRED_I is out of scope of this specification. If
  there is some hint in any upcoming document about what can be done
  here, that would be useful to readers.

  (In particular, such a document could outline

  - under which conditions U already has access to the PRK
    by the time it commits to ID_CRED_I, and how that can be used to
    arrive at a key ID that only W can read, thereby not leaking
    identifying information to V, or

  - whether, at least in ELA forward flow, U and W can use their shared
    knowledge of CRED_V to do something similar to IPv6 privacy
    extensions or BLE privacy beacons, where different unauthorized
    parties V can only track U across joining attempts if they use a
    single CRED_V.

  but the content is admittedly beyond this document).

* 4.7.4 is not literally wrong, but feels a bit misleading:
  confidentiality is only confidentiality against passive attacks in
  both cases (9528 was often explicit in against-what when using the
  term confidentiality). And the distinction between being not
  authenticated (reverse) vs being authenticated (forward) is rather
  moot, given that time of sending information, the authentication of
  the latter is only relative to a kccs or a self-signed end-entity
  certificate.

* Schemes for CoAP give coap:// only. On an unconstrained link, I'd
  expect that they would use coap+tcp:// would be in active use as well.
  (Especially as using some coap without s is over-all beneficial as it
  can PoP for V in a single go.)

* The document is inconsistent about the content of LOC_W: 4.3.1 admits
  URLs or domains, whereas 5 has a SHOULD on "the protocol indicated by
  the scheme in the LOC_W URI".

  I'd guess that a domain would be fine, given all the rest happens
  through well-known intefaces, and V can just try some and remember
  what it tried?

* Section 5.4.2 is completely unreferenced -- nothing links in there,
  nothing metions "certificate request", nothing mentions "certrequest".

  What is this used for, and why is it not just a follow-up field to
  Fetch_CRED_U (like, Fetch_CRED_U_chain)?

* Operators of W may want to update their keys even within a single
  cipher suite. Obviously a party W will need to keep its old key
  available as long as any U is out, but is there any guidance on how it
  would introduce new keys? Use a new LOC_W? Decide based on ID_CRED_U
  which W to use?

* Section 6: whether U is authorized to interact with *V*. (Not W: The
  trust relation with W is built in, V gets authenticated through the
  voucher).

* .arpa name: Nice ot have that, but this is never referenced anywhere
  else in the document. It was used in the old CoJP appendix -- so maybe
  move to where that is resurrected? (And please resurrect it!)

* IANA considerations: This document uses
  application/lake-authz-voucherrequest+cbor,
  application/lake-authz-voucherresponse+cbor and
  application/lake-authz-vouchererror+cbor, but 7.4 and 7.5 only handle
  one of them.

* A.1: TBD_EAD_LABEL is from app-profiles. Is the plan here to have
  these clustered (even though app-profiles is just an informative
  reference)? If so, a note to RFC editor to replace might be helpful.
  Or there will not be a cluster, in which case, please consider an
  early allocation for app-profiles.

* https://github.com/lake-wg/authz/issues/84 is still open.

BR
Christian

-- 
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom