search

core-wg / oscore-key-update

Other
0 stars 0 forks source link

Further corner cases #27

Closed rikard-sics closed 1 year ago

rikard-sics commented 2 years ago

0: Don't send non-KUDOS messages while KUDOS running.

1: An outgoing non-KUDOS message is always protected with the most recent security context.

2: Client must be ready to receive responses protected with key material different than that used to protect the corresponding request. This is the case if KUDOS is ran in between a request a corresponding response. For client-initiated KUDOS this can happen where the responses are observe notifications. For the server-initiated version, this can happen if the client uses NSTART > 1 and one of the requests results to be a KUDOS trigger. While the other requests would be server later by the server (after KUDOS) is done.

3: "Stuck-party": This can happen when the server-initiated version of KUDOS is used. Client is client-only, and only sending NON requests (not expecting a response). In this case the client never listens for responses, and thus doesn't get (process) KUDOS message #1 from the server. So rekeying can never start. To avoid this deadlock we can say that every X messages should listen for a response, or be CON.

rikard-sics commented 2 years ago

Point 3 is done in: https://core-wg.github.io/oscore-key-update/draft-ietf-core-oscore-key-update.html#name-preventing-deadlock-situati

rikard-sics commented 1 year ago

Point 1 is done in this commit, and the already existing text in that paragraph: e255aa129aedeaa66473b0b40a8b913888b4bd1a

rikard-sics commented 1 year ago

Point 0 already done in existing text: https://core-wg.github.io/oscore-key-update/draft-ietf-core-oscore-key-update.html#section-3.3

Once a peer acting as initiator (responder) has sent (received) the first KUDOS message, that peer MUST NOT send a non KUDOS message to the other peer, until having completed the key update process on its side.