feat: implementation of section 4.2 in RFC8613 (simple ACK not encrypted)

[mopsiok]

According to OSCORE, section 4.2, OSCORE encryption is only valid for request/response model. Simple ACK messages with no piggybacked response are on the lower communication layer (messaging layer), and must be sent unencrypted. Doing the opposite results in creating a CoAP packet with code=0.02 (request) and type=ACK, which is invalid in terms of CoAP RFC, section 4.2.

As the user may not be fully aware of this limitation, it probably should be handled inside the library. Technically this behavior is not an error, so the result of coap2oscore executed on small ACK packet would be OK, even though no encryption is performed. It is left this way also to provide backward compatibility.

[StefanHri]

Can you point me to the exact place in the text saying that ACK messages should be sent unencrypted?

"With one exception (see Section 4.1.3.5), the Outer Code SHALL be set to 0.02 (POST) for requests and to 2.04 (Changed) for responses."

I understand that if an ACK message with no payload is sent, the plaintext for encryption consists only of the original code field. The new code field must be set to changed 2.04. Did you experience that this is not the case?

[mopsiok]

Hello, thanks for your reply. My understanding is based on RFC8613 section 4.2:

"Most CoAP header fields (i.e., the message fields in the fixed 4-byte header) are required to be read and/or changed by CoAP proxies; thus, they cannot, in general, be protected end-to-end from one endpoint to the other. As mentioned in Section 1, OSCORE protects the CoAP request/response layer only and not the CoAP messaging layer (Section 2 of [RFC7252]), so fields such as Type and Message ID are not protected with OSCORE."

If I understand it correctly, an ACK message with no payload is not on the request/response layer, and should not be protected at all. Also, information about ACK is necessary for proxy devices and should not be excluded from the outer (encrypted) CoAP packet, which seems to be the exact thing that we observe in our system.

Doing the opposite creates an outer message that has code set to 0.02/2.04, and at the same time its type is ACK. And that is not a valid CoAP message at all, which is defined in RFC7252 section 4.2:

"The Acknowledgement message MUST echo the Message ID of the Confirmable message and MUST carry a response or be Empty (see Sections 5.2.1 and 5.2.2)."

and section 1.2: " Separate Response When a Confirmable message carrying a request is acknowledged with an Empty message (e.g., because the server doesn't have the answer right away), a Separate Response is sent in a separate message exchange (Section 5.2.2).

Empty Message A message with a Code of 0.00; neither a request nor a response. An Empty message only contains the 4-byte header."

From my understanding, when current solution is encrypting an empty ACK packet, it creates an invalid CoAP packet in return. I am happy to discuss it anyway.

Regards, Patryk

[StefanHri]

@gselander @emanjon

Hi Göran and John, can you help us with this question? Thanks!

[rikard-sics]

Hello. I have been working on integrating OSCORE into the Java Californium library. In that implementation the simple ACK is not encrypted.

The way I understand is that it comes down to the fact that the simple ACK is defined as an "Acknowledgement Message": https://datatracker.ietf.org/doc/html/rfc7252#section-1.2 And thus it is not an actual Request or Response. (In contrast a Piggybacked Response is considered a Response).

The processing steps for OSCORE should be applied to Requests and Responses so the simple ACK is therefore excluded. It also says the following: https://datatracker.ietf.org/doc/html/rfc8613#page-25

With one exception (see Section 4.1.3.5), the Outer Code SHALL be set to 0.02 (POST) for requests and to 2.04 (Changed) for responses.

So this changing of the code then applies to Requests and Responses only.