Key Update for OSCORE (KUDOS)

1.1. Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

Readers are expected to be familiar with the terms and concepts related to CoAP [RFC7252], Observe [RFC7641], CBOR [RFC8949], OSCORE [RFC8613], and EDHOC [RFC9528].¶

This document additionally defines the following terminology.¶

• FS mode: the KUDOS execution mode that achieves forward secrecy (see Section 4.3).¶

• No-FS mode: the KUDOS execution mode that does not achieve forward secrecy (see Section 4.4).¶

• Equilibrium: The situation where a peer has no execution of KUDOS currently ongoing with the other KUDOS peer for updating one of their OSCORE Security Contexts.¶

4.1. Extensions to the OSCORE Option

This document extends the use of the OSCORE Option originally defined in [RFC8613] as follows.¶

• This document defines the usage of the eight least significant bit, called "Extension-1 Flag", in the first byte of the OSCORE Option containing the OSCORE flag bits. The registration of this flag bit in the "OSCORE Flag Bits" registry is specified in Section 6.1.¶

  When the Extension-1 Flag is set to 1, the second byte of the OSCORE Option MUST include the OSCORE flag bits 8-15.¶

• This document defines the usage of the least significant bit "Nonce Flag", 'd', in the second byte of the OSCORE Option containing the OSCORE flag bits 8-15. This flag bit is specified in Section 6.1.¶

  When it is set to 1, the compressed COSE object contains a field 'x' and a field 'nonce', to be used for the steps defined in Section 4.3. In particular, the 1 byte 'x' following 'kid context' (if any) encodes the size of the following field 'nonce', together with signaling bits that indicate the specific behavior to adopt during the KUDOS execution.¶

  Hereafter, a message is referred to as a "KUDOS message", if and only if the second byte of flags is present and the 'd' bit is set to 1. If that is not the case, the message is referred to as a "non KUDOS message".¶

  The encoding of 'x' is as follows:¶

  • The four least significant bits encode the 'nonce' size in bytes minus 1, namely 'm'.¶

  • The fifth least significant bit is the "No Forward Secrecy" 'p' bit. The sender peer indicates its wish to run KUDOS in FS mode or in no-FS mode, by setting the 'p' bit to 0 or 1, respectively. This makes KUDOS possible to run also for peers that cannot support the FS mode. At the same time, two peers MUST run KUDOS in FS mode if they are both capable to, as per Section 4.3. The execution of KUDOS in no-FS mode is defined in Section 4.4.¶

  • The sixth least significant bit is the "Preserve Observations" 'b' bit. The sender peer indicates its wish to preserve ongoing observations beyond the KUDOS execution or not, by setting the 'b' bit to 1 or 0, respectively. The related processing is defined in Section 4.5.¶

  • The seventh least significant bit is the 'z' bit. The meaning of 'z' is as follows:¶

    • z = 0: This is a "divergent" message, that is a KUDOS message protected with a temporary OSCORE Security Context and indicating that the sender peer is moving away from "equilibrium". The sender peer is offering its own nonce in the 'nonce' field of this message and is waiting to receive the other peer's nonce.¶

    • z = 1: This is a "convergent" message, that is a KUDOS message protected with the newly established OSCORE Security Context and indicating that the sender peer is offering its own nonce in the 'nonce' field of this message, has received the other peer's nonce, and is going to wait for key confirmation (to return to equilibrium).¶

  • The eight least significant bit is reserved for future use. This bit SHALL be set to zero when not in use. According to this specification, if this bit is set to 1: i) if the message is a request, it is considered to be malformed and decompression fails as specified in item 2 of Section 8.2 of [RFC8613]; ii) if the message is a response, it is considered to be malformed and decompression fails as specified in item 2 of Section 8.4 of [RFC8613] and the client SHALL discard the response as specified in item 8 of Section 8.4 of [RFC8613].¶

Figure 1 shows extended OSCORE Option value, with the presence of 'nonce'.¶

 0 1 2 3 4 5 6 7  8   9   10  11  12  13  14  15 <----- n bytes ----->
+-+-+-+-+-+-+-+-+---+---+---+---+---+---+---+---+---------------------+
|1|0|0|h|k|  n  | 0 | 0 | 0 | 0 | 0 | 0 | 0 | d | Partial IV (if any) |
+-+-+-+-+-+-+-+-+---+---+---+---+---+---+---+---+---------------------+


 <- 1 byte -> <----- s bytes ------> <- 1 byte -> <--- m + 1 bytes --->
