[Lake] Re: Inria Paris Hackathon. EDHOC Rekeying discussion.

[Göran Selander <[e-mail]>]

Hi,

I looked through the key schedule, looks overall good to me, just a few proposed changes.

With the analogy of method 2, PSK maps to the secret of the Initiator, which appears in the key derivation as CRED_I and the secret used by I to compute G_IY.

EDHOC relies on COSE for identification of credentials. Let us use the term CRED_PSK for the COSE object containing the PSK. One example of CRED_PSK is a CWT Claims Set with a cnf claim containing a COSE_key object with the PSK.

Now completing the analogy:

> OLD: context_3 = << ID_CRED_I,   TH_3, CRED_I, ? EAD_3 >>
> NEW: context_3 = << ID_CRED_PSK, TH_3 >>
NEW2: context_3 = << ID_CRED_PSK, TH_3, CRED_PSK >>

(Note that CRED_PSK is known since there are separate decryption keys used for the two ciphertexts of message_3)
> OLD: PRK_4e3m = EDHOC_Extract( SALT_4e3m, G_IY )
> NEW: PRK_4e3m = EDHOC_Extract( SALT_4e3m, PSK )

NEW2: PRK_4e3m = EDHOC_Extract( SALT_4e3m, CRED_PSK )

(This is just avoiding different representations of PSK. Happy for input if there are any disadvantages of this.)

> OLD: TH_4 = H(TH_3, PLAINTEXT_3, CRED_I)
> NEW: TH_4 = H(TH_3, ID_CRED_PSK, ? EAD_3 )

NEW2: TH_4 = H(TH_3, ID_CRED_PSK, ? EAD_3, CRED_PSK )

For the last one, CRED_PSK may be redundant, since it is included in the derivations or PRK_4e3m, from which all keying material using TH_4 is derived. So I’m happy with either NEW or NEW2 in that case.

Göran

From: John Mattsson <john.mattsson=[e-mail]>
Date: Friday, 24 May 2024 at 17:19
To: [e-mail] <[e-mail]>
Subject: [Lake] Re: Inria Paris Hackathon. EDHOC Rekeying discussion.
Hi,

I made a quick first sketch of how the key derivation would/could work in Approach B. It would be quite similar to method 2 (Responder authenticates with signature, Initiator with Static DH). The only changes concern message_3. (Take these suggestions with a pinch of salt as I made them quite quickly, there might be errors).

KEYSTREAM_3 used to encrypt ID_CRED_PSK could be almost identical to K_3
OLD: K_3           = EDHOC_KDF( PRK_3e2m, 3,   TH_3, key_length )
NEW: KEYSTREAM_3   = EDHOC_KDF( PRK_3e2m, TBD, TH_3, ID_CRED_PSK_length )

OLD: TH_3 = H(TH_2, PLAINTEXT_2, CRED_R)
NEW: TH_3 = H(TH_2, PLAINTEXT_2)

The AEAD key in message 3 would be similar to MAC_3 but would require an IV.
OLD: MAC_3         = EDHOC_KDF( PRK_4e3m, 6,   context_3, mac_length_3 )
NEW: K_3           = EDHOC_KDF( PRK_4e3m, TBD, context_3, key_length )
OLD: IV_3          = EDHOC_KDF( PRK_3e2m, 4,   TH_3,      iv_length )
NEW: IV_3          = EDHOC_KDF( PRK_4e3m, TBD, context_3, iv_length )

OLD: context_3 = << ID_CRED_I,   TH_3, CRED_I, ? EAD_3 >>
NEW: context_3 = << ID_CRED_PSK, TH_3 >>

(EAD_3 is protected by the being included in the plaintext)
OLD: PRK_4e3m = EDHOC_Extract( SALT_4e3m, G_IY )
NEW: PRK_4e3m = EDHOC_Extract( SALT_4e3m, PSK )

OLD: TH_4 = H(TH_3, PLAINTEXT_3, CRED_I)
NEW: TH_4 = H(TH_3, ID_CRED_PSK, ? EAD_3 )

   Initiator                                                   Responder
   |                 METHOD, SUITES_I, G_X, C_I, EAD_1                 |
   +------------------------------------------------------------------>|
   |                             message_1                             |
   |                                                                   |
   |                       G_Y, Enc( C_R, EAD_2 )                      |
   |<------------------------------------------------------------------+
   |                             message_2                             |
   |                                                                   |
   |                 Enc( ID_CRED_PSK ), AEAD( EAD_3 )                 |
   +------------------------------------------------------------------>|
   |                             message_3                             |
   |                                                                   |
   |                           AEAD( EAD_4 )                           |
   |<- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
   |                             message_4                             |

Cheers,
John Preuß Mattsson


From: John Mattsson <[e-mail]>
Date: Friday, 24 May 2024 at 17:16
To: Michael Richardson <[e-mail]>, Elsa Lopez perez <[e-mail]>
Cc: [e-mail] <[e-mail]>
Subject: Re: [Lake] Re: Inria Paris Hackathon. EDHOC Rekeying discussion.
Michael Richardson wrote:
>I thought that we had a rekey mechanism inside OSCORE for this kind of thing?

The rekey mechanisms in OSCORE does not have especially good security properties as they do not include ephemeral Diffie-Hellman. This might be ok in very constrained use cases but in EAP-EDHOC you probably expect more. For TLS 1.3, BSI is recommending to phase out psk_ke and some implementations does not support it due to its questionable security.

Elsa wrote:
>Now, what I do not understand is why do we then use a MAC_3 in the current version of EDHOC in message_3, if we are as well using >an AEAD?
>Wouldn’t the tag be enough to authenticate the Initiator instead of MAC_3?

I think you can do that and if I remember correctly an earlier version of EDHOC relied completely on AEAD and skipped MACs. One reason we did not do that in message 2 was that ENC(SIGN(MAC())) requires less bytes on the wire than AEAD(SIGN()).

Elsa wrote:
>If you replace message_4 with OSCORE message, can you still authenticate the Responder? How would you do it with an OSCORE message?
Cryptographically there is very little difference between an EDHOC message_4 containing an AEAD and an OSCORE message containing an AEAD.
Cheers,
John


From: Michael Richardson <[e-mail]>
Date: Friday, 24 May 2024 at 17:02
To: Göran Selander <[e-mail]>
Cc: [e-mail] <[e-mail]>
Subject: [Lake] Re: Inria Paris Hackathon. EDHOC Rekeying discussion.

Göran Selander <[e-mail]> wrote:
    > One use case is update of session keys with good security properties at
    > less computational cost than re-running with public authentication
    > keys.

I thought that we had a rekey mechanism inside OSCORE for this kind of thing?


--
Michael Richardson <[e-mail]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide