Identifier Update for OSCORE
draft-ietf-core-oscore-id-update-00
| Document | Type | Active Internet-Draft (core WG) | |
|---|---|---|---|
| Authors | Rikard Höglund , Marco Tiloca | ||
| Last updated | 2024-03-05 | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Additional resources | Mailing list discussion | ||
| Stream | WG state | WG Document | |
| Document shepherd | (None) | ||
| IESG | IESG state | I-D Exists | |
| Consensus boilerplate | Unknown | ||
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-ietf-core-oscore-id-update-00
#x27; field of the OSCORE Option. Then, the server decrypts and verifies the response by using CTX_B. Finally, the server prepares a CoAP response, protects it with CTX_B, and sends it to the client as Response #3. Upon receiving the OSCORE message Response #3, the client decrypts and verifies it with the OSCORE Security Context CTX_B. In case of successful verification, the client confirms that the server is aligned with the new OSCORE Sender/Recipient IDs, and thus discards the OSCORE Security Context CTX_A. After that, one further exchange occurs, where both the CoAP request and the CoAP response are protected with the OSCORE Security Context CTX_B. In particular, upon receiving, decrypting, and successfully verifying the OSCORE message Request #4, the server confirms that the client is aligned with the new OSCORE Sender/Recipient IDs, and thus discards the OSCORE Security Context CTX_A. 2.1.3. Additional Actions for Execution After having experienced a loss of state, a peer MUST NOT participate in a stand-alone OSCORE ID update procedure with another peer, until having performed a full-fledged establishment/renewal of an OSCORE Security Context with the other peer (e.g., by running KUDOS [I-D.ietf-core-oscore-key-update] or the authenticated key establishment protocol EDHOC [I-D.ietf-lake-edhoc]). More precisely, a peer has experienced a loss of state if it cannot access the latest snapshot of the latest OSCORE Security Context CTX_OLD or the whole set of OSCORE Sender/Recipient IDs that have been used with the triplet (Master Secret, Master Salt, ID Context) of CTX_OLD. This can happen, for instance, after a device reboots. Höglund & Tiloca Expires 5 September 2024 [Page 15] Internet-Draft Identifier Update for OSCORE March 2024 Furthermore, when participating in a stand-alone OSCORE ID update procedure, a peer performs the following additional steps. * When a peer sends an ID update message, the value of the Recipient-ID Option that the peer specifies as its new intended OSCORE Recipient ID MUST fulfill both the following conditions: it is currently available as Recipient ID to use for the peer (see Section 3.3 of [RFC8613]); and the peer has never used it as Recipient ID with the current triplet (Master Secret, Master Salt, ID Context). * When receiving an ID update message, the peer MUST abort the procedure if it has already used the identifier specified in the Recipient-ID Option as its own Sender ID with the current triplet (Master Secret, Master Salt, ID Context). In order to fulfill the conditions above, a peer has to keep track of the OSCORE Sender/Recipient IDs that it has used with the current triplet (Master Secret, Master Salt, ID Context) since the latest update of the OSCORE Master Secret (e.g., performed by running KUDOS). 2.2. Preserving Observations Across ID Updates When running the OSCORE ID update procedure stand-alone or integrated in an execution of KUDOS, the following holds if Observe [RFC7641] is supported, in order to preserve ongoing observations beyond a change of OSCORE identifiers. * If a peer intends to keep active beyond an update of its Sender ID the observations where it is acting as CoAP client, then the peer: - MUST store the value of the 'kid' parameter from the original Observe requests, and retain it for the whole duration of the observations, throughout which the client MUST NOT update the stored value associated with the corresponding Observe registration request; and - MUST use the stored value of the 'kid' parameter from the original Observe registration request as value for the 'request_kid' parameter in the external_aad structure (see Section 5.4 of [RFC8613]), when verifying notifications for that observation as per Section 8.4.2 of [RFC8613]. * If a peer is acting as CoAP server in an ongoing observation, then the peer: Höglund & Tiloca Expires 5 September 2024 [Page 16] Internet-Draft Identifier Update for OSCORE March 2024 - MUST store the value of the 'kid' parameter from the original Observe registration request, and retain it for the whole duration of the observation, throughout which the peer MUST NOT update the stored value associated with the corresponding Observe registration request; and - MUST use the stored value of the 'kid' parameter from the original Observe registration request as value for the 'request_kid' parameter in the external_aad structure (see Section 5.4 of [RFC8613]), when protecting notifications for that observation as per Section 8.3.1 of [RFC8613]. 3. Security Considerations TODO Security 4. IANA Considerations This document has the following actions for IANA. Note to RFC Editor: Please replace all occurrences of "[RFC-XXXX]" with the RFC number of this specification and delete this paragraph. 4.1. CoAP Option Numbers Registry IANA is asked to enter the following option number to the "CoAP Option Numbers" registry within the "Constrained RESTful Environments (CoRE) Parameters" registry group. +========+==============+============+ | Number | Name | Reference | +========+==============+============+ | TBD24 | Recipient-ID | [RFC-XXXX] | +--------+--------------+------------+ Table 1: New CoAP Option Number Note to RFC Editor: Following the registration of the CoAP Option Number 24, please replace "TBD24" with "24" in the table above. Then, please delete this paragraph. 5. References 5.1. Normative References [I-D.ietf-core-oscore-key-update] Höglund, R. and M. Tiloca, "Key Update for OSCORE (KUDOS)", Work in Progress, Internet-Draft, draft-ietf- Höglund & Tiloca Expires 5 September 2024 [Page 17] Internet-Draft Identifier Update for OSCORE March 2024 core-oscore-key-update-07, 4 March 2024, <https://datatracker.ietf.org/doc/html/draft-ietf-core- oscore-key-update-07>. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>. [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained Application Protocol (CoAP)", RFC 7252, DOI 10.17487/RFC7252, June 2014, <https://www.rfc-editor.org/info/rfc7252>. [RFC7641] Hartke, K., "Observing Resources in the Constrained Application Protocol (CoAP)", RFC 7641, DOI 10.17487/RFC7641, September 2015, <https://www.rfc-editor.org/info/rfc7641>. [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>. [RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz, "Object Security for Constrained RESTful Environments (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019, <https://www.rfc-editor.org/info/rfc8613>. [RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", STD 94, RFC 8949, DOI 10.17487/RFC8949, December 2020, <https://www.rfc-editor.org/info/rfc8949>. 5.2. Informative References [I-D.ietf-lake-edhoc] Selander, G., Mattsson, J. P., and F. Palombini, "Ephemeral Diffie-Hellman Over COSE (EDHOC)", Work in Progress, Internet-Draft, draft-ietf-lake-edhoc-23, 22 January 2024, <https://datatracker.ietf.org/doc/html/ draft-ietf-lake-edhoc-23>. Appendix A. Examples of OSCORE ID update procedure Integrated in KUDOS The following section shows two examples where the OSCORE ID update procedure is performed together with the KUDOS procedure for updating OSCORE keying material. Höglund & Tiloca Expires 5 September 2024 [Page 18] Internet-Draft Identifier Update for OSCORE March 2024 A.1. Forward Message Flow Figure 4 provides an example of the OSCORE ID update procedure, as run integrated in an execution of KUDOS and in the forward message flow (see Section 4.3.1 of [I-D.ietf-core-oscore-key-update]). On each peer, SID and RID denote the OSCORE Sender ID and Recipient ID of that peer, respectively. Client Server (initiator) (responder) | | CTX_OLD { | | CTX_OLD { SID = 0x01 | | SID = 0x00 RID = 0x00 | | RID = 0x01 } | | } | | Generate N1 | | | | CTX_1 = updateCtx( | | X1, | | N1, | | CTX_OLD) | | | | | Request #1 | Protect with CTX_1 |--------------------->| /.well-known/kudos | OSCORE { | | ... | | d flag: 1 | CTX_1 = updateCtx( | x: X1 | X1, | nonce: N1 | N1, | ... | CTX_OLD) | kid: 0x01 | | } | Verify with CTX_1 | Encrypted Payload { | | ... | Generate N2 | Recipient-ID: 0x42 | | ... | CTX_NEW = updateCtx( | } | Comb(X1,X2), | | Comb(N1,N2), | | CTX_OLD) | | | Response #1 | |<---------------------| Protect with CTX_NEW | OSCORE { | | ... | CTX_NEW = updateCtx( | Partial IV: 0 | Comb(X1,X2), | ... | Comb(N1,N2), | | Höglund & Tiloca Expires 5 September 2024 [Page 19] Internet-Draft Identifier Update for OSCORE March 2024 CTX_OLD) | d flag: 1 | | x: X2 | Verify with CTX_NEW | nonce: N2 | | ... | Discard CTX_OLD | } | | Encrypted Payload { | Update SID and | ... | Update SID and RID in CTX_NEW | Recipient-ID: 0x78 | RID in CTX_NEW | ... | CTX_NEW { | } | CTX_NEW { SID = 0x78 | | SID = 0x42 RID = 0x42 | | RID = 0x78 } | | } | | // The actual key update process ends here. // The two peers can use the new Security Context CTX_NEW. | | | Request #2 | Protect with CTX_NEW |--------------------->| /temp | OSCORE { | | ... | | kid: 0x78 | Verify with CTX_NEW | } | | Encrypted Payload { | Discard CTX_OLD | ... | | Application Payload | | } | | | | Response #2 | |<---------------------| Protect with CTX_NEW | OSCORE { | | ... | Verify with CTX_NEW | } | | Encrypted Payload { | | ... | | Application Payload | | } | | | Figure 4: Example of the OSCORE ID update procedure with Forward Message Flow and Integrated in a KUDOS Execution. Höglund & Tiloca Expires 5 September 2024 [Page 20] Internet-Draft Identifier Update for OSCORE March 2024 A.2. Reverse Message Flow Figure 5 provides an example of the OSCORE ID update procedure, as run integrated in an execution of KUDOS and in the reverse message flow (see Section 4.3.2 of [I-D.ietf-core-oscore-key-update]). On each peer, SID and RID denote the OSCORE Sender ID and Recipient ID of that peer, respectively. Client Server (responder) (initiator) | | CTX_OLD { | | CTX_OLD { SID = 0x01 | | SID = 0x00 RID = 0x00 | | RID = 0x01 } | | } | | | Request #1 | Protect with CTX_OLD |--------------------->| /temp | OSCORE { | | ... | | kid: 0x01 | | } | Verify with CTX_OLD | Encrypted Payload { | | ... | Generate N1 | Application Payload | | } | CTX_1 = updateCtx( | | X1, | | N1, | | CTX_OLD) | | | Response #1 | |<---------------------| Protect with CTX_1 | OSCORE { | | ... | CTX_1 = updateCtx( | Partial IV: 0 | X1, | ... | N1, | d flag: 1 | CTX_OLD) | x: X1 | | nonce: N1 | Verify with CTX_1 | ... | | } | Generate N2 | Encrypted Payload { | | ... | CTX_NEW = updateCtx( | Recipient-ID: 0x78 | Comb(X1,X2), | ... | Comb(N1,N2), | } | CTX_OLD) | | | | Höglund & Tiloca Expires 5 September 2024 [Page 21] Internet-Draft Identifier Update for OSCORE March 2024 | Request #2 | Protect with CTX_NEW |--------------------->| /.well-known/kudos | OSCORE { | | ... | | d flag: 1 | CTX_NEW = updateCtx( | x: X2 | Comb(X1,X2), | nonce: N2 | Comb(N1,N2), | y: w | CTX_OLD) | old_nonce: N1 | | kid: 0x01 | | ... | | } | Verify with CTX_NEW | Encrypted Payload { | | ... | Discard CTX_OLD | Recipient-ID: 0x42 | | ... | | Application Payload | | } | | | Update SID and | | Update SID and RID in CTX_NEW | | RID in CTX_NEW | | CTX_NEW { | | CTX_NEW { SID = 0x78 | | SID = 0x42 RID = 0x42 | | RID = 0x78 } | | } | | // The actual key update process ends here. // The two peers can use the new Security Context CTX_NEW. | | | Response #2 | |<---------------------| Protect with CTX_NEW | OSCORE { | | ... | Verify with CTX_NEW | } | | Encrypted Payload { | Discard CTX_OLD | ... | | Application Payload | | } | | | | Request #3 | Protect with CTX_NEW |--------------------->| /temp | OSCORE { | | ... | | kid: 0x78 | Verify with CTX_NEW | } | Höglund & Tiloca Expires 5 September 2024 [Page 22] Internet-Draft Identifier Update for OSCORE March 2024 | Encrypted Payload { | | ... | | Application Payload | | } | | | | Response #3 | |<---------------------| Protect with CTX_NEW | OSCORE { | | ... | Verify with CTX_NEW | } | | Encrypted Payload { | | ... | | Application Payload | | } | | | Figure 5: Example of the OSCORE ID update procedure with Reverse Message Flow and Integrated in a KUDOS Execution. Appendix B. Document Updates This section is to be removed before publishing as an RFC. B.1. Version -00 * Split out material from Key Update for OSCORE draft into this new document. * Extended terminology * Editorial improvements Acknowledgments The authors sincerely thank Christian Amsüss, Carsten Bormann, John Preuß Mattsson, and Göran Selander for their feedback and comments. The work on this document has been partly supported by VINNOVA and the Celtic-Next project CRITISEC; and by the H2020 projects SIFIS- Home (Grant agreement 952652) and ARCADIAN-IoT (Grant agreement 101020259). Authors' Addresses Höglund & Tiloca Expires 5 September 2024 [Page 23] Internet-Draft Identifier Update for OSCORE March 2024 Rikard Höglund RISE AB Isafjordsgatan 22 SE-16440 Stockholm Kista Sweden Email: rikard.hoglund@ri.se Marco Tiloca RISE AB Isafjordsgatan 22 SE-16440 Stockholm Kista Sweden Email: marco.tiloca@ri.se Höglund & Tiloca Expires 5 September 2024 [Page 24]