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

Hi Christian:

Thank you for comments. See our comments inline.

> El 16 ago 2021, a las 16:52, Christian Amsüss <christian@amsuess.com> escribió:
> 
> 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)?

What you mentioned was something we already considered but we do not see how it would solve the problem. Let me explain. According to OSCORE RFC , Section 8.2 - step 2:

"If either the
       decompression or the COSE message fails to decode, or the server
       fails to retrieve a Recipient Context with Recipient ID
       corresponding to the 'kid' parameter received, then the server
       SHALL stop processing the request.”

What you mention solves step 2, however the step 5 says:

"If decryption fails, the server MUST stop processing the
          request and MAY respond with a 4.00 (Bad Request) error
          message."

However, the OSCORE context with Recipient ID does not have any Recipient key yet, correct?. To make this work, we believe this should happen.

1) The CoAP server should create an OSCORE context with ID but without any key material.

2) When the CoAP message contains the OSCORE ID that hits the OSCORE context without any key material, we would have to assume this is CoAP-EAP: the OSCORE implementation should not discard or give a fail for this coap message but "pass the control" to CoAP-EAP so that we send a altAccept to the EAP state machine so we get the MSK.

3) From the MSK, we derive the OSCORE key material for the OSCORE context with the corresponding ID and update the OSCORE context with this key material 

4) Verify that the received protected coap-message with OSCORE.

5) Then we can get the cleartext information.

For us, this seems a little odd and we do no think it is supported by OSCORE RFC, are we wrong?

Any comment is welcome.

Best Regards

P.D: Dan is processing your review of the I-D. Thank you very much.

> 
> (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
> _______________________________________________
> Ace mailing list
> Ace@ietf.org
> 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: +34868888501 Fax: +34868884151 e-mail: rafa@um.es
-------------------------------------------------------