# IETF108 Lightweight Authenticated Key Exchange (LAKE) Friday July 31st, 1100-1240 UTC Chairs: Mališa Vučinić, Stephen Farrell Charter: https://datatracker.ietf.org/group/lake/about Mailing list: https://www.ietf.org/mailman/listinfo/Lake Jabber room: lake@jabber.ietf.org Etherpad: https://codimd.ietf.org/notes-ietf-108-lake Meetecho link: http://www.meetecho.com/ietf108/lake/ Agenda: - Administrivia and agenda bash (chairs, 5 mins) - Intro to EDHOC (Göran Selander, 25 mins) - Open Issues (Göran Selander, 20 mins) - Tamarin study of EDHOC (Karl Norrman, 20 mins) - AOB # Minutes Minute takers: Francesca Palombini, Christian Amsüss Jabber logs: https://www.ietf.org/jabber/logs/lake/2020-07-31.html ## Administrivia and agenda bash (chairs, 5 mins) Intro and agenda bashing. ## Intro to EDHOC (Göran Selander, 25 mins) Göran presenting the slides. BK: On Auxiliary Data. On the slide, it showed up in the blue box. Is it covered under encryption, mac, signature? GS: Additional data is included in external_aad I think. Need to look it up. GS: Guarantees vary over AD. AD3 can be encrypted and confidentiality protected, AD2 has less; could look up details. DKG: see sl.12 TH2 should include the hash of the messages, which should include the additional data. GS: That's orrect. BK: At some points you can't send some data if you don't want them to be public, because you haven't authenticated the peer yet. DKG: For AD1 and AD2 maybe, AD3 should be safe. MS: see sl. 7 about method. Is there any requirement on initiator to understand whether m=0/1/2/3 will happen? GS: Currently no negotiation or information sharing on methods. This assumes that the initiator knows whether responder uses RPK or signature. It's an option if we want, using the same kind of error flow like in cipher suites, but is not currently included. MS: Consider adding that. Also where initiator has several credentials, eg. in group scenarios -- there should be error flow for those cases. (Eg. find out that PSK is not good enough and need to go with certificate). GS: Current spec only uses asymmetric protocol, PSK based authentication is out of scope to start with. How to find the credential is preovided in ID_CRED_R. GS: Could you give an example for the group case? MS: If you don't support PSK, then it does not really make a difference. Group PSK would have been an example. GS: Group excluded from the scope. MS: What's the enrollment goal -- start with a certificate and enroll with another? (sl. 6) GS: one scenario: start with manifacturer built in credential, which you use to enroll another certificate. GS: By the way, neither of the certificates need to go over the constrained link. BK: reference to the certificate, is it possible for the device never to dereference that reference? GS: In principle yes. Subir Das: ad deployment scenarios: Manufacturer 802.1ax certificate in device. If I activate after 1y and certificate is invalid, is there a way to still bootstrap the device? GS: revocation of credential used in the protocol is not excluded in the requirements. chenmeiling: Will the public key be used for signature or encryption? GS: It may be a signature key (for signing) or a static DH key, in which case it's used in the key scheme to derive a shared secret. ## Open Issues (Göran Selander, 20 mins) (Link from presentation: ) Issue \#2 MV: most of the hardware I've seen implements SHA256. 2 or 3 seems the most reasonable. I'd like to see us converge to one single alg to use. MS: we saw this in 6lo and we have solved it: https://tools.ietf.org/html/draft-ietf-lwig-curve-representations-11 and https://tools.ietf.org/html/draft-ietf-6lo-ap-nd-23#section-8.2 SF: Seems like something to pass IESG. MS: That's the plan. **AP: Mohit to comment in the issue with ref to the documents + everybody who has input comment in the issue.** AP completed:-) efficient! \o/ **AP: Göran to start the discussion on issue\#3.** SF: Encourage people to open issue on github but if it substantial also send email to the mailing list. ## Tamarin study of EDHOC (Karl Norrman, 20 mins) Karl presenting the slides. SF: is there a plan on how to wrap this theory work, getting polished, peer review, how long this will take? Not precise answer, just a general plan. KN: Put on arxiv, and thankful for reviewes there. Planning to submit to conference in August with wrap-up and polish. Not aware of anyone doing Tamarin modelling or other modelling on this. SF: So done soon-ish or when the protocol is finalized? KN: Trying to secure machine with more memory…(?). Also looking into computation proofs. Tobias Guggemos: sl 19 - not sure I understand this. (? hard to understand) KN: Only responder can compute that(?) [sorry I have a hard time following here] **AP (even though not officially named that): Göran to go through it and make issues of that** ## AOB BK: gather town to socialize after the session at . SF: Thoughts on how to procede from here? GS: Virtual meeting would be great. Will have some more input after the issues are more tracked. Mid-late September? MCR: suggesting Hackathon online SF: multiple implementation. Are people testing together? organizing an hackathon would help them? GS: there is a number of implementations. Would have to check if that would help. SF: plan to remove the PSK option in the next version. GS: should happen soon, + we need to include feedback, + waiting to get feedback on the other verification team. End of September sounds reasonable. SF: Ok so participants wait for -01 version to read and review. *[GS]: Göran Selander *[BK]: Benjamin Kaduk *[DKG]: Daniel Kahn Gillmor *[MS]: Mohit Sethi *[MV]: Malisa Vucinic *[SF]: Stephen Farrell *[KN]: Karl Norrman *[AP]: ACTION POINT