PSK Authentication EDHOC

Discuss PSK authentication method and resumption method (lightweight)
- Similar to what was done with PSK/resumption mechanism in TLS 1.3.
- External and internal PSK
The method should still provide ephemeral key exchange, identity protection and mitigate tracking and fingerprinting.
Benefits:
- 1 asymmetric operation compared to three in current methods.
- eliminates external things like fetching credentials from a database, revocation and path validation.

Key scheduling
- Add ID_PSK in message 1. Remove ID_CRED_R and ID_CRED_I in m2 and m3, respectively. Secure privacy properties when sending ID_PSK in clear in the first message? Proposal to encrypt it using G_XY.
- Add PSK to salt to derive PRK_2e (salt = [TH_2, PSK]).
- PRK_3e2m, PRK_4e3m and PRK_2e should be different. (MAC oracle Charlie Jacomme)
- Derive resumption PSK = EDHOC_KDF(PRK_out, 11, h'', h_len)

Discussion

Previous discussion slides:
- slides-116-lake-edhoc-rekeying-and-psk-authentication-00 (ietf.org)
- edhoc-rekey_v2 (ietf.org)
Do we need a fourth message? It might not be necessary for cryptographic reasons but EAP-EDHOC might need it. There are two main approaches:
- Approach A: Send PSK_ID in m1, similarly to how it is done in TLS 1.3.
  - m1: G_X, PSK_ID
  - m2: G_Y, MAC
  - m3: MAC
  - OSCORE
- Approach B: Send PSK_ID encrypted using the ephemeral shared secret G_XY. The benefit of this is that it protects the PSK identifier from passive attackers. Better privacy than approach A.
  - m1: G_X
  - m2: G_Y
  - m3: PSK_ID, MAC
  - OSCORE
  - m4: MAC

Key schedule

Approach A

Approach B