Subject: Re: [Ace] About securing last exchange CoAP-EAP ( and EAP state machine - RFC 4137)

From: Christian Amsüss <[email-masked]>
Date: Mon, 11 Oct 2021 12:09:40 +0200

Hello Rafa,

that's the mail I missed in our previous discussion -- and yes, it
largely describes already just what I think can work, see comments
below.

On Sat, Sep 04, 2021 at 09:19:35PM +0200, Rafa Marin-Lopez wrote:
> I think that is not possible because that would move the EAP peer
> state machine to a final state SUCCESS without any chance to withdraw. 

Does there need to be?

If a request arrives at an OSCORE context and the validation *fails*,
the most probable explanation is that someone got the key derivation
wrong -- no point in allowing another attempt.

Or, of course, an attacker has been listening, and either attempting to
guess a key (giving them several attempts is questionable) or trying to
disturb the negotiation (which they can already do more easily by
sending unsuccessful CoAP responses).

> However, the MSK required to create the OSCORE context, which allows
> deciphering the message, is not available yet (even though eapKeyData
> variable has content). The reason is that, according to EAP state
> machine (RFC 4137) Figure 3, the MSK becomes available
> (eapKeyAvailable = TRUE) when EAP success (rxSuccess or altSuccess
> from the EAP lower layer) is sent to EAP state machine.

The OSCORE context can be partially initialized, or updated over its
lifetime. This is odd if you think of the context as a Recipient ID to
key mapping, but that's not generally the case in OSCORE, and the
construction of its RFC8613 B.2 also depends on data about requests
being fed "live" into the key derivation before the actual key is there.

With agreed-on recipient IDs[1], what happens as the "last" message EAP
is involved in can be this:

* OSCORE message is received
* OSCORE library looks into OSCORE option, finds an ID placed there by
  EAP
* OSCORE library asks EAP for key material for that ID (this is a
  callback, not a dictionary lookup)
* EAP sees that and declares altSuccess based on the receiption of the
  message alone, and then extracts the key material from the state
  machine
* EAP returns the context key material to the OSCORE library
* Message is decrypted

That message does not even need to go up to the EAP resource any more --
it's just as fine if that is already usable data. (If there is no
request pending and you prefer to have such a message just to clean out
the EAP state even though it has no timeouts, any encrypted message
would do, including a POST to the EAP resource).

BR
c

[1]: https://mailarchive.ietf.org/arch/msg/core/AK8Wxy64tXofocdRHm5HNew8dpE/

-- 
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom

---

From: Christian Amsüss <[email-masked]>
Date: Mon, 11 Oct 2021 12:16:04 +0200

Hi,

sorry for spreading this out over the sub-threads[1], just to get the
pointers right and everything addressed:

On Fri, Sep 03, 2021 at 08:32:59PM +0200, Rafa Marin-Lopez wrote:
> 2) When the CoAP message contains the OSCORE ID that hits the OSCORE
>   context without any key material, we would have to assume this is
>   CoAP-EAP: the OSCORE implementation should not discard or give a
>   fail for this coap message but "pass the control" to CoAP-EAP so
>   that we send a altAccept to the EAP state machine so we get the MSK.

It's not because the context is without key material -- it's because
that context was created by EAP and that software component, rather than
giving a key, gave a "callback" (however it's precisely implemented)
that tells the OSCORE context to rather ask for a key with metadata from
the last message.

(OSCORE appendix B.2 needs something similar to implement, so this
shouldn't be new to OSCORE implementations).

> 3) From the MSK, we derive the OSCORE key material for the OSCORE
>   context with the corresponding ID and update the OSCORE context with
>   this key material 

The key IDs need to be preconfigured for this to work, see [2] -- but
that's best practice anyway.

BR
c

[1]: https://mailarchive.ietf.org/arch/msg/emu/nb8zGGDJ3d4fUaCW8QMkf6rkhVs/
[2]: https://mailarchive.ietf.org/arch/msg/core/AK8Wxy64tXofocdRHm5HNew8dpE/