[Emu] About securing last exchange CoAP-EAP

[Dan Garcia Carrillo <[e-mail]>]

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.