Re: [Emu] [Ace] About securing last exchange CoAP-EAP ( and EAP state machine - RFC 4137)

[Rafa Marin-Lopez <[e-mail]>]

Hi Göran:

Thanks for your comments. Please see ours inline

> El 26 ago 2021, a las 12:12, Göran Selander <goran.selander=[e-mail]> escribió:
> 
> 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" <[e-mail] <mailto:[e-mail]> on behalf of [e-mail] <mailto:[e-mail]>> 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.

In reality, the problem is not protecting message 7 (in fact, the EAP authenticator can protect it) but the EAP peer (CoAP server) is not able to verify the protected message 7 with OSCORE. 

To be more specific. The EAP state machine (RFC 4137), in particular, the EAP peer state machine (Figure 3), defines two variables that constitute part of the interface with the EAP lower-layer (which is CoAP-EAP). One variable is eapKeyData and the other eapKeyAvailable. It turns out that eapKeyData changes from NONE to the key value in state METHOD when the EAP method exports a key, which means the MSK is set in eapKeyData. However, only in the SUCCESS state, the eapKeyAvailable variable is set to TRUE, indicating to the EAP lower-layer that there is a key available. The SUCCESS state is reached when receiving, for example, an EAP success or for example there is an indication of the EAP  lower-layer (altAccept). However, and here it is the problem, the EAP peer needs the key to process/decrypt message 7 and the eapKeyAvailable is FALSE because EAP peer state machine is not in SUCCESS state.

Having said this, it seems that nothing precludes that an EAP lower-layer can check the state of eapKeyData to see if eapKeyData != NONE and to access key even though eapKeyAvailable is still FALSE. In fact, eapKeyAvailable is set TRUE when the SUCCESS state is reached by verifying precisely if eapKeyData != NONE. As an example, wpa_supplicant has a function to recover this key:

const u8 * eap_get_eapKeyData(struct eap_sm *sm, size_t *len)
{
	if (sm == NULL || sm->eapKeyData == NULL) {
		*len = 0;
		return NULL;
	}

	*len = sm->eapKeyDataLen;
	return sm->eapKeyData;
}

which is checking if eapKeyData is not NULL (NONE) to return the key. There is no other verification. And the function is well programmed according to the RFC 4137, in our opinion.

Therefore, the EAP lower-layer could access the MSK by looking at the eapKeyData variable. If the EAP lower-layer accesses the eapKeyData, it can create the OSCORE context with the single goal of decrypting message 7 without the need of an opportunistic success. In fact, the state machine is not yet moved to SUCCESS state when accessing eapKeyData. If message 7 protected with OSCORE is verified correctly, it means the counterpart (EAP authenticator) already has the MSK, and it could be considered as AltAccept, which will move the EAP peer state machine to the final state. If, for some reason (though we are not able to find out one), the EAP peer ends up in the FAILURE state, the EAP peer can get rid of the OSCORE context and report an error to the EAP authenticator.

In this sense, we have a question for the EMU WG: 

Would be a problem, taking into account RFC 4137, if an EAP lower-layer access the eapKeyData value (if eapKeyData changes from NONE to a value) for (only) decrypting information sent by the EAP authenticator before reaching the SUCCESS state? Apparently, it would be for the definition of eapKeyAvailable, although we do not see any impediment taking into account the eapKeyData is exposed in the current EAP peer state machine. If this option is considered an acceptable behavior, the problem is solved. 

>  
> 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.

In the option we described above, it would not be opportunistic because there is no declaration of success until message 7 is processed correctly (including OSCORE)
>  
> 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?

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. 

>  
> 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.

If we change the role, the EAP responses go inside the CoAP requests that complicates the design. Moreover, we have the reasons mentioned in the I-D (section 5.3)

>  
> * 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.

Yes, we have considered this case as well. As we see it, key confirmation cannot wait. So it becomes mandatory. Without that step, the EAP peer will not know the access has been granted. Therefore, under CoAP-EAP standpoint, running OSCORE after EAP would be required (which means that two additional messages are included in the design anyway). It is true the exchange could be also used to send traffic. The advantage of this approach is that OSCORE can be used and the design may be more simple. The disadvantage is that we are adding two additional messages, which is not good if we consider constrained links. 

Btw, two other options would be also possible:

1) To add a new cryptosuite to OSCORE to support NULL encryption + integrity 
2) Or to create an authentication tag based on COSE but acting only at payload level. We would achieve key confirmation in message 7 and 8 without using OSCORE, and after that OSCORE core context can be created safely for posterior exchanges. But under CoAP-EAP standpoint the process has finished.

We tend to think option 2), as Dan mentioned, would meet all we want : access to the MSK as expected in the EAP state machine (SUCCESS state); key confirmation; reducing the number of messages; and creating the OSCORE context safely afterwards. The only “problem” we see is that we are not using OSCORE in message 7 and 8 but COSE with integrity for (only) the payload. Opinions?

Best Regards.

>  
>  
> Göran
>  
>  
>  
>  
> From: Ace <[e-mail] <mailto:[e-mail]>> on behalf of Dan Garcia Carrillo <[e-mail] <mailto:[e-mail]>>
> Date: Saturday, 14 August 2021 at 13:37
> To: EMU WG <[e-mail] <mailto:[e-mail]>>, "[e-mail] <mailto:[e-mail]>" <[e-mail] <mailto:[e-mail]>>
> Cc: "[e-mail] <mailto:[e-mail]>" <[e-mail] <mailto:[e-mail]>>
> 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
>  
> _______________________________________________
> Ace mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/ace <https://www.ietf.org/mailman/listinfo/ace>
------------------------------------------------------- 
Rafa Marin-Lopez, PhD
Dept. Information and Communications Engineering (DIIC)
Faculty of Computer Science-University of Murcia
30100 Murcia - Spain
Telf: [phone] Fax: [phone] e-mail: [e-mail]
-------------------------------------------------------