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