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.
+-------------+--------------------+--------------------+ | 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 ) 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. 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. * 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. 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
_______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu