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
[email protected]
https://www.ietf.org/mailman/listinfo/emu
