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
signature.asc
Description: PGP signature
_______________________________________________ Emu mailing list [email protected] https://www.ietf.org/mailman/listinfo/emu
