EDHOC fuzzing - 2023-01-31

# EDHOC fuzzing - 2023-01-31 [toc] The following information was specified in a PDF file attached to the mail "Re: Regarding our discussion about fuzzing of EDHOC" from Kostis on 2023-01-27 at 10:04. --- The project is available at https://github.com/rikard-sics/californium/tree/edhoc. The commit hash f994359a0bc04d62df5b3706a64ce857f1d3dfb7 identifies the version. A patch has been applied to the downloaded source code that provides additional functionality to the server and client implementations and allows for altering some parameters regarding the EDHOC exchange. For example, it allows to specify if the EDHOC exchange would include an EDHOC message_4 or not. This patch does not alter the logic of the implementation. In all of these experiments the client is the Initiator and the server is the Responder. Additionally, the implementations are treated as a black-box. ## Default Client Regarding the Default Client all were as expected. Only an EDHOC exchange is successfully completed and then the client terminates. ## Client side - Use of message_4 and OSCORE-protected exchange Regarding the Client with EDHOC requiring message 4 and one OSCORE message afterwards: 1 - Session not terminated after sending EDHOC error message leads to completed EDHOC exchange without receiving message 4 The client under learning (with the parameters set to require message 4, derive OSCORE context and exchange an OSCORE message afterwards) has sent the initial message 1, received the expected message 2 and sent back the message 3. Now the expected reply from the server is a message 4. Instead, if either a message 2 or a message 3 is the server’s reply then correctly an EDHOC error message is the response from the client. At this point the client should have terminated the EDHOC session, which does not in this case. This allows the EDHOC protocol to continue and regardless of the server’s response to the client’s error message, the client finishes the protocol, derives (or has already derived after receiving message 3) the OSCORE context and replies with an OSCORE-protected message. ### Comments 1. "regardless of the server’s response to the client’s error message, the client finishes the protocol" Can you be more specific? After the client sends the EDHOC error message, what is the reply from the server that is apparently making the client continue to execute EDHOC? Even if this kind of misbehavior occurs, it would have to be specifically message_4 in order for the client to continue and complete the EDHOC execution. 2. "the client finishes the protocol, derives (or has already derived after receiving message 3) the OSCORE context and replies with an OSCORE-protected message." The client sends EDHOC message_3, i.e., it does not receive it. 3. The event you describe is handled in lines 598-602 of ClientEdhocExecutor.java That is, after having sent EDHOC message_3, the client receives a response which is neither an EDHOC error message nor the expected EDHOC message_4. Then, per the decision to discontinue the protocol, the client moves to the section at lines 620-624. In particular, the client purges the EDHOC session, does not send an EDHOC error message [SIDE-NOTE], and shuts down the communication stack instance that it has used so far, before finally returning to the main application. After that, the client does not engage in any further communication. That is, back to lines 291-299 of EdhocClient.java, the overall failed EDHOC execution results in terminating the client process altogether. So I wonder how you could have observed the described behavior. Can you provide the debug output produced by the client and server, and a Wireshark trace? [SIDE-NOTE] The choice explained above about the client not sending an EDHOC error message is consistent with what occurs in lines 269-273 of ClientEdhocExecutor.java when, after having sent EDHOC message_1, the client receives as a reply a message which is neither EDHOC message_2 nor an EDHOC error message. This is also admitted by the specification. [Section 5.1 of the EDHOC Internet Draft version -18](https://datatracker.ietf.org/doc/html/draft-ietf-lake-edhoc-18#name-message-processing-outline): > The following steps are expected to be performed at reception of an EDHOC message: > > ... > > 3. If the message received is an error message, then process it according to Section 6, else process it as the expected next message according to the protocol state. > > If the processing fails for some reason then, typically, an error message is sent, the protocol is discontinued, and the protocol state erased. So I am choosing not to send an EDHOC error message upon receiving a totally unexpected (bogus) message, irrespective of it being an EDHOC message at all. Yet, I am discontinuing the protocol. Note that sending an EDHOC error message implies discontinuing the protocol, but the implication does not hold in the reverse direction. ## Server side - Use of message_4 Regarding the Default Server and the one when EDHOC message 4 is expected: 1 – Successfully processes EDHOC error message after the EDHOC exchange leading to previous OSCORE Context termination One successful EDHOC exchange has been completed and both peers have derived an OSCORE context, with which they may have already exchanged messages. If the server receives an EDHOC error message with the prepended connection identifier of the previoucly completed session, it does not reply anything back, but it seems to successfully process this error message. This stops (if not deleted or purges) the already derived OSCORE context from the previous session. In other words, the server is at a state with no active EDHOC sessions, but processes an EDHOC error message that contains no other specific information to the previous session, than the prepended connection identifier. Essentially this EDHOC error message makes the server to terminate the encrypted connection between the two peers. ### Comments First, a clarification about: > In other words, the server is at a state with no active EDHOC sessions, but processes an EDHOC error message that contains no other specific information to the previous session, than the prepended connection identifier. At the server, the EDHOC execution is completed after sending EDHOC message_4, but the EDHOC session persists, e.g., in order to possibly use it in the future to run EDHOC-KeyUpdate. Also, the connection identifier C_R prepended to the EDHOC error message is indeed the only and sufficient information element linking the EDHOC error message with the EDHOC session in question. Second, the behavior you describe is admitted by the specification. [Section 5.1 of the EDHOC Internet Draft version -18](https://datatracker.ietf.org/doc/html/draft-ietf-lake-edhoc-18#name-message-processing-outline) says: > EDHOC messages SHALL be processed according to the current protocol state. The following steps are expected to be performed at reception of an EDHOC message: > > ... > > If the message received is an error message, then process it according to Section 6. > > ... > > If the processing fails for some reason then, typically, an error message is sent, the protocol is discontinued, and the protocol state erased. After having successfully processed the last message (message_3 or message_4 depending on application profile) the protocol is completed, after which no error messages are sent and EDHOC session output MAY be maintained even if error messages are received. Further details are provided in the following subsections and in Section 6. In this particular case, the last message to use in the protocol is EDHOC message_4. This means that: * After sending EDHOC message_4, the server will not send an EDHOC error message. * After sending EDHOC message_4, if the server receives an EDHOC error message, the server MAY decide to preserve the derived application keying material, i.e., the OSCORE Security Context, or even also EDHOC prk_out. The Java implementation takes a conservative approach, by purging the EDHOC session and deleting the OSCORE Security Context. I read the sentence in the specification as this being the expected default approach, while a deviation from it is also admitted. Besides being conservative from a security point of view, this helps preserving (short, hence precious) EDHOC connection identifiers to be used as OSCORE Sender/Recipient IDs, which would otherwise risk to go wasted and not possible to use, as locked in potentially "zombie" OSCORE Security Contexts. Note that the EDHOC error message might have been legitimately sent by the client, following the reception of EDHOC message_4 and the failure in correctly processing it. Of course, the processing failure at the client might be the result of EDHOC message_4 being altered in transit by an adversary. Instead, the EDHOC error message might be crafted and injected by an adversary, even though the client successfully processed EDHOC message_4. This can be broken down into two different cases. * CASE 1: The adversary injects the EDHOC error message before the client and server complete a request-response exchage protected with OSCORE. Per the current implementation (again, as admitted by the specification), the server would delete the OSCORE Security Context. If later on, the EDHOC Initiator acts as CoAP client and sends an OSCORE-protected request to the EDHOC Responder, then the latter will reply with a 4.01 response due to a not found OSCORE Security Context. Eventually, this will just trigger a new execution of EDHOC altogether. If this is in turn imaginable as a DoS vector, I believe there are simpler and more effective way to attempt performing a DoS against the EDHOC Responder :-) * CASE 2: The adversary injects the EDHOC error message after the client and server complete a request-response exchage protected with OSCORE. The same as in CASE 1 applies here too. Admittedly, here it is a pity that the server deletes the OSCORE Security Context after it has succesfully been used in protected exchanges. This boils down to the fact that EDHOC error messages are not protected, hence forgeable. Addressing this corner case in a fine-grained manner would require EDHOC to gain knowledge of which application keying material has been successfully used after its derivation, in order to preserve it. However, this can be quite challenging if not practically impossible to achieve in a clean implementation, especially if EDHOC and OSCORE are provided by separate libraries. Of course, an implementation can handle the above in a different way, and have the server preserving the OSCORE Security Context (or even also EDHOC prk_out) when receiving an EDHOC error message after having sent EDHOC message_4. Bottom line, it is left to the discretion and permissiveness of the specific implementation, presumably in accordance with application policies. ## Server side - Use of message_4 2 – Minor detail: HelloWorldResource is a CoAP resource ### Comments Although that may seem weird, that's correct and consistent. This is acceptable for the goal of testing the EDHOC protocol, by means of admittedly toy resources to access through OSCORE-protected requests, after the EDHOC completion. It would be inconsistent if the resource would be advertised with the 'osc' target attribute in a link to it. In such a case, the REST handler at the server application must not process any received request that was not protected with OSCORE.