• 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

Diagrams

Key schedule

https://docs.google.com/drawings/d/1CaSlUGdeJrfUj6GSp2Y6hRs69G60rnr_NOpW0ILP4x4/edit?usp=sharing

Approach A

https://docs.google.com/drawings/d/1fXr9CyR41A2-I5DCxHIdJvA1TpwNZqi8fxG5QWnTX4I/edit?usp=sharing

Approach B

https://docs.google.com/drawings/d/16pO7xMiU2ddMFHYZAozuqgMh-IcXbqVoi5k_Dx9Inxg/edit?usp=sharing