Hi,
Here is a late response to this thread (see first mail at the end). On 2021-08-16, 16:52, "Ace on behalf of Christian Amsüss" <[email protected] on behalf of [email protected]> wrote: Hello, On Sat, Aug 14, 2021 at 01:37:06PM +0200, Dan Garcia Carrillo wrote: > As such, CoAP server (left side) could not see the content of the CoAP > message (message 7) without deciphering it. Moreover, as the URI-path is > also ciphered we cannot point to the right application to process the > message to achieve an alternate indication of success. If the recipient ID were available a bit earlier (and not derived from the MSK), would it then be viable to infer from the OSCORE ID that this is the last message, process an "EAP success", and start derivation just to extract the session lifetime (and thereby confirm the keys)? (That'd be all assuming that the "EAP success" contains really just the EAP success code and no further information, which would be "compressed" into the "some OSCORE is sent on this" information, and that the Session-Lifetime does not need to be known to advance the EAP state machine). [GS] If I understand right, MSK is not intended to be available from the EAP state machine until "EAP success" has been declared, which creates a problem to protect the message carrying the "EAP success" with MSK or key derived from it. Even if EAP success would only be integrity protected, there is still need to access the key to verify the integrity of the success message which is a catch 22. As far as I understand the two proposals (by the authors and by Christian) they are both opportunistic: preliminary declare success, get the MSK, derive the key, and attempt to verify the message. But it was not clear to me if success can be "withdrawn" or what happens if the message doesn't verify. Or conversely, if success can be declared opportunistically before access to MSK and without verification of message 7, then why not do that already before reception of message 7, and withdraw if it doesn't verify? Other alternatives: * If the mapping from EAP to CoAP client/server is instead reversed, then message 8 would be a CoAP request which can be protected by OSCORE using a key derived from MSK since it is by then available. This would add a message 9 (10% of the total no. of messages) for key confirmation in the other direction. * Alternatively, OSCORE may be started after EAP is concluded. This would add another message exchange but that exchange could be normal traffic and thus not add to the number of messages, if key confirmation can wait until there is traffic. An extra exchange for key confirmation can be added only in use cases it can't wait and there is no traffic, whatever those are. There is a similar setting in LAKE, where EDHOC has an optional message 4 if explicit key confirmation cannot be obtained otherwise. Göran From: Ace <[email protected]> on behalf of Dan Garcia Carrillo <[email protected]> Date: Saturday, 14 August 2021 at 13:37 To: EMU WG <[email protected]>, "[email protected]" <[email protected]> Cc: "[email protected]" <[email protected]> Subject: [Ace] About securing last exchange CoAP-EAP Dear ACE and EMU WG members, In the last exchange of CoAP-EAP we intended to run OSCORE to achieve key confirmation, a protected EAP success and the establishment of the OSCORE security association. It was our understanding that only integrity protection was possible but it is not the case after consulting OSCORE authors. More specifically, the payload and URI-Path with OSCORE are class E they are ciphered (and integrity protected) and, as far as we understand, there is no option, currently, of using a NULL encryption suite to achieve only integrity. CoAP CoAP Sever Client ... 5) |<----------------------------------------| | ACK [0x9869] | | Token (0xac) | | 2.01 Created Location-Path [/a/z] | MSK | Payload EAP-X-Resp (n) | | 6) |---------------------------------------->| v | CON [0x7811] POST /a/z |OSCORE | Token (0xac), OSCORE |CONTEXT MSK | Payload (EAP success||Session-Lifetime) |(*) | 7) |<----------------------------------------| v | ACK [0x7811] | OSCORE (*)| Token (0xac), OSCORE | CONTEXT 8) |---------------------------------------->| (*) Protected with OSCORE As such, CoAP server (left side) could not see the content of the CoAP message (message 7) without deciphering it. Moreover, as the URI-path is also ciphered we cannot point to the right application to process the message to achieve an alternate indication of success. 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. rxSuccess && (reqId == lastId) && (decision != FAIL) | V __________________________ |______SUCCESS_____________| |if (eapKeyData != NONE) | | eapKeyAvailable = TRUE | |eapSuccess = TRUE | |__________________________| ^ | (altAccept && decision != FAIL) || (idleWhile == 0 && decision == UNCOND_SUCC) Our proposed solution is to generate an authentication tag in the form of a COSE object that will be used to integrity-protect the payload of message 7 and message 8, allowing the EAP peer to see the EAP success and sending it to the EAP state machine so that, after obtaining the MSK, verifying the authentication tag in message 7 (key confirmation). After message 7 is processed correctly, CoAP server will be able to generate the OSCORE security context and after processing message 8 CoAP client (right entity in the exchange) will create the OSCORE context. From this point CoAP messages between both entities can be protected using OSCORE context. CoAP CoAP Sever Client 5) |<----------------------------------------| | ACK [0x9869] | | Token (0xac) | | 2.01 Created Location-Path [/a/z] | | Payload EAP-X-Resp (n) | 6) |---------------------------------------->| | CON [0x7811] POST /a/z | | Token (0xac) | MSK | Payload (EAP success||Session-Lifetime | | | MSK | || AuthenticationTag) | v | | | 7) |<----------------------------------------|AUTH_KEY| | v | ACK [0x7811] | | |AUTH_KEY | 2.01 Created Location-Path [/a/z1] | | v | Token (0xac) | | OSCORE Context| Payload(AuthenticationTag) | V 8) |---------------------------------------->| OSCORE Context
_______________________________________________ Emu mailing list [email protected] https://www.ietf.org/mailman/listinfo/emu
