Hi John: Thank you for continuing this discussion. Please see some quick thoughts/questions inline.
> El 28 feb 2023, a las 17:15, John Mattsson > <john.mattsson=40ericsson....@dmarc.ietf.org> escribió: > > Hi, > > Let’s have some discussion based on the presentation at the interim. My view > is that the thing that would make sense to do in LAKE is to have a new method > 4 that can be used for both the initial handshake and for resumption, similar > to the PSK authentication in TLS 1.3. Btw, I was wondering if we should also add to this discussion the rekey, similarly to TLS1.3 KeyUpdate (which exchanges 2 messages). That is: -PSK authentication (method 4) -Resumption based on PSK (Method 0-3 and then to use a PSK) -Application rekey (by exchanging 2 messages). > > +-------------+--------------------+--------------------+ > | Method Type | Initiator | Responder | > | Value | Authentication Key | Authentication Key | > +=============+====================+====================+ > | 0 | Signature Key | Signature Key | > | 1 | Signature Key | Static DH Key | > | 2 | Static DH Key | Signature Key | > | 3 | Static DH Key | Static DH Key | > | 4 | PSK | PSK | > +-------------+--------------------+--------------------+ > > Aligning with LAKEs high security requirements I think the method should > provide > > - forward secrecy with respect to long-term keys > (ephemeral-ephemeral ECDH) > - Identity protection. > > Required changes (high-level) compared to method 3: > --------------------------------------------------------------- > > Initiator Responder > | METHOD, SUITES_I, G_X, C_I, EAD_1, ID_CRED_PSK | > +------------------------------------------------------------------>| > | message_1 | > | | > | G_Y, Enc( MAC_2, EAD_2 ), C_R | > |<------------------------------------------------------------------+ > | message_2 | > | | > | AEAD( MAC_3, EAD_3 ) | > +------------------------------------------------------------------>| > | message_3 | > | | > | AEAD( EAD_4 ) | > |<- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + > | message_4 | > > > - Add ID_CRED_PSK in message_1 > - Remove ID_CRED_R in message_2 and ID_CRED_I in message_3 > - The salt to derive PRK_2e is [TH_2, PSK] > - PRK_3e2m = PRK_4e3m = PRK_2e like in method 0; > - Derive resumption PSK = EDHOC_KDF( PRK_out, 11, h'', > hash_length ) Couldn’t we use AEAD in message_2? What was the problem identified in Fig. 5 in https://datatracker.ietf.org/doc/draft-ietf-lake-edhoc/00/? > > Discussion > --------------------------------------------------------------- > > There does not seem to be any reason to have more than one PSK. If the > initial method is 0-3 you need to derive one resumption PSK that can be used > many times. In the case of resumption, I was thinking if it would make sense to periodically running a full EDHOC authentication (method 0-3) to change the PSK and the ID_CRED_PSK value. In this case, an attacker would see a changing ID_CRED_PSK over time. In other words, the resumption PSK has a “lifetime”. During the lifetime, it is true the attacker would see the same ID-CRED-PSK (assuming several runs of EDHOC with the resumption PSK), but after, that the full EDHOC the PSK and the identity would change. > If the initial method is 4 (PSK) there seems to be no reason to derive a > resumption PSK. > Should message_1 contain a MAC or an AEAD? The only things that can be > encrypted are C_I and EAD_1. Stop an attacker to create new message_1 but an > attacker can still replay old message_1. Right, you cannot really authenticate the Initiator with protecting with integrity this message_1. As you mention, it could be a replay. > How to provide identity protecting, mitigate identification, and mitigate > tracking? Reusing a PSK identifier several times without it being encrypted > enables identification and tracking. I see several ways to achieve acceptable > privacy with symmetric crypto. What to do if things get out of sync? > Derive a new random PSK identifier in each EDHOC exchange. 64-bit would > definitely be enough. > PSK ID = EDHOC_KDF( PRK_out, 12, h'', 8 ) > If message_1 contains a MAC (or AEAD) the Responder can test several PSK. The > PSK Identifier can then be much smaller. Maybe 16, 24 or 32 bits. > The server sends a new PSK ID in message_2. This PSK ID can be much smaller > and the length can be chosen by the Responder. The con is that it increases > the size of message_2, but message_2 could still be 45 bytes if there is no > ID_CRED_R. > message_1 contains a MAC (or AEAD) and the Responder simply tests all PSK. > Symmtric operations are much cheaper that assymetric. Typically 2-3 orders of > magnitude. So testing 50 MACs is much cheaper than verifying a signature. (Btw, the Initiator must know somehow "the Responder’s identity" beforehand to select the proper ID_CRED_PSK) I was wondering if ID_CRED_PSK protection is a MUST. I mention this because , as far as I understand, for example, in TLS1.3, the client sends the list of identities in the ClientHello. And as you mentioned, we are trying to do something similar to PSK authentication in TLS1.3. In any case, for some identity tracking mitigation, perhaps it is better to include the new PSK ID in message 2 (I was checking EAP-AKA for the distribution of pseudonyms and fast re-authentication identities and it is the server which selects them.) My 0.02 cents. > I plan to ask for presentation time at IETF 116 to continue this discussion. > If there is interest in LAKE to do this I would be willing to drive a draft. > I think such a document can be relatively short and only describe differences > from method 0-3. > > Cheers, > John > -- > Lake mailing list > l...@ietf.org <mailto:l...@ietf.org> > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lake__;!!D9dNQwwGXtA!U-EjE64K_LPlaJaWNdPnbVCZ2pUBxHWYbRFC-jeAgZ1vNHhgGeKgrSyxX9iSm9CC61xYj539lcyVJ9IMcf7qJUk7pA$ ------------------------------------------------------ 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
