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

[John Mattsson <[e-mail]>]

Hi Rafael:

RFC 9528 is not "self complete" without a forth message as you then lack key commitment.
A typical way to use RFC 9528 EDHOC today is:

Fig 1:

   Initiator                                                   Responder
   +------------------------------------------------------------------>|
   |                             message_1                             |
   |<------------------------------------------------------------------+
   |                             message_2                             |
   +------------------------------------------------------------------>|
   |                             message_3                             |
   +------------------------------------------------------------------>|
   |                               OSCORE                              |
   |<------------------------------------------------------------------+
   |                               OSCORE                              |
   +------------------------------------------------------------------>|
   |                               OSCORE                              |
   |<------------------------------------------------------------------+
   |                               OSCORE                              |

You cannot use RFC 9528 EDHOC like this:

   Initiator                                                   Responder
   +------------------------------------------------------------------>|
   |                             message_1                             |
   |<------------------------------------------------------------------+
   |                             message_2                             |
   +------------------------------------------------------------------>|
   |                             message_3                             |
   +------------------------------------------------------------------>|
   |                               OSCORE                              |
   +------------------------------------------------------------------>|
   |                               OSCORE                              |
   +------------------------------------------------------------------>|
   |                               OSCORE                              |
   +------------------------------------------------------------------>|
   |                               OSCORE                              |
   +------------------------------------------------------------------>|

I don't think forcing message_4 in Fig 1. would make sense. If you use EDHOC "stand alone" then you MUST use message_4.

>if the OSCORE request goes from Initiator to the Responder, the Initiator will start to send the OSCORE request without authenticating the Responder.

Yes, I don't see a problem. You probably need to split authentication into smaller parts. The Initiator knows the Identity of the party with the PSK, which is the only party that can decrypt. You also get PFS and replay protection, i.e, much better security properties than 0-RTT in TLS 1.3 or anything protected with S/MIME. That the Initiator has not verified the aliveness of the other party having the PSK is not a problem for sending OSCORE.

Cheers,
John

From: RAFAEL MARIN LOPEZ <[e-mail]>
Date: Monday, 27 May 2024 at 07:16
To: John Mattsson <[e-mail]>
Cc: RAFAEL MARIN LOPEZ <[e-mail]>, [e-mail] <[e-mail]>
Subject: Re: [Lake] Inria Paris Hackathon. EDHOC Rekeying discussion.
Hi John:

If EDHOC message_4 is NOT sent, the Responder will not be authenticated after finishing EDHOC. We are relaying the Responder’s authentication to something  external to EDHOC. Would not it better to design EDHOC PSK self complete? In the current RFC, key confirmation might be delayed but the authentication of the parties is not. Moreover, my assumption is that OSCORE will not be performed in all uses cases. After all, EDHOC and OSCORE are separated things that can work standalone. Moreover, if the OSCORE request goes from Initiator to the Responder, the Initiator will start to send the OSCORE request without authenticating the Responder. I think it would be better to make message_4 mandatory in EDHOC PSK. What do you think?

Best Regards.


El 24 may 2024, a las 16:07, John Mattsson <john.mattsson=[e-mail]<mailto:john.mattsson=[e-mail]>> escribió:

Elsa wrote:
Why does C_R need to be encrypted?
John: A simple answer is that RFC 9528 does so and new modes should do the same unless they have strong reasons not to. A longer answer of why is that the security AD put a discuss on EDHOC and asked why C_R was not encrypted. EDHOC was then changed. Best practice today is to encrypt as much as possible. When used with CoAP, encrypting C_R does not provide much extra privacy but theoretically you could transport EDHOC over a protocol that does not need to send C_R in cleartext and then later start OSCORE on a separate MAC/IP address. In that case encrypting C_R improves security.
Elsa wrote:
Why is the MAC_3 not needed? Isn'i it needed for authentication?
Rafael wrote:
Assuming PSK is included somehow in the key used in the AEAD, correct?

John: Yes, assuming the PSK key is included in the derivation of the AEAD key, the tag in the AEAD ciphertex can be used for authentication.

Elsa wrote:
What is the difference between PSK_ID and IS_CRED_PSK?