+------------+----------------------+------------+--------------------+
| s (if any) | kid context (if any) | x (if any) | nonce (if any)     |
+------------+----------------------+------------+--------------------+
                                   /              \____
                                  /                    |
                                 /   0 1 2 3 4 5 6 7   |
                                 |  +-+-+-+-+-+-+-+-+  |
                                 |  |0|z|b|p|   m   |  |
                                 |  +-+-+-+-+-+-+-+-+  |

4.2. Function for Security Context Update

The updateCtx() function shown in Figure 2 takes as input the three parameters input1, input2, and CTX_IN. In particular, input1 and input2 are built from the 'x' and 'nonce' fields transported in the OSCORE Option value of the exchanged KUDOS messages (see Section 4.1), while CTX_IN is the OSCORE Security Context to update. The function returns a new OSCORE Security Context CTX_OUT.¶

As a first step, the updateCtx() function builds the two CBOR byte strings input1_cbor and input2_cbor, with value the input parameter input1 and input2, respectively. Then, it builds X_N, as the byte concatenation of input1_cbor and input2_cbor. In order for updateCtx() to be agnostic of the order the nonce values were exchanged, the input1_cbor and input2_cbor values are first sorted in lexicographical order before they are concatenated. E.g., if input1_cbor comes before input2_cbor in lexicographical ordering, then X_N takes the value input1_cbor | input2_cbor and vice-versa.¶

After that, the updateCtx() function derives the new values of the Master Secret and Master Salt for CTX_OUT. In particular, the new Master Secret is derived through a KUDOS-Expand step, which takes as input the Master Secret value from the Security Context CTX_IN, the literal string "key update", X_N, and the length of the Master Secret. Instead, the new Master Salt takes X_N as value.¶

The definition of KUDOS-Expand depends on the key derivation function used for OSCORE by the two peers, as specified in CTX_IN. If the key derivation function is an HKDF Algorithm (see Section 3.1 of [RFC8613]), then KUDOS-Expand is mapped to HKDF-Expand [RFC5869], as shown below. Also, the hash algorithm is the same one used by the HKDF Algorithm specified in CTX_IN.¶

KUDOS-Expand(CTX_IN.MasterSecret, ExpandLabel, key_length) =
   HKDF-Expand(CTX_IN.MasterSecret, ExpandLabel, key_length)

If a future specification updates [RFC8613] by admitting different key derivation functions than HKDF Algorithms (e.g., KMAC as based on the SHAKE128 or SHAKE256 hash functions), that specification has to update also the present document in order to define the mapping between such key derivation functions and KUDOS-Expand.¶

When an HKDF Algorithm is used, the derivation of new values follows the same approach used in TLS 1.3, which is also based on HKDF-Expand (see Section 7.1 of [RFC8446]) and used for computing new keying material in case of key update (see Section 4.6.3 of [RFC8446]).¶

After that, the new Master Secret and Master Salt parameters are used to derive a new Security Context CTX_OUT as per Section 3.2 of [RFC8613]. Any other parameter required for the derivation takes the same value as in the Security Context CTX_IN.¶

Note that the following holds for the newly derived CTX_OUT:¶

• In its Sender Context, the Sender Sequence Number is initialized to 0 as per Section 3.2.2 of [RFC8613].¶

• If the peer that has derived CTX_OUT supports CoAP Observe [RFC7641], the Notification Number used for the replay protection of Observe notifications (see Section 7.4.1 of [RFC8613]) is left as not initialized.¶

Finally, the updateCtx() function returns the newly derived Security Context CTX_OUT.¶

Since the updateCtx() function also takes X as input, the derivation of CTX_OUT also considers as input the information from the 'x' field transported in the OSCORE Option value of the exchanged KUDOS messages. In turn, this ensures that, if successfully completed, a KUDOS execution occurs as intended by the two peers.¶

