Update also Sender/Recipient ID during KUDOS execution

[rikard-sics]

Possible extension

[rikard-sics]

RH (p12): procedure to update OSCORE Sender/Recipient ID. It can be used stand-alone or embedded in a KUDOS execution. Not to use right after a reboot to avoid reuse of AEAD nonce. An exception is when OSCORE Appendix B.1 is used, and the node can restart from a safe SSN. CA: Might be easier to phrase in terms of "when having lost state", and being explicit about which state is lost (here it's probably the set of sender IDs ever used on this master secret)

Right ..., so, regardless a rebooting happened or not, it is really about having lost state. This procedure must not be used if the device does not remember to whole set of Sender/Recipient IDs used with the Master Secret of CTX_OLD. In such a case, the device has to first run KUDOS to update the Master Secret.

This opens for yet another consistency check to do when running this procedure as stand alone, regardless a rebooting happened or not. That is, a peer receiving an ID to use as its own Sender ID must abort the procedure if it has already used that ID as its own Sender ID under that Master Secret. Also it must offer its own Recipient ID only if this is not only available at the moment but also never used before under the current Master Secret. Practically, between two consecutive updates of Master Secret (e.g., through KUDOS), a device must keep track of the Sender/Recipient IDs used under that Master Secret.

[rikard-sics]

• From John, about possibly establishing also new Sender/Recipient IDs. Something to at least discuss. --- https://mailarchive.ietf.org/arch/msg/core/GXsKO4wKdt3RTZnQZxOzRdIG9QI/

And Christian suggests to actually use an inner option for that, adding more considerations on selecting new identifiers among the ones not used yet (hence it's easier to just do it in KUDOS) --- https://mailarchive.ietf.org/arch/msg/core/ClwcSF0BUVxDas8BpgT0WY1yQrY/ It's also even better if we want to admit this as happening not necessarily as part of a KUDOS execution.

General points:

• Like in EDHOC, each endpoint can specify its own new Recipient ID, i.e., the new Sender ID of the other peer.
• This update of Sender/Recipient IDs has to be optional to do.
• This can be embedded in a KUDOS execution or not (i.e., stand-alone).
• Both when embedded in KUDOS and when stand-alone, it has to be possible to be client- or server-initiated. When embedded in KUDOS, the initiator (responder) of this procedure is also the initiator (responder) of KUDOS.
• Updating the Sender/Recipient IDs practically triggers the derivation of a new security context, with everything it implies (e.g., on Sender Sequence Number and Replay Window).
• This procedure MUST not be used immediately following a reboot, to avoid reuse of AEAD nonces. Instead, KUDOS has to be used first (or something else, e.g., EDHOC).

To define:

• How to transport the new Recipient ID
• Where is it a good time to delete the old Sender/Recipient IDs (e.g., based on key confirmation)
• What about observations? Possible to preserve?
• Downgrading attack by blocking request with p = 0, and injecting fake 5.03 response

[rikard-sics]

How to transport the new IDs

Rationale: use a new dedicated CoAP option for both transport and signaling.

+------+---+---+---+---+-------------+--------+--------+---------+
| No.  | C | U | N | R | Name        | Format | Length | Default |
+------+---+---+---+---+-------------+--------+--------+---------+
|      |   |   |   |   |             |        |        |         |
| TBD1 |   |   |   |   | RecipientID | opaque |  0-7   | (none)  |
|      |   |   |   |   |             |        |        |         |
+------+---+---+---+---+-------------+--------+--------+---------+
           C=Critical, U=Unsafe, N=NoCacheKey, R=Repeatable

Proposed option number: 24 (00011000) (If we want it to be critical it can be number 13)

The content of the option is the offered new Recipient ID of the message sender. The peer offers a Recipient ID value which is, on its side, currently free under the ID Context used for the Security Context in question.

The option is of class E for OSCORE.

[rikard-sics]

This idea has now been added to the text of the draft.