Subject: [Ace] About securing last exchange CoAP-EAP

From: Dan Garcia Carrillo <[email-masked]>
Date: Sat, 14 Aug 2021 13:37:06 +0200

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.

---

From: Christian Amsüss <[email-masked]>
Date: Mon, 16 Aug 2021 16:52:03 +0200

Hello,

On Sat, Aug 14, 2021 at 01:37:06PM +0200, Dan Garcia Carrillo wrote:
> 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).

BR
c

-- 
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom

---

From: Göran Selander <[email-masked]>
Date: Thu, 26 Aug 2021 10:12:30 +0000

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-masked] on behalf of [email-masked]> wrote:

    Hello,

    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-masked]> on behalf of Dan Garcia Carrillo <[email-masked]>

Date: Saturday, 14 August 2021 at 13:37

To: EMU WG <[email-masked]>, "[email-masked]" <[email-masked]>

Cc: "[email-masked]" <[email-masked]>

Subject: [Ace] About securing last exchange CoAP-EAP

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

                               ...

              | ACK [0x9869]                            |

              | Token (0xac)                            |

     v        | ACK [0x7811]                            |

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

|eapSuccess = TRUE         |

             ^

             |

    (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

              | ACK [0x9869]                            |

              | Token (0xac)                            |

              |                          Token (0xac)   |      MSK

  | v         | ACK [0x7811]                            |        |

  v           | Token (0xac)                            |        |

                                                               Context