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

[Christian Amsüss <[e-mail]>]

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