Requests in Transit Across a Key Update (e.g. sending messages during KUDOS execution)

[rikard-sics]

If you get a request, reply afterwards with the new key material (after KUDOS execution). Process request with CTX_OLD, and protect response with CTX_NEW.

If you get a response, process it with CTX_OLD.

[rikard-sics]

Similar problems as with the observation scenario above. This could happen if a request was sent and the response is received after rekeying with KUDOS has happened (where the response is using the new key material).

Sequence of events is:

• The client sends Req1, protected with the old key material and Partial IV X.
• The client and server run KUDOS and establish new key material.
• The client sends Req2, protected with the new key material and Partial IV X.
• The server responds to Req1, protecting the response with the new key material.

The response from the server would cryptograhically match both Req1 and Req2.

Possible solution:

• The client determines a time T as follows.
  • In the client-initiated version of KUDOS, T is the time right before sending Request 1.
  • In the server-initiated version of KUDOS, T is the time right before sending Request 2.
• At time T, the client has to ensure that there are no ongoing exchanges (i.e., requests pending the reception of a ACK or response), with the exception of ongoing observations.
• If there are any and running KUDOS is urgent, the client frees up the Token value(s) used for non-responded requests that are not Observation requests.

[rikard-sics]

Bring up during an interim?

[rikard-sics]

This should now be solved in section 4.3.1.1 Avoiding In-Transit Requests During a Key Update considering that we are forbidding running KUDOS when requests are in transit (having outstanding interactions).