RN doing introductions.
RN: Document status. Updated both WG documents and individual
submissions (some new). Ongoing discussion on rechartering, which will
continue today.
YS presenting, slides
YS (p2): Supported models -- unilateral, mutual; background check,
passport.
YS (p4): Cross-referencing with parallel work in TLS. Clearer motivation
and alignment with EDHOC properties.
MUS: Motivation in TLS is different from what you do here.
Intra-handshake is there, but why is client being attested here? Would
like to see use case quoted for that.
CA (on chat): Well in EDHOC, the common case is mutual authentication;
in TLS people even use a different acronym for that.
MCR: We're saying it's a different thing and that's out of scope.
MUS: Yes, so it needs differnt motivation.
MCR: EDHOC is not TLS, this is different. We're just saying there's
other related work, but the present work is different.
MUS: But that work is referenced to build motivation.
MUS (on chat): The properties here
https://www.ietf.org/archive/id/draft-ietf-lake-ra-03.html#section-3 are
not sufficient. It has to be defined what does modification mean; what
it means to run in parallel. Property 3 is not correct: The privacy
properties do change.
MCR: MUS's comment on scope is not addressed in draft, please address
collaborating with MUS.
GS: Typical IoT use case is that you don't want bad devices in network;
thus client is attested. Good to spell that out.
YS: Agreed.
YS (p5-8): Changes and additions.
YS (p9): Next steps.
ZJ (chat, for offline discussion): for the part 5.4.2. Result_request,
does nonce is necessary to guarantee freshness, as the attester still
can use an old attestation result and sign it with this "new" nonce.
MUS (on chat): believe it is necessary but not sufficient. which is to
say you still need the initiator to time bound it, and nonce alone is
insufficient.
ELP presenting, slides
ELP (p2): Draft frozen since call for analysis issued.
ELP (p3-4): Updates of the test vectors. Re-did interop tests.
ELP (p5-6): Compiled claimed security properties. Downgrading,
post-quantum concerns, etc.
ELP (p7): Formal analysis call done. Will be taking place. Findings to
be presented during next IETF.
MUS: Which tool is used at Orange?
ELP: Don't know. They use computational proofs.
CA (chat only): I'm looking forward to using this in an ACE-OSCORE style
scenario -- that'll give confidentiality against a present-day AS, and
decrypt-later protection unless the AS stores the keys (and gets
compromised later)
MT presenting, slides
MT (p2): Recapping the concept. Application profile = configuration
about intended execution of EDHOC. Out-of-band and in-band venues.
MT (p3): Updates from -02
MT (p4): Now allows also information about security protocol that comes
after EDHOC. No concrete use case, but consistent with goal and
semantics.
MT (p5): prescriptive vs non-prescriptive parameters
MT (p6): Allow initiator to trigger responder to provide description.
MT (p7): reply_flag param, mandate a response with info or keep
optional
MT (p8): determining size of output for EDHOC_Exporter. No need for a
separate draft about this
MT (p9): Disseminating this info through SVCB records
MT (p10-11): appropriate wire-format
MT (p12): toolbox may be completed, asking for feedback
MV: Timeline: Done with params, what is the expected timeline?
MT: Might complete by next IETF.
GF presenting, slides
GF (p2): Generalized protocol, not just authorization/enrollment;
3-party workflow is valuable for other cases too. Having item w/o
voucher value helps implement EAD item state machine.
GF (p3): EDHOC PQS suites. to cover for next draft version
GF (p4): V=W on hold until PQS is sorted.
RN: about PQ. Can you finish this even if EDHOC changes in future?
GF: We have some proposed cipher suites.
RN: Just proposals for now. We don't know for sure what will exist.
GF: IIRC, all we need to modify in authz is field to support ciphertext,
independent of ciphersuite.
RN: Recommendation: Be as agnostic as possible.
JPM: There's nothing special with the selected cipher suites. It would
apply to all KEMs.
GS presenting, slides
GS (p2): Background. ID_CRED is reference to credential.
GS (p3): How is CRED used in EDHOC?
GS (p4): Lightweight enrolmen: EST-OSCORE. Sufficient to get cert hash.
E.g., useful for post-quantum certs. Doesn't work today due to design of
EDHOC.
GS (p5): So let's replace the cert with a hash of the cert in specific
computations/derivations that normally take the credential by value as
input. Let's signal that with a new COSE header.
GS (p6): History from -00 to upcoming -01. Value of COSE header is the
hash function.
GS (p7): Summary. Need to do security considerations
CA: Lots of discussion during original EDHOC about having cred and not
just key in, and not just identifier. I'm all for not having to hash
arbitrary-length data all the time. But what changed?
GS: Mentality in protocol was "put everything in transcript hash", and
nobody objected. Let's ensure this is not a bad idea...
RN: Ask for some reviews
GS: Yes, take into account Marco's review. Make v-01.
GS presenting, slides
GS (p2): Make EDHOC quantum resistant. 3 parts: Signature, key exchange,
static DH. Respectively: drop-in, some more work, nothing available.
PW (as an individual): This is just pure post quantum, not hybrid? Seems
to be a push for hybrid...
GS: Good point. For KEMs, works also for hybrid KEMs. For signatures,
need to check but think it works.
PW: To be fair, the key exchange part is most important for hybrid
GS: Original purpose: cipher suites. Deployers concerned whether quantum
algorithms will be added.
GS (p3): Length of G_Y can come from cipher suite.
LPC presenting, slides
LPF (p2): KEM-based auth for EDHOC.
LPF (p10): KEM used to avoid the signatures.
LPF (p2-6): Overview and details on updates.
LPF (p7-p14): Extension of protocol. Simplicity and sticking with
existing flow vs. earlier authentication. Summarized on p14.
KK: Is the goal to replace authentication with PQ authentication? Or to
add PQ altogether?
LPF: It's combining both. Can be KEM for one and PQC for other. Adapts
same concepts of how EDHOC combines DH and signatures.
KK: So no traditional signatures?
LPF: No. No hybrid approach.
GS: What about identity protection?
LPF: Formal verification not happened, but think it's covered.
GS: But same types as in original messages 1/2/3?
LPF: We changed message_3. …? Diffeentiated between active and passive
attacker.
MC presenting, slides
MC (p1): Utilizes preshared long-term key.
MC (p2): Combined satellite and cellular network. From 3GPP: They use
IPsec for backhaul protection, but too heavy for this backhaul.
(Referingcing … other draft(?)).
MC (p3): Motivated by improving efficiency by reusing symmetric-based
methods from 3G/4G/5G networks. AKA is in there, try to reuse it.
MC (p4): Challenge-response creates keys.
MC (p5): Protocol flow.
MC (p6): New method 5: EDHOC-AKA
MC (p8): Differences from EDHOC-PSK
MC (p9): Summary + next steps.
MCR, chat: Why not EDHOC-EAP-AKA? RFC4187. It's widely implemented.
ELP, chat: I think it was commented already in the mailing list, but
couldn't you just send the extra information needed for AKA in the EAD
handlers of EDHOC_PSK, rather than defining a new method?
CA (on chat): +1; My gut feeling from the pres is that AKA can probably
happen in ID_CRED_x or in EADs and then PSK.
MT (on chat): Could it be as simple as: the external PSK used in
-edhoc-psk can be the result of an earlier AKA execution?
GS: Commented by mail already; questions still open: You map AKA into
EDHOC fields. As far as I see, these exist in PSK (ID_CRED_R for
token, ID_CRED_I for response). Seems to be overlapping. p8 says that
difference is in PRK. Using EDHOC-PSK formula with PSK=K_AKA gives you
that.
GS: Also, it's not clear to me why there are 2 authentications going on.
Maybe you think of different endpoints?
GS: On "backhaul from satellite", there are no credentials in satellite,
but in UE, right? Does this propose SIM credentials in satellite?
[MT did you understand? Nope]
MC: On differences AKA/PSK: Read PSK; difference is PSK is going into
key derivation, but (note takers did not understand)
MC: In satellite, there is no SIM/eSIM, but in NTN scenarios, GNP(?) is
deployed on satellite. No need to use SIM/eSIM.
RN: Please take rest to list, out of time.
RN: Ongoing discussion on the mailing list to update the Charter.
RN: Main extensions:
Input and comments came. Paul has to review as AD.
PW: Discuss the Charter text. When you are done, I'll check and we can
start the rechartering. A bit concerned on WG documents not yet
proceeding to the IESG.
PW: When documents are waiting on external parties, please indicate
using a note in the datatracker and pause it there.
CA on chat: "Waiting for external" definitely applies to GREASE: Needs
implementation that shows it working.
MV: Not in data tracker: EDHOC-PSK is in formal analysis stage. RA draft
was paused due to IETF back-and-forth between intra and inter. Will
update datatracker to represent state better.
MT: June 2026 would be good milestone for -lake-app-profiles, like
impl-cons. As to -impl-cons, it's ready for me but we need input/content
from other implementors (e.g., Christian, Geovane, and Lidia)
GS: Something maybe before others is PQ cipher suites. For those
deploying EDHOC already. Otherwise, fine for me.
RN: So WG thinks charter is ready.
PW: Will read and recharter based on that, and then initial IESG review;
then public phase. Can be a few weeks.