Hi John: > El 26 ene 2023, a las 0:25, John Mattsson > <john.mattsson=40ericsson....@dmarc.ietf.org> escribió: > > 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,
Correct. Thanks for the summary. Those are the main reason of providing resumption. > > I think there are four ways to do this > > - 1) EHDHOC is lightweight enough. Just redo full EDHOC. (similar to full > handshake in TLS) Yes, we have always this option. > - 2) Use PSK with ECDHE (similar to psk_dhe_ke in TLS) Let me also add here, as a reference, IKEv2. Basically, section 1.3.2 in RFC 7296 shows a 1-RTT exchange including DH exchange and nonces to regenerate the IKE security association. > - 3) Use PSK with exchanged random values (similar to psk_ke in TLS) Curiously, when IKEv2 tries to generate key material for the IPsec security associations (and not for the IKEv2 SA) allows just sending nonces (see section 1.3.3 in RFC 7296), though there is also the possibility to include a DH exchange. I mention this because EDHOC can be used to regenerate OSCORE contexts. > - 4) Derive from PSK without new radnomness (similar to key update in TLS) Yes. > > I don't think 4) is needed. No good in terms of security > 2) or 3) provides nice optimizations. I agree. > 2) provides significantly better security than 3) Indeed > KUDOS in CORE WG alrady provides 3) when EHDOC is used to key OSCORE. We should take into account that OSCORE might no be used in certain uses cases, such as EAP-EDHOC. > > 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. Not sure if we need 3 flights but only 2 flights 1-RTT > > 3) would be ok to use for a short while, but then the recommendation would > have to be to rerun 1). That is precisely what IKEv2 does. But moreover, IKEv2 allows flexibility between 2) and 3), which is something might be considered also here. > 2) you can rerun for a much longer time. This implies ECDH key generation each time > All things considered 2) might therefore be more lightweight than 3). Not sure about this. It might depend on the number of exchanges with 3) you allow before running 1) VS constantly running 2). This can be controlled with two lifetimes: “reauth" lifetime ( after the expiration you should run 1)) and rekey time where you should run 3) after the expiration. > > 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. Correct. > 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 Also possible, yes. Best Regards and thanks for your feedback. > > 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/ > <https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ingles-eap-edhoc/__;!!D9dNQwwGXtA!QEvNWG8GBAZkd9-alz_icUnIYUrnlVg5c9hdyzvwXRnc61EmxClQ2wipFz7khv254AK9ZwA-UKmhX2tupcWjZpIoJQ$> > > 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> > ------------------------------------------------------- > > > > > -- > Lake mailing list > l...@ietf.org <mailto:l...@ietf.org> > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lake__;!!D9dNQwwGXtA!QEvNWG8GBAZkd9-alz_icUnIYUrnlVg5c9hdyzvwXRnc61EmxClQ2wipFz7khv254AK9ZwA-UKmhX2tupcXLaq_q4g$ > > <https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lake__;!!D9dNQwwGXtA!QEvNWG8GBAZkd9-alz_icUnIYUrnlVg5c9hdyzvwXRnc61EmxClQ2wipFz7khv254AK9ZwA-UKmhX2tupcXLaq_q4g$> ------------------------------------------------------ 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 -------------------------------------------------------
_______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
