Re: [Lake] [core] 🔔 Working Group Last Call (WGLC) of draft-ietf-core-oscore-edhoc-06

[John Mattsson <[e-mail]>]

> Then maybe "[on error], OSCORE key material MUST NOT be derived from the EDHOC exchange, let alone
> be used to protect the respone"?

That sounds good to me.

I think we should discuss this topic in LAKE. My view was that deriving keys after message_3 and sending an error after message_3 could both be done. A reason why you sometimes want to decouple authentication from key derivation and continuing the security protocol is that authentication might take a long time (request to some database, popup for the human user to click OK/Deny, etc). The EDHOC specification should be clear on what is allowed and not. If always waiting for authentication is preferred from an implementation perspective then maybe EDHOC should mandate that. The important part is that everybody agrees on what is possible and not.

Also, another comments why the EAD support discovery has to change is that supporting EAD is mandatory in EDHOC-19. All compliant servers need to support EAD1, EAD2, EAD3, EAD4 (if they support message_4).

John


From: Christian Amsüss <[e-mail]>
Date: Tuesday, 28 February 2023 at 12:59
To: John Mattsson <[e-mail]>, Carsten Bormann <[e-mail]>
Cc: [e-mail] <[e-mail]>, [e-mail] <[e-mail]>
Subject: Re: [core] [Lake] 🔔 Working Group Last Call (WGLC) of draft-ietf-core-oscore-edhoc-06
On 28 February 2023 12:54:02 CET, John Mattsson <[e-mail]> wrote:
> and then there are authentication errors (X.509 identity not authorized, X.509 cert expired, X.509 issuer not trusted, certificate revoked, database oflline, OCSP server offline, etc.).
5
Ok, I see where this comes from now.

Then maybe "[on error], OSCORE key material MUST NOT be derived from the EDHOC exchange, let alone be used to protect the respone"?

BR
c