function updateCtx(input1, input2, CTX_IN):

 // Output values
 CTX_OUT       // The new Security Context
 MSECRET_NEW   // The new Master Secret
 MSALT_NEW     // The new Master Salt

 // Define the label for the key update
 Label = "key update"

 // Create CBOR byte strings from input1 and input2
 input1_cbor = create_cbor_bstr(input1)
 input2_cbor = create_cbor_bstr(input2)

 // Concatenate the CBOR-encoded input1 and input2
 // according to their lexicographic order
 X_N = is_lexicographic_shorter(input1_cbor, input2_cbor) ?
       (input1_cbor | input2_cbor) : (input2_cbor | input1_cbor)

 // Determine the length in bytes of the current Master Secret
 oscore_key_length = length(CTX_IN.MasterSecret)

 // Create the new Master Secret using KUDOS-Expand-Label
 MSECRET_NEW = KUDOS_Expand_Label(CTX_IN.MasterSecret, Label,
                                  X_N, oscore_key_length)

 // Set the new Master Salt to X_N
 MSALT_NEW = X_N

 // Derive the new Security Context CTX_OUT, using
 // the new Master Secret, the new Master Salt,
 // and other parameters from CTX_IN
 CTX_OUT = derive_security_context(MSECRET_NEW, MSALT_NEW, CTX_IN)

 // Return the new Security Context
 return CTX_OUT


function KUDOS_Expand_Label(master_secret, Label, X_N, key_length):

 struct {
     uint16 length = key_length;
     opaque label<7..255> = "oscore " + Label;
     opaque context<0..255> = X_N;
 } ExpandLabel;

 return KUDOS_Expand(master_secret, ExpandLabel, key_length)

4.3. Key Update

This section defines KUDOS, a lightweight procedure that two OSCORE peers can use to update their keying material and establish a new OSCORE Security Context.¶

Using KUDOS as described in this section will achieve forward secrecy for the new keying material produced by the execution of KUDOS, as long as the original OSCORE keying material was also established with forward secrecy. For peers unable to store information to persistent memory, Section 4.4 provides an alternative approach to perform key update without achieving forward secrecy. This alternative ensures that also very constrained peers are able to use KUDOS, although without achieving forward secrecy.¶

A peer can run KUDOS for active rekeying at any time, or for a variety of more compelling reasons. These include the (approaching) expiration of the OSCORE Security Context, approaching limits for the key usage [I-D.ietf-core-oscore-key-limits], application policies, and imminent exhaustion of the OSCORE Sender Sequence Number space.¶

The expiration time of an OSCORE Security Context and the key usage limits are hard limits. Once reached them, a peer MUST stop using the keying material in the OSCORE Security Context for exchanging application data with the other peer, and has to perform a rekeying before resuming secure communication.¶

Before starting KUDOS, the two peers share the OSCORE Security Context CTX_OLD. In particular, CTX_OLD is the most recent OSCORE Security Context that a peer has with the other peer, before initiating the KUDOS procedure or upon having received and successfully verified a divergent KUDOS message. During an execution of KUDOS, a temporary OSCORE Security Context CTX_TEMP is derived.¶

Once successfully completed the KUDOS execution, the two peers agree on a newly established OSCORE Security Context CTX_NEW that replaces CTX_OLD. In particular, CTX_NEW is the most recent OSCORE Security Context that a peer has, before sending a convergent KUDOS message or upon having received and successfully verified a convergent KUDOS message. CTX_OLD can be safely deleted upon receiving key confirmation from the other peer, i.e., that the other peer also has CTX_NEW.¶

The following specifically defines how KUDOS is run in its stateful FS mode achieving forward secrecy. That is, in the OSCORE Option value of all the exchanged KUDOS messages, the "No Forward Secrecy" 'p' bit is set to 0.¶

In order to run KUDOS in FS mode, both peers have to be able to write in non-volatile memory. From the newly derived Security Context CTX_NEW, the peers MUST store to non-volatile memory the immutable parts of the OSCORE Security Context as specified in Section 3.1 of [RFC8613], with the possible exception of the Common IV, Sender Key, and Recipient Key that can be derived again when needed, as specified in Section 3.2.1 of [RFC8613]. If the peer is unable to write in non-volatile memory, the two peers have to run KUDOS in its stateless no-FS mode (see Section 4.4).¶

4.4. Key Update Admitting no Forward Secrecy

The FS mode of the KUDOS procedure defined in Section 4.3 ensures forward secrecy of the OSCORE keying material. However, it requires peers executing KUDOS to preserve their state (e.g., across a device reboot), by writing information such as data from the newly derived OSCORE Security Context CTX_NEW in non-volatile memory.¶