John: ID_CRED_PSK aligns with RFC 9528. PSK_ID is not really defined. I think ID_CRED_PSK should be defined similar to ID_CRED_I and ID_CRED_R. I think ID_CRED_PSK like ID_CRED_I and ID_CRED_R should be a COSE header_map. Today this would be { 4 : kid } and be encoded as an CBOR integer. But I think it is good to allow new COSE header parameters identifying a PSK to be standardized in the future.
Elsa wrote:
I thought message_4 was needed for authentication in the approach B.
Rafael wrote:
Mmmm...I am not sure about this. In the flow Message 4 is still required to authenticate the Responder since Message 2 is NOT authenticating the Responder. Am I missing something?
John: I think the requirement is that a fourth message need to be sent. I think you can still replace EDHOC message_4 with an OSCORE message. The use of pre-shared keys changes quite a lot. This is no longer SIGMA. The Initiator already has the authentication key of the Responder it wants to talk to.
Cheers,
John Preuß Mattsson

From: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Date: Friday, 24 May 2024 at 11:19
To: John Mattsson <[e-mail]<mailto:[e-mail]>>, [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Subject: Re: [Lake] Re: Inria Paris Hackathon. EDHOC Rekeying discussion.
Hello John,

I have some questions regarding the message flow:

  1.  Why does C_R need to be encrypted?

  1.  Why is the MAC_3 not needed? Isn'i it needed for authentication?

  1.  What is the difference between PSK_ID and IS_CRED_PSK?

  1.  I thought message_4 was needed for authentication in the approach B.

Best,

Elsa

________________________________
From: John Mattsson <john.mattsson=[e-mail]<mailto:john.mattsson=[e-mail]>>
Sent: Friday, May 24, 2024 8:24 AM
To: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Subject: [Lake] Re: Inria Paris Hackathon. EDHOC Rekeying discussion.

Hi,

- I think it would be very good and simple if all EDHOC methods offer ephemeral key exchange and identity protection. That is what RFC 9528 is currently promising. The current modes in EHDOC already have better privacy properties than TLS 1.3 as reuse of ephemeral keys is forbidden. Rekeying has privacy problems if reuse of the identifier is allowed. And forbidding reuse leads to other problems.

- I think it would be good with a single method for both initial handshake and rekeying. I think approach B is good for both. For use cases sending application data, the application data can be done in parallel with message_3 as usual. In EAP-EDHOC that do not send application data message_4 is mandatory. Other implementations can continue to use OSCORE instead of EDHOC message_4 but the following sentence would have to be changed to SHALL

   The Initiator SHOULD NOT persistently
   store PRK_out or application keys until the Initiator has verified
   message_4 or a message protected with a derived application key, such
   as an OSCORE message

- In addition to rekeying, EDHOC with PSK authentication can be useful in existing systems where two nodes are given a PSK from other parties and would like to perform ephemeral Diffie-Hellman to get PFS and hinder the other parties to eavesdrop unless they are active on-path attackers during the whole communication. Examples could be GBA and AKMA in mobile systems or Peer and Authenticator in EAP.

I looked a little bit more into details of Elsa's Approach B figure.
- C_R should be encrypted.
- I don't think a separate MAC_3 is needed. The tag in AEAD( EAD_3 ) is enough.
- The PSK identity should be before AEAD( EAD_3 )
- I think it is best to turn PSK_ID into ID_CRED_PSK to align with the other methods. It should be a COSE header with the same encoding rules.
- message_4 should still be dashed as it can be replaced with OSCORE.


   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                             |


(From an authentication point of view, approach B is how PSK authentication works in TLS 1.2)

Cheers,
John Preuß Mattsson
--
Lake mailing list -- [e-mail]<mailto:[e-mail]>
To unsubscribe send an email to [e-mail]<mailto:[e-mail]>

Dr. RAFAEL MARÍN LÓPEZ

Assistant Professor
Dept. Ingeniería de la Información y las Comunicaciones
[e-mail]<mailto:[e-mail]>
T ([phone]

[Image removed by sender. logo UMU]<https://www.um.es/>
[Image removed by sender. logo euniwell]<https://www.euniwell.eu/>
[Image removed by sender. logo hr]<https://www.um.es/web/hrs4r>
[Image removed by sender. logo CMN]<https://www.campusmarenostrum.es/>