Hi Rafa, Thanks for bringing up this question. I think this is a very good discussion to have at this point.
First discussion is probably why resumption is needed. I think there are three things that can be more optimized in a resumption. - A) Message sizes in the protocol. - B) Less asymetric operations in the protocol - C) External things like fetching credentials from a database, revocation, path validation, I think there are four ways to do this - 1) EHDHOC is lightweight enough. Just redo full EDHOC. (similar to full handshake in TLS) - 2) Use PSK with ECDHE (similar to psk_dhe_ke in TLS) - 3) Use PSK with exchanged random values (similar to psk_ke in TLS) - 4) Derive from PSK without new radnomness (similar to key update in TLS) I don't think 4) is needed. 2) or 3) provides nice optimizations. 2) provides significantly better security than 3) KUDOS in CORE WG alrady provides 3) when EHDOC is used to key OSCORE. I would suggest going 2) I think that is lightweight enough with a total of around 100 bytes for the three flights, a single asymmetric operation, and no need to fetch external authentication material. 3) would be ok to use for a short while, but then the recommendation would have to be to rerun 1). 2) you can rerun for a much longer time. All things considered 2) might therefore be more lightweight than 3). PSK authentication suffers from tracking and fingerprinting when the psk identifier is reused. If 2) or 3) is is done there should be a good solution for how to provide client identity protection. One option is to derive a new random psk identifier in the full EDHOC as well as in the resumption: PSK = EDHOC-KDF( PRK_4e3m, 10, TH_4, psk_length ) PSK_ID = EDHOC-KDF( PRK_4e3m, 11, TH_4, psk_id_length ) The Resonder could alternatively send an encrypted PSK_ID to the Initiator Cheers, John From: Lake <lake-boun...@ietf.org> on behalf of Rafa Marin-Lopez <r...@um.es> Date: Sunday, 22 January 2023 at 19:08 To: l...@ietf.org <l...@ietf.org>, EMU WG <emu@ietf.org> Cc: Rafa Marin-Lopez <r...@um.es> Subject: [Lake] EDHOC rekey Dear LAKE WG, EMU WG members: We are in the process of updating EAP-EDHOC I-D, which uses EDHOC inside an EAP authentication. https://datatracker.ietf.org/doc/draft-ingles-eap-edhoc/ We have been discussing internally about a resumption mechanism. A simple way to define this is doing it in the context of EAP-EDHOC by using Appendix J EDHOC-KeyUpdate. Having said this, I think it would be worth considering an EDHOC rekey exchange (i.e. involving 1 RTT), as something similar as, for example, IKEv2 does. This has the advantage that can be used in contexts different than EAP-EDHOC. Thus, it is not clear whether we should design this in the context of EAP-EDHOC or, on the contrary, LAKE WG could discuss this in the future. In my humble opinion, discussing this in LAKE WG could allow defining this EDHOC rekey protocol in such a way that could be used in different uses cases as a generic contribution, not just in EAP-EDHOC. I would be willing to discuss (and contribute) if LAKE WG is in favor of considering this in the future. Best Regards. ------------------------------------------------------- Rafa Marin-Lopez, PhD Dept. Information and Communications Engineering (DIIC) Faculty of Computer Science-University of Murcia 30100 Murcia - Spain Telf: +34868888501 Fax: +34868884151 e-mail: r...@um.es<mailto:r...@um.es> -------------------------------------------------------
_______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