This can be problematic for devices that cannot dynamically write information to non-volatile memory. For example, some devices may support only a single writing in persistent memory when initial keying material is provided (e.g., at manufacturing or commissioning time), but no further writing after that. Therefore, these devices cannot perform a stateful key update procedure, and thus are not capable to run KUDOS in FS mode to achieve forward secrecy.¶

In order to address these limitations, KUDOS can be run in its stateless no-FS mode, as defined in the following. This allows two peers to achieve the same results as when running KUDOS in FS mode (see Section 4.3), with the difference that forward secrecy is not achieved and no state information is required to be dynamically written in non-volatile memory.¶

From a practical point of view, the two modes differ as to what exact OSCORE Master Secret and Master Salt are used as part of the OSCORE Security Context CTX_IN that is provided as input to the updateCtx() function (see Section 4.2).¶

If either or both peers are not able to write in non-volatile memory, then the two peers have to run KUDOS in no-FS mode.¶

4.5. Preserving Observations Across Key Updates

As defined in Section 4.3, once a peer has completed the KUDOS execution and successfully derived the new OSCORE Security Context CTX_NEW, that peer normally terminates all the ongoing observations it has with the other peer [RFC7641], as protected with the old OSCORE Security Context CTX_OLD.¶

This section describes a method that the two peers can use to safely preserve the ongoing observations that they have with one another, beyond the completion of a KUDOS execution. In particular, this method ensures that an Observe notification can never successfully cryptographically match against the Observe requests of two different observations, e.g., against an Observe request protected with CTX_OLD and an Observe request protected with CTX_NEW.¶

The actual preservation of ongoing observations has to be agreed by the two peers at each execution of KUDOS that they run with one another, as defined in Section 4.5.1. If, at the end of a KUDOS execution, the two peers have not agreed on that, they MUST terminate the ongoing observations that they have with one another, just as defined in Section 4.3.4.¶

4.6. Retention Policies

Applications MAY define policies that allow a peer to temporarily keep the old Security Context CTX_OLD beyond having established the new Security Context CTX_NEW and having achieved key confirmation, rather than simply deleting CTX_OLD. This allows the peer to decrypt late, still on-the-fly incoming non KUDOS messages protected with CTX_OLD.¶

When enforcing such policies, the following applies.¶

• Outgoing non KUDOS messages MUST be protected by using only CTX_NEW.¶

• Incoming non KUDOS messages MUST first be attempted to decrypt by using CTX_NEW. If decryption fails, a second attempt can use CTX_OLD.¶

• KUDOS messages MUST NOT be protected or unprotected by using CTX_OLD.¶

• When an amount of time defined by the policy has elapsed since the establishment of CTX_NEW, the peer deletes CTX_OLD.¶

A peer MUST NOT retain CTX_OLD beyond the establishment of CTX_NEW and the achievement of key confirmation, if any of the following conditions holds:¶

• CTX_OLD is expired.¶

• Limits set for safe key usage have been reached [I-D.ietf-core-oscore-key-limits], for the Recipient Key of the Recipient Context of CTX_OLD.¶

4.7. Discussion

KUDOS is intended to deprecate and replace the procedure defined in Appendix B.2 of [RFC8613], as fundamentally achieving the same goal, while displaying a number of improvements and advantages.¶

In particular, it is especially convenient for the handling of failure events concerning the JRC node in 6TiSCH networks (see Section 2). That is, among its intrinsic advantages compared to the procedure defined in Appendix B.2 of [RFC8613], KUDOS preserves the same ID Context value, when establishing a new OSCORE Security Context.¶

Since the JRC uses ID Context values as identifiers of network nodes, namely "pledge identifiers", the above implies that the JRC does not have to perform anymore a mapping between a new, different ID Context value and a certain pledge identifier (see Section 8.3.3 of [RFC9031]). It follows that pledge identifiers can remain constant once assigned, and thus ID Context values used as pledge identifiers can be employed in the long-term as originally intended.¶

4.8. Signaling KUDOS support in EDHOC

The EDHOC protocol defines the transport of additional External Authorization Data (EAD) within an optional EAD field of the EDHOC messages (see Section 3.8 of [RFC9528]). An EAD field is composed of one or multiple EAD items, each of which specifies an identifying 'ead_label' encoded as a CBOR integer, and an optional 'ead_value' encoded as a CBOR bstr.¶

This document defines a new EDHOC EAD item KUDOS_EAD and registers its 'ead_label' in Section 6.3. By including this EAD item in an outgoing EDHOC message, a sender peer can indicate whether it supports KUDOS and in which modes, as well as query the other peer about its support. Note that peers do not have to use this EDHOC EAD item to be able to run KUDOS with each other, irrespective of the modes they support. A KUDOS peer MUST only use the EDHOC EAD item KUDOS_EAD as non-critical. That is, when included in an EDHOC message, its 'ead_label' MUST be used with positive sign. The possible values of the 'ead_value' are as follows:¶

When the KUDOS_EAD item is included in EDHOC message_1 with 'ead_value' ASK, a recipient peer that supports the KUDOS_EAD item MUST specify whether it supports KUDOS in EDHOC message_2.¶

When the KUDOS_EAD item is not included in EDHOC message_1 with 'ead_value' ASK, a recipient peer that supports the KUDOS_EAD item MAY still specify whether it supports KUDOS in EDHOC message_2.¶

When the KUDOS_EAD item is included in EDHOC message_2 with 'ead_value' FULL or PART, a recipient peer that supports the KUDOS_EAD item SHOULD specify whether it supports KUDOS in EDHOC message_3. An exception applies in case, based on application policies or other context information, the recipient peer that receives EDHOC message_2 already knows that the sender peer is supposed to have such knowledge.¶

When the KUDOS_EAD item is included in EDHOC message_2 with 'ead_value' NONE, a recipient peer that supports the KUDOS_EAD item MUST NOT specify whether it supports KUDOS in EDHOC message_3.¶

In the following cases, the recipient peer silently ignores the KUDOS_EAD item specified in the received EDHOC message, and does not include a KUDOS_EAD item in the next EDHOC message it sends (if any).¶

• The recipient peer does not support the KUDOS_EAD item.¶

• The KUDOS_EAD item is included in EDHOC message_1 with 'ead_value' different than ASK¶

• The KUDOS_EAD item is included in EDHOC message_2 or message_3 with 'ead_value' ASK.¶

• The KUDOS_EAD item is included in EDHOC message_4.¶

That is, by specifying 'ead_value' ASK in EDHOC message_1, a peer A can indicate to the other peer B that it wishes to know if B supports KUDOS and in what mode(s). In the following EDHOC message_2, B indicates whether it supports KUDOS and in what mode(s), by specifying either NONE, FULL, or PART as 'ead_value'. Specifying the 'ead_value' FULL or PART in EDHOC message_2 also asks A to indicate whether it supports KUDOS in EDHOC message_3.¶

To further illustrate the functionality, two examples are presented below as EDHOC executions where only the new KUDOS_EAD item is shown when present, and assuming that no other EAD items are used by the two peers.¶

In the example above, the Initiator asks the EDHOC Responder about its support for KUDOS ('ead_value' = ASK). In EDHOC message_2, the Responder indicates that it supports both the FS and no-FS mode of KUDOS ('ead_value' = FULL). Finally, in EDHOC message_3, the Initiator indicates that it also supports both the FS and no-FS mode of KUDOS ('ead_value' = FULL). After the EDHOC execution has successfully finished, both peers are aware that they both support KUDOS, in the FS and no-FS modes.¶

In this second example, the Initiator asks the EDHOC Responder about its support for KUDOS ('ead_value' = ASK). In EDHOC message_2, the Responder indicates that it does not support KUDOS at all ('ead_value' = NONE). Finally, in EDHOC message_3, the Initiator does not include the KUDOS_EAD item, since it already knows that using KUDOS with the other peer will not be possible. After the EDHOC execution has successfully finished, the Initiator is aware that the Responder does not support KUDOS, which the two peers are not going to use with each other.¶

6.1. OSCORE Flag Bits Registry

IANA is asked to add the following entries to the "OSCORE Flag Bits" registry within the "Constrained RESTful Environments (CoRE) Parameters" registry group.¶

In the same registry, IANA is asked to mark as 'Unassigned' the entry with Bit Position of 1, i.e., to update the entry as follows.¶

6.2. CoAP Option Numbers Registry

IANA is asked to add this document as a reference for the OSCORE Option in the "CoAP Option Numbers" registry within the "Constrained RESTful Environments (CoRE) Parameters" registry group.¶

6.3. EDHOC External Authorization Data Registry

IANA is asked to add the following entries to the "EDHOC External Authorization Data" registry defined in Section 10.5 of [RFC9528] within the "Ephemeral Diffie-Hellman Over COSE (EDHOC)" registry group.¶

6.4. The Well-Known URI Registry

IANA is asked to add the 'kudos' well-known URI to the Well-Known URIs registry as defined by [RFC8615].¶

• URI suffix: kudos¶

• Change controller: IETF¶

• Specification document(s): [RFC-XXXX]¶

• Related information: None¶

6.5. Resource Type (rt=) Link Target Attribute Values Registry

IANA is requested to add the resource type "core.kudos" to the "Resource Type (rt=) Link Target Attribute Values" registry under the registry group "Constrained RESTful Environments (CoRE) Parameters".¶

• Value: "core.kudos"¶

• Description: KUDOS resource.¶

• Reference: [RFC-XXXX]¶

7.1. Normative References

[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/rfc/rfc2119>.

[RFC5869]

Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand Key Derivation Function (HKDF)", RFC 5869, DOI 10.17487/RFC5869, May 2010, <https://www.rfc-editor.org/rfc/rfc5869>.

[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/rfc/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/rfc/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/rfc/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/rfc/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/rfc/rfc8949>.

[RFC9528]

Selander, G., Preuß Mattsson, J., and F. Palombini, "Ephemeral Diffie-Hellman Over COSE (EDHOC)", RFC 9528, DOI 10.17487/RFC9528, March 2024, <https://www.rfc-editor.org/rfc/rfc9528>.

7.2. Informative References

[I-D.ietf-ace-edhoc-oscore-profile]

Selander, G., Mattsson, J. P., Tiloca, M., and R. Höglund, "Ephemeral Diffie-Hellman Over COSE (EDHOC) and Object Security for Constrained Environments (OSCORE) Profile for Authentication and Authorization for Constrained Environments (ACE)", Work in Progress, Internet-Draft, draft-ietf-ace-edhoc-oscore-profile-06, 21 October 2024, <https://datatracker.ietf.org/doc/html/draft-ietf-ace-edhoc-oscore-profile-06>.

[I-D.ietf-core-oscore-key-limits]

Höglund, R. and M. Tiloca, "Key Usage Limits for OSCORE", Work in Progress, Internet-Draft, draft-ietf-core-oscore-key-limits-04, 8 January 2025, <https://datatracker.ietf.org/doc/html/draft-ietf-core-oscore-key-limits-04>.

[I-D.irtf-cfrg-aead-limits]

Günther, F., Thomson, M., and C. A. Wood, "Usage Limits on AEAD Algorithms", Work in Progress, Internet-Draft, draft-irtf-cfrg-aead-limits-09, 9 October 2024, <https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-aead-limits-09>.

[LwM2M]

Open Mobile Alliance, "Lightweight Machine to Machine Technical Specification - Core, Approved Version 1.2, OMA-TS-LightweightM2M_Core-V1_2-20201110-A", November 2020, <http://www.openmobilealliance.org/release/LightweightM2M/V1_2-20201110-A/OMA-TS-LightweightM2M_Core-V1_2-20201110-A.pdf>.

[LwM2M-Transport]

Open Mobile Alliance, "Lightweight Machine to Machine Technical Specification - Transport Bindings, Approved Version 1.2, OMA-TS-LightweightM2M_Transport-V1_2-20201110-A", November 2020, <http://www.openmobilealliance.org/release/LightweightM2M/V1_2-20201110-A/OMA-TS-LightweightM2M_Transport-V1_2-20201110-A.pdf>.

[RFC4086]

Eastlake 3rd, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, DOI 10.17487/RFC4086, June 2005, <https://www.rfc-editor.org/rfc/rfc4086>.

[RFC7554]

Watteyne, T., Ed., Palattella, M., and L. Grieco, "Using IEEE 802.15.4e Time-Slotted Channel Hopping (TSCH) in the Internet of Things (IoT): Problem Statement", RFC 7554, DOI 10.17487/RFC7554, May 2015, <https://www.rfc-editor.org/rfc/rfc7554>.

[RFC7967]

Bhattacharyya, A., Bandyopadhyay, S., Pal, A., and T. Bose, "Constrained Application Protocol (CoAP) Option for No Server Response", RFC 7967, DOI 10.17487/RFC7967, August 2016, <https://www.rfc-editor.org/rfc/rfc7967>.

[RFC8180]

Vilajosana, X., Ed., Pister, K., and T. Watteyne, "Minimal IPv6 over the TSCH Mode of IEEE 802.15.4e (6TiSCH) Configuration", BCP 210, RFC 8180, DOI 10.17487/RFC8180, May 2017, <https://www.rfc-editor.org/rfc/rfc8180>.

[RFC8446]

Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, <https://www.rfc-editor.org/rfc/rfc8446>.

[RFC8615]

Nottingham, M., "Well-Known Uniform Resource Identifiers (URIs)", RFC 8615, DOI 10.17487/RFC8615, May 2019, <https://www.rfc-editor.org/rfc/rfc8615>.

[RFC8724]

Minaburo, A., Toutain, L., Gomez, C., Barthel, D., and JC. Zuniga, "SCHC: Generic Framework for Static Context Header Compression and Fragmentation", RFC 8724, DOI 10.17487/RFC8724, April 2020, <https://www.rfc-editor.org/rfc/rfc8724>.

[RFC8824]

Minaburo, A., Toutain, L., and R. Andreasen, "Static Context Header Compression (SCHC) for the Constrained Application Protocol (CoAP)", RFC 8824, DOI 10.17487/RFC8824, June 2021, <https://www.rfc-editor.org/rfc/rfc8824>.

[RFC9031]

Vučinić, M., Ed., Simon, J., Pister, K., and M. Richardson, "Constrained Join Protocol (CoJP) for 6TiSCH", RFC 9031, DOI 10.17487/RFC9031, May 2021, <https://www.rfc-editor.org/rfc/rfc9031>.

[RFC9176]

Amsüss, C., Ed., Shelby, Z., Koster, M., Bormann, C., and P. van der Stok, "Constrained RESTful Environments (CoRE) Resource Directory", RFC 9176, DOI 10.17487/RFC9176, April 2022, <https://www.rfc-editor.org/rfc/rfc9176>.

[RFC9200]

Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and H. Tschofenig, "Authentication and Authorization for Constrained Environments Using the OAuth 2.0 Framework (ACE-OAuth)", RFC 9200, DOI 10.17487/RFC9200, August 2022, <https://www.rfc-editor.org/rfc/rfc9200>.

[RFC9203]

Palombini, F., Seitz, L., Selander, G., and M. Gunnarsson, "The Object Security for Constrained RESTful Environments (OSCORE) Profile of the Authentication and Authorization for Constrained Environments (ACE) Framework", RFC 9203, DOI 10.17487/RFC9203, August 2022, <https://www.rfc-editor.org/rfc/rfc9203>.

[Symmetric-Security]

Mattsson, J. P., "Security of Symmetric Ratchets and Key Chains - Implications for Protocols like TLS 1.3, Signal, and PQ3", February 2024, <https://eprint.iacr.org/2024/220>.

A.1. Successful KUDOS Initiated with a Request

The following shows a succesful execution of KUDOS where KUDOS is started by the client sending a divergent KUDOS message.¶

A.2. Successful KUDOS Initiated with a Response

The following shows a succesful execution of KUDOS where KUDOS is started by the Server sending a divergent KUDOS message.¶

B.1. Version -09 to -10

• Major re-design building on a state machine driving the KUDOS execution.¶

B.2. Version -08 to -09

• Merge text about avoiding in-transit requests during a key update into a single subsection.¶

• Improved error handling.¶

• Editorial improvements and clarifications.¶

• State that the EDHOC EAD item must be used as non-critical.¶

• Extended description and updates values for KUDOS communication overhead.¶

• Introduce special case when non-CAPABLE devices may operate in FS Mode.¶

• Add parameter for signaling KUDOS support when using the ACE OSCORE profile.¶

• Enable using the reverse message flow for peers that are only CoAP servers.¶

• Further clarifications about achieving key confirmation and deletion of old contexts.¶

• Restructure distribution of content about FS and no-FS mode.¶

• Warn of consequences of running KUDOS with insufficient margin.¶

• Stressed usefulness of core.kudos for safe KUDOS requests without side effects.¶

B.3. Version -07 to -08

• Add note about usage of the CoAP No-Response Option.¶

• Avoid problems for two simultaneously started key updates.¶

• Set Notification Number to be uninitialized for new OSCORE Security Contexts.¶

• Handle corner case for responder that reached its key usage limits.¶

• Re-organizing main section about Forward Secrecy mode into subsections.¶

• IANA considerations for CoAP Option Numbers Registry to refer to this draft for the OSCORE option.¶

• Use AASVG in diagrams.¶

• Use actual tables instead of figures.¶

• Clarifications and editorial improvements.¶

• Extended security considerations with reference to relevant paper.¶

B.4. Version -06 to -07

• Removed material about the ID update procedure, which has been split out into a separate draft.¶

• Allow non-random nonces for CAPABLE devices.¶

• Editorial improvements.¶

• Permit flexible message flow with KUDOS messages as any request/response.¶

• Enable sending KUDOS messages as regular application messages.¶

B.5. Version -05 to -06

• Mandate support for both the forward and reverse message flow.¶

• Mention the EDHOC and OSCORE profile of ACE as method for rekeying.¶

• Clarify definition of KUDOS (request/response) message.¶

• Further extend the OSCORE option to transport N1 in the second KUDOS message as a request.¶

• Mandate support for the no-FS mode on CAPABLE devices.¶

• Explain when KUDOS fails during selection of mode.¶

• Explicitly forbid using old keying material after reboot.¶

• Editorial improvements.¶

B.6. Version -04 to -05

• Note on client retransmissions if KUDOS execution fails in reverse message flow.¶

• Specify what information needs to be written to non-volatile memory to handle reboots.¶

• Extended recommendations and considerations on minimum size of nonces N1 & N2.¶

• Arbitrary maximum size of the Recipient-ID Option.¶

• Detailed lifecycle of the OSCORE IDs update procedure.¶

• Described examples of OSCORE IDs update procedure.¶

• Examples of OSCORE IDs update procedure integrated in KUDOS.¶

• Considerations about using SCHC for CoAP with OSCORE.¶

• Clarifications and editorial improvements.¶

B.7. Version -03 to -04

• Removed content about key usage limits.¶

• Use of "forward message flow" and "reverse message flow".¶

• Update to RFC 8613 extended to include protection of responses.¶

• Include EDHOC_KeyUpdate() in the methods for rekeying.¶

• Describe reasons for using the OSCORE ID update procedure.¶

• Clarifications on deletion of CTX_OLD and CTX_NEW.¶

• Added new section on preventing deadlocks.¶

• Clarified that peers can decide to run KUDOS at any point.¶

• Defined preservation of observations beyond OSCORE ID updates.¶

• Revised discussion section, including also communication overhead.¶

• Defined a well-known KUDOS resource and a KUDOS resource type.¶

• Editorial improvements.¶

B.8. Version -02 to -03

• Use of the OSCORE flag bit 0 to signal more flag bits.¶

• In UpdateCtx(), open for future key derivation different than HKDF.¶

• Simplified updateCtx() to use only Expand(); used to be METHOD 2.¶

• Included the Partial IV if the second KUDOS message is a response.¶

• Added signaling of support for KUDOS in EDHOC.¶

• Clarifications on terminology and reasons for rekeying.¶

• Updated IANA considerations.¶

• Editorial improvements.¶

B.9. Version -01 to -02

• Extended terminology.¶

• Moved procedure for preserving observations across key updates to main body.¶

• Moved procedure to update OSCORE Sender/Recipient IDs to main body.¶

• Moved key update without forward secrecy section to main body.¶

• Define signaling bits present in the 'x' byte.¶

• Modifications and alignment of updateCtx() with EDHOC.¶

• Rules for deletion of old EDHOC keys PRK_out and PRK_exporter.¶

• Describe CBOR wrapping of involved nonces with examples.¶

• Renamed 'id detail' to 'nonce'.¶

• Editorial improvements.¶

B.10. Version -00 to -01

• Recommendation on limits for CCM_8. Details in Appendix.¶

• Improved message processing, also covering corner cases.¶

• Example of method to estimate and not store 'count_q'.¶

• Added procedure to update OSCORE Sender/Recipient IDs.¶

• Added method for preserving observations across key updates.¶

• Added key update without forward secrecy.¶