Key Update for OSCORE (KUDOS)

2.1.1. Limits for 'q' and 'v'

Formulas for calculating the security levels, as Integrity Advantage (IA) and Confidentiality Advantage (CA) probabilities, are presented in [I-D.irtf-cfrg-aead-limits]. These formulas take as input specific values for 'q' and 'v' (see section Section 2.1) and for 'l', i.e., the maximum length of each message (in cipher blocks).¶

For the algorithms shown in Figure 1 that can be used as AEAD Algorithm for OSCORE, the key property to achieve is having IA and CA values which are no larger than p = 2^-64, which will ensure a safe security level for the AEAD Algorithm. This can be entailed by using the values q = 2^20, v = 2^20, and l = 2^10, that this document recommends to use for these algorithms.¶

Figure 1 also shows the resulting IA and CA probabilities enjoyed by the considered algorithms, when taking the value of 'q', 'v' and 'l' above as input to the formulas defined in [I-D.irtf-cfrg-aead-limits].¶

+------------------------+----------------+----------------+
| Algorithm name         | IA probability | CA probability |
|------------------------+----------------+----------------|
| AEAD_AES_128_CCM       | 2^-64          | 2^-66          |
| AEAD_AES_128_GCM       | 2^-97          | 2^-89          |
| AEAD_AES_256_GCM       | 2^-97          | 2^-89          |
| AEAD_CHACHA20_POLY1305 | 2^-73          | -              |
+------------------------+----------------+----------------+

When AEAD_AES_128_CCM_8 is used as AEAD Algorithm for OSCORE, the triplet (q, v, l) considered above yields larger values of IA and CA. Hence, specifically for AEAD_AES_128_CCM_8, this document recommends using the triplet (q, v, l) = (2^20, 2^14, 2^8). This is appropriate, since the resulting CA and IA values are not greater than the threshold value of 2^-50 defined in [I-D.irtf-cfrg-aead-limits], and thus yields an acceptable security level. Achieving smaller values of CA and IA would require to inconveniently reduce 'q', 'v' or 'l', with no corresponding increase in terms of security, as further elaborated in Appendix A.¶

+------------------------+----------+----------+-----------+
| Algorithm name         | l=2^6 in | l=2^8 in | l=2^10 in |
|                        | bytes    | bytes    | bytes     |
|------------------------+----------+----------|-----------|
| AEAD_AES_128_CCM       | 1024     | 4096     | 16384     |
| AEAD_AES_128_GCM       | 1024     | 4096     | 16384     |
| AEAD_AES_256_GCM       | 1024     | 4096     | 16384     |
| AEAD_AES_128_CCM_8     | 1024     | 4096     | 16384     |
| AEAD_CHACHA20_POLY1305 | 4096     | 16384    | 65536     |
+------------------------+----------+----------+-----------+

2.2.1. Common Context

The Common Context is extended to include the following parameter.¶

• 'exp': with value the expiration time of the OSCORE Security Context, as a non-negative integer. The parameter contains a numeric value representing the number of seconds from 1970-01-01T00:00:00Z UTC until the specified UTC date/time, ignoring leap seconds, analogous to what specified for NumericDate in Section 2 of [RFC7519].¶

  At the time indicated in this field, a peer MUST stop using this Security Context to process any incoming or outgoing message, and is required to establish a new Security Context to continue OSCORE-protected communications with the other peer.¶

2.2.2. Sender Context

The Sender Context is extended to include the following parameters.¶

• 'count_q': a non-negative integer counter, keeping track of the current 'q' value for the Sender Key. At any time, 'count_q' has as value the number of messages that have been encrypted using the Sender Key. The value of 'count_q' is set to 0 when establishing the Sender Context.¶

• 'limit_q': a non-negative integer, which specifies the highest value that 'count_q' is allowed to reach, before stopping using the Sender Key to process outgoing messages.¶

  The value of 'limit_q' depends on the AEAD algorithm specified in the Common Context, considering the properties of that algorithm. The value of 'limit_q' is determined according to Section 2.1.1.¶

Note for implementation: it is possible to avoid storing and maintaining the counter 'count_q'. Rather, an estimated value to be compared against 'limit_q' can be computed, by leveraging the Sender Sequence Number of the peer and (an estimate of) the other peer's. A possible method to achieve this is described in Appendix B. While this relieves peers from storing and maintaining the precise 'count_q' value, it results in overestimating the number of encryptions performed with a Sender Key. This in turn results in approaching 'limit_q' sooner and thus in performing a key update procedure more frequently.¶

2.2.3. Recipient Context

The Recipient Context is extended to include the following parameters.¶

• 'count_v': a non-negative integer counter, keeping track of the current 'v' value for the Recipient Key. At any time, 'count_v' has as value the number of failed decryptions occurred on incoming messages using the Recipient Key. The value of 'count_v' is set to 0 when establishing the Recipient Context.¶

• 'limit_v': a non-negative integer, which specifies the highest value that 'count_v' is allowed to reach, before stopping using the Recipient Key to process incoming messages.¶

  The value of 'limit_v' depends on the AEAD algorithm specified in the Common Context, considering the properties of that algorithm. The value of 'limit_v' is determined according to Section 2.1.1.¶

2.3.1. Protecting a Request or a Response

Before encrypting the COSE object using the Sender Key, the 'count_q' counter MUST be incremented.¶

If 'count_q' exceeds the 'limit_q' limit, the message processing MUST be aborted. From then on, the Sender Key MUST NOT be used to encrypt further messages.¶

2.3.2. Verifying a Request or a Response

If an incoming message is detected to be a replay (see Section 7.4 of [RFC8613]), the 'count_v' counter MUST NOT be incremented.¶

If the decryption and verification of the COSE object using the Recipient Key fails, the 'count_v' counter MUST be incremented.¶

After 'count_v' has exceeded the 'limit_v' limit, incoming messages MUST NOT be decrypted and verified using the Recipient Key, and their processing MUST be aborted.¶

4.3.1. Client-Initiated Key Update

Figure 5 shows the KUDOS workflow with the client acting as initiator.¶

                   Client               Server
                   (initiator)          (responder)
                        |                    |
Generate N1             |                    |
                        |                    |
CTX_1 =                 |                    |
  updateCtx(X1, N1,     |                    |
            CTX_OLD)    |                    |
                        |                    |
                        |     Request #1     |
Protect with CTX_1      |------------------->|
                        | OSCORE Option:     | CTX_1 =
                        |   ...              |  updateCtx(X1, N1,
                        |   d flag: 1        |            CTX_OLD)
                        |   X1               |
                        |   Nonce: N1        | Verify with CTX_1
                        |   ...              |
                        |                    | Generate N2
                        |                    |
                        |                    | CTX_NEW =
                        |                    |  updateCtx(Comb(X1,X2),
                        |                    |            Comb(N1,N2),
                        |                    |            CTX_OLD)
                        |                    |
                        |     Response #1    |
                        |<-------------------| Protect with CTX_NEW
CTX_NEW =               | OSCORE Option:     |
 updateCtx(Comb(X1,X2), |   ...              |
           Comb(N1,N2), |                    |
              CTX_OLD)  |   d flag: 1        |
                        |   X2               |
Verify with CTX_NEW     |   Nonce: N2        |
                        |   ...              |
Discard CTX_OLD         |                    |
                        |                    |

// The actual key update process ends here.
// The two peers can use the new Security Context CTX_NEW.

                        |                    |
                        |     Request #2     |
Protect with CTX_NEW    |------------------->|
                        |                    | Verify with CTX_NEW
                        |                    |
                        |                    | Discard CTX_OLD
                        |                    |
                        |     Response #2    |
                        |<-------------------| Protect with CTX_NEW
Verify with CTX_NEW     |                    |
                        |                    |

First, the client generates a random value N1, and uses the nonce N = N1 and X = X1 together with the old Security Context CTX_OLD, in order to derive a temporary Security Context CTX_1.¶

If the peers' original Security Context was derived through the EDHOC protocol and the updateCtx() function in Section 4.2 used METHOD 1 to derive CTX_1, then the client deletes the newly derived EDHOC keys PRK_out and PRK_exporter, which do not replace the old ones.¶

Then, the client sends an OSCORE request to the server, protected with the Security Context CTX_1. In particular, the request has the 'd' flag bit set to 1, and specifies X1 as 'x' and N1 as 'nonce' (see Section 4.1). After that, the client deletes CTX_1.¶

Upon receiving the OSCORE request, the server retrieves the value N1 from the 'nonce' field of the request, the value X1 from the 'x' byte of the OSCORE Option, and provides the updateCtx() function with the input N = N1, X = X1 and the old Security Context CTX_OLD, in order to derive the temporary Security Context CTX_1.¶

Figure 6 shows an example of how the two peers compute X and N provided as input to the updateCtx() function, and how they compute X_N within the updateCtx() function, when deriving CTX_1 (see Section 4.2).¶

   X1 and N1 expressed as raw values
   X1 = 0x80
   N1 = 0x018a278f7faab55a

   updateCtx() is called with
   X = 0x80
   N = 0x018a278f7faab55a

   In updateCtx(), X_cbor and N_cbor are built as CBOR byte strings
   X_cbor = 0x4180               (h'80')
   N_cbor = 0x48018a278f7faab55a (h'018a278f7faab55a')

   In updateCtx(), X_N is built from N_cbor and X_cbor
   X_N = 0x4b418048018a278f7faab55a (h'418048018a278f7faab55a')

If the peers' original Security Context was derived through the EDHOC protocol and the updateCtx() function in Section 4.2 used METHOD 1 to derive CTX_1, then the server deletes the newly derived EDHOC keys PRK_out and PRK_exporter, which do not replace the old ones.¶

Then, the server verifies the request by using the Security Context CTX_1.¶

After that, the server generates a random value N2, and uses N = Comb(N1, N2) and X = Comb(X1, X2) together with the old Security Context CTX_OLD, in order to derive the new Security Context CTX_NEW.¶

An example of this nonce processing on the server with values for N1, X1, N2 and X2 is presented in Figure 7.¶

   X1, X2, N1 and N2 expressed as raw values
   X1 = 0x80
   X2 = 0x80
   N1 = 0x018a278f7faab55a
   N2 = 0x25a8991cd700ac01

   X1, X2, N1 and N2 as CBOR byte strings
   X1 = 0x4180 (h'80')
   X2 = 0x4180 (h'80')
   N1 = 0x48018a278f7faab55a (h'018a278f7faab55a')
   N2 = 0x4825a8991cd700ac01 (h'25a8991cd700ac01')

   updateCtx() is called with
   X = 0x41804180
   N = 0x48018a278f7faab55a4825a8991cd700ac01

   In updateCtx(), X_cbor and N_cbor are built as CBOR byte strings
   X_cbor = 0x4441804180 (h'41804180')
   N_cbor = 0x5248018a278f7faab55a4825a8991cd700ac01
            (h'48018a278f7faab55a4825a8991cd700ac01')

   In updateCtx(), X_N is built from N_cbor and X_cbor
   X_N = 0x581844418041805248018a278f7faab55a4825a8991cd700ac01
         (h'44418041805248018a278f7faab55a4825a8991cd700ac01')

Then, the server sends an OSCORE response to the client, protected with the new Security Context CTX_NEW. In particular, the response has the 'd' flag bit set to 1 and specifies N2 as 'nonce'. After that, the server deletes CTX_1.¶

Upon receiving the OSCORE response, the client retrieves the value N2 from the 'nonce' field of the response, and the value X2 from the 'x' byte of the OSCORE Option. Since the client has received a response to an OSCORE request it made with the 'd' flag bit set to 1, the client provides the updateCtx() function with the input N = Comb(N1, N2), X = Comb(X1, X2) and the old Security Context CTX_OLD, in order to derive the new Security Context CTX_NEW. Finally, the client verifies the response by using the Security Context CTX_NEW and deletes the old Security Context CTX_OLD.¶

If the peers' original Security Context was derived through the EDHOC protocol and the updateCtx() function in Section 4.2 used METHOD 1 to derive CTX_NEW, then the client replaces the old EDHOC keys PRK_out and PRK_exporter with the newly derived ones.¶

Then, the client can send a new OSCORE request protected with the new Security Context CTX_NEW.¶

When successfully verifying the request using the Security Context CTX_NEW, the server deletes the old Security Context CTX_OLD and can reply with an OSCORE response protected with the new Security Context CTX_NEW.¶

If the peers' original Security Context was derived through the EDHOC protocol and the updateCtx() function in Section 4.2 used METHOD 1 to derive CTX_NEW, then the server replaces the old EDHOC keys PRK_out and PRK_exporter with the newly derived ones.¶

From then on, the two peers can protect their message exchanges by using the new Security Context CTX_NEW.¶

Note that the server achieves key confirmation only when receiving a message from the client as protected with the new Security Context CTX_NEW. If the server sends a non KUDOS request to the client protected with CTX_NEW before then, and the server receives a 4.01 (Unauthorized) error response as reply, the server SHOULD delete the new Security Context CTX_NEW and start a new client-initiated key update process, by taking the role of initiator as per Figure 5.¶

Also note that, if both peers reboot simultaneously, they will run the client-initiated version of KUDOS defined in this section. That is, one of the two peers implementing a CoAP client will send KUDOS Request #1 in Figure 5.¶

4.3.2. Server-Initiated Key Update

Figure 8 shows the KUDOS workflow with the server acting as initiator.¶

                      Client               Server
                   (responder)          (initiator)
                        |                    |
                        |     Request #1     |
Protect with CTX_OLD    |------------------->|
                        |                    | Verify with CTX_OLD
                        |                    |
                        |                    | Generate N1
                        |                    |
                        |                    | CTX_1 =
                        |                    |  updateCtx(X1, N1,
                        |                    |            CTX_OLD)
                        |                    |
                        |     Response #1    |
                        |<-------------------| Protect with CTX_1
CTX_1 =                 | OSCORE Option:     |
  updateCtx(X1, N1,     |   ...              |
            CTX_OLD)    |   d flag: 1        |
                        |   X1               |
Verify with CTX_1       |   Nonce: N1        |
                        |   ...              |
Generate N2             |                    |
                        |                    |
CTX_NEW =               |                    |
 updateCtx(Comb(X1,X2), |                    |
           Comb(N1,N2   |                    |
              CTX_OLD)  |                    |
                        |                    |
                        |     Request #2     |
Protect with CTX_NEW    |------------------->|
                        | OSCORE Option:     | CTX_NEW =
                        |   ...              |  updateCtx(Comb(X1,X2),
                        |                    |            Comb(N1,N2),
                        |   d flag: 1        |            CTX_OLD)
                        |   X2               |
                        |   Nonce: N1|N2     | Verify with CTX_NEW
                        |   ...              |
                        |                    | Discard CTX_OLD
                        |                    |

// The actual key update process ends here.
// The two peers can use the new Security Context CTX_NEW.

                        |     Response #2    |
                        |<-------------------| Protect with CTX_NEW
Verify with CTX_NEW     |                    |
                        |                    |
Discard CTX_OLD         |                    |
                        |                    |

First, the client sends a normal OSCORE request to the server, protected with the old Security Context CTX_OLD and with the 'd' flag bit set to 0.¶

Upon receiving the OSCORE request and after having verified it with the old Security Context CTX_OLD as usual, the server generates a random value N1 and provides the updateCtx() function with the input N = N1, X = X1 and the old Security Context CTX_OLD, in order to derive the temporary Security Context CTX_1.¶

If the peers' original Security Context was derived through the EDHOC protocol and the updateCtx() function in Section 4.2 used METHOD 1 to derive CTX_1, then the server deletes the newly derived EDHOC keys PRK_out and PRK_exporter, which do not replace the old ones.¶

Then, the server sends an OSCORE response to the client, protected with the Security Context CTX_1. In particular, the response has the 'd' flag bit set to 1 and specifies N1 as 'nonce' (see Section 4.1). After that, the server deletes CTX_1.¶

Upon receiving the OSCORE response, the client retrieves the value N1 from the 'nonce' field of the response, the value X1 from the 'x' byte of the OSCORE Option, and provides the updateCtx() function with the input N = N1, X = X1 and the old Security Context CTX_OLD, in order to derive the temporary Security Context CTX_1.¶

If the peers' original Security Context was derived through the EDHOC protocol and the updateCtx() function in Section 4.2 used METHOD 1 to derive CTX_1, then the client deletes the newly derived EDHOC keys PRK_out and PRK_exporter, which do not replace the old ones.¶

Then, the client verifies the response by using the Security Context CTX_1.¶

After that, the client generates a random value N2, and provides the updateCtx() function with the input N = Comb(N1, N2), X = Comb(X1, X2) and the old Security Context CTX_OLD, in order to derive the new Security Context CTX_NEW. Then, the client sends an OSCORE request to the server, protected with the new Security Context CTX_NEW. In particular, the request has the 'd' flag bit set to 1 and specifies N1 | N2 as 'nonce'. After that, the client deletes CTX_1.¶

Upon receiving the OSCORE request, the server retrieves the value N1 | N2 from the request and the value X2 from the 'x' byte of the OSCORE Option. Then, the server verifies that: i) the value N1 is identical to the value N1 specified in a previous OSCORE response with the 'd' flag bit set to 1; and ii) the value N1 | N2 has not been received before in an OSCORE request with the 'd' flag bit set to 1.¶

If the verification succeeds, the server provides the updateCtx() function with the input N = Comb(N1, N2), X = Comb(X1, X2) and the old Security Context CTX_OLD, in order to derive the new Security Context CTX_NEW. Finally, the server verifies the request by using the Security Context CTX_NEW and deletes the old Security Context CTX_OLD.¶

If the peers' original Security Context was derived through the EDHOC protocol and the updateCtx() function in Section 4.2 used METHOD 1 to derive CTX_NEW, then the server replaces the old EDHOC keys PRK_out and PRK_exporter with the newly derived ones.¶

After that, the server can send an OSCORE response protected with the new Security Context CTX_NEW.¶

When successfully verifying the response using the Security Context CTX_NEW, the client deletes the old Security Context CTX_OLD.¶

If the peers' original Security Context was derived through the EDHOC protocol and the updateCtx() function in Section 4.2 used METHOD 1 to derive CTX_NEW, then the client replaces the old EDHOC keys PRK_out and PRK_exporter with the newly derived ones.¶

From then on, the two peers can protect their message exchanges by using the new Security Context CTX_NEW.¶

Note that the client achieves key confirmation only when receiving a message from the server as protected with the new Security Context CTX_NEW. If the client sends a non KUDOS request to the server protected with CTX_NEW before then, and the client receives a 4.01 (Unauthorized) error response as reply, the client SHOULD delete the new Security Context CTX_NEW and start a new client-initiated key update process, by taking the role of initiator as per Figure 5 in Section 4.3.1.¶

4.4.1. Handling and Use of Keying Material

In the following, a device is denoted as "CAPABLE" if it is able to store information in non-volatile memory (e.g., on disk), beyond a one-time-only writing occurring at manufacturing or (re-)commissioning time.¶

The following terms are used to refer to OSCORE keying material.¶

• Bootstrap Master Secret and Bootstrap Master Salt. If pre-provisioned during manufacturing or (re-)commissioning, these OSCORE Master Secret and Master Salt are initially stored on disk and are never going to be overwritten by the device.¶
• Latest Master Secret and Latest Master Salt. These OSCORE Master Secret and Master Salt can be dynamically updated by the device. In case of reboot, they are lost unless they have been stored on disk.¶

Note that:¶

• A peer running KUDOS can have none of the pairs above associated with another peer, only one or both.¶
• A peer that has neither of the pairs above associated with another peer, cannot run KUDOS in any mode with that other peer.¶

• A peer that has only one of the pairs above associated with another peer can attempt to run KUDOS with that other peer, but the procedure might fail depending on the other peer's capabilities. In particular:¶

  • In order to run KUDOS in FS mode, a peer must be a CAPABLE device. It follows that two peers have to both be CAPABLE devices in order to be able to run KUDOS in FS mode with one another.¶
  • In order to run KUDOS in no-FS mode, a peer must have Bootstrap Master Secret and Bootstrap Master Salt available as stored on disk.¶

As a general rule, once successfully generated a new OSCORE Security Context CTX (e.g., CTX is the CTX_NEW resulting from a KUDOS execution, or it has been established through the EDHOC protocol [I-D.ietf-lake-edhoc]), a peer considers the Master Secret and Master Salt of CTX as Latest Master Secret and Latest Master Salt. After that:¶

• If the peer is a CAPABLE device, it SHOULD store Latest Master Secret and Latest Master Salt on disk.¶

  As an exception, this does not apply to possible temporary OSCORE Security Contexts used during a key update procedure, such as CTX_1 used during the KUDOS execution. That is, the OSCORE Master Secret and Master Salt from such temporary Security Contexts MUST NOT be stored on disk.¶

• The peer MUST store Latest Master Secret and Latest Master Salt in volatile memory, thus making them available to OSCORE message processing and possible key update procedures.¶

4.4.2. Selection of KUDOS Mode

During a KUDOS execution, the two peers agree on whether to perform the key update procedure in FS mode or no-FS mode, by leveraging the "No Forward Secrecy" bit, 'p', in the 'x' byte of the OSCORE Option value of the KUDOS messages (see Section 4.1). The 'p' bit practically determines what OSCORE Security Context to use as CTX_OLD during the KUDOS execution, consistently with the indicated mode.¶

• If the 'p' bit is set to 0 (FS mode), the updateCtx() function used to derive CTX_1 or CTX_NEW considers as input CTX_OLD the current OSCORE Security Context shared with the other peer as is. In particular, CTX_OLD includes Latest Master Secret as OSCORE Master Secret and Latest Master Salt as OSCORE Master Salt.¶
• If the 'p' bit is set to 1 (no-FS mode), the updateCtx() function used to derive CTX_1 or CTX_NEW considers as input CTX_OLD the current OSCORE Security Context shared with the other peer, with the following difference: Bootstrap Master Secret is used as OSCORE Master Secret and Bootstrap Master Salt is used as OSCORE Master Salt. That is, every execution of KUDOS in no-FS mode between these two peers considers the same pair (Master Secret, Master Salt) in the OSCORE Security Context CTX_OLD provided as input to the updateCtx() function, hence the impossibility to achieve forward secrecy.¶

A peer determines to run KUDOS either in FS or no-FS mode with another peer as follows.¶

• If a peer A is not a CAPABLE device, it MUST run KUDOS only in no-FS mode. That is, when sending a KUDOS message, it MUST set to 1 the 'p' bit of the 'x' byte in the OSCORE Option value.¶

• If a peer A is a CAPABLE device, it SHOULD run KUDOS only in FS mode and SHOULD NOT run KUDOS as initiator in no-FS mode. That is, when sending a KUDOS message, it SHOULD set to 0 the 'p' bit of the 'x' byte in the OSCORE Option value. An exception applies in the following cases.¶

  • The peer A is running KUDOS with another peer B, which A has learned to not be a CAPABLE device (and hence not able to run KUDOS in FS mode).¶

    Note that, if the peer A is a CAPABLE device, it is able to store such information about the other peer B on disk and it MUST do so. From then on, the peer A will perform every execution of KUDOS with the peer B in no-FS mode, including after a possible reboot.¶

  • The peer A is acting as responder and running KUDOS with another peer B without knowing its capabilities, and A receives a KUDOS message where the 'p' bit of the 'x' byte in the OSCORE Option value is set to 1.¶

• If the peer A is a CAPABLE device and has learned that another peer B is also a CAPABLE device (and hence able to run KUDOS in FS mode), then the peer A MUST NOT run KUDOS with the peer B in no-FS mode. This also means that, if the peer A acts as responder when running KUDOS with the peer B, the peer A MUST terminate the KUDOS execution if it receives a KUDOS message from the peer B where the 'p' bit of the 'x' byte in the OSCORE Option value is set to 1.¶

  Note that, if the peer A is a CAPABLE device, it is able to store such information about the other peer B on disk and it MUST do so. This ensures that the peer A will perform every execution of KUDOS with the peer B in FS mode. In turn, this prevents a possible downgrading attack, aimed at making A believe that B is not a CAPABLE device, and thus to run KUDOS in no-FS mode although the FS mode can actually be used by both peers.¶

Within the limitations above, two peers running KUDOS generate the new OSCORE Security Context CTX_NEW according to the mode indicated per the bit 'p' set by the responder in the second KUDOS message.¶

If, after having received the first KUDOS message, the responder can continue performing KUDOS, the bit 'p' in the reply message has the same value as in the bit 'p' set by the initiator, unless the value is 0 and the responder is not a CAPABLE device. More specifically:¶

• If both peers are CAPABLE devices, they will run KUDOS in FS mode. That is, both initiator and responder sets the 'p' bit to 0 in the respective sent KUDOS message.¶
• If both peers are not CAPABLE devices or only the peer acting as initiator is not a CAPABLE device, they will run KUDOS in no-FS mode. That is, both initiator and responder sets the 'p' bit to 1 in the respective sent KUDOS message.¶
• If only the peer acting as initiator is a CAPABLE device and it has knowledge of the other peer being a not CAPABLE device, they will run KUDOS in no-FS mode. That is, both initiator and responder sets the 'p' bit to 1 in the respective sent KUDOS message.¶

• If only the peer acting as initiator is a CAPABLE device and it has no knowledge of the other peer being a not CAPABLE device, they will not run KUDOS in FS mode and will rather set to ground for possibly retrying in no-FS mode. In particular, the initiator sets the 'p' bit of its sent KUDOS message to 0. Then:¶

  • If the responder is a server, it MUST reply with a 5.03 (Service Unavailable) error response. The response MUST be protected with the newly derived OSCORE Security Context CTX_NEW. The diagnostic payload MAY provide additional information. In the error response, the 'p' bit MUST be set to 1.¶

    When receiving the error response, the initiator learns that the responder is not a CAPABLE device (and hence not able to run KUDOS in FS mode). The initiator MAY try running KUDOS again. If it does so, the initiator MUST set the 'p' bit to 1, when sending a new request as first KUDOS message.¶

  • If the responder is a client, it sends to the initiator the second KUDOS message as a new request, which MUST be protected with the newly derived OSCORE Security Context CTX_NEW. In the newly sent request, the 'p' bit MUST be set to 1.¶

    When receiving the new request above (i.e., with the 'p' bit set to 1 as a follow-up to the previous KUDOS response having the 'p' bit set to 0), the initiator learns that the responder is not a CAPABLE device (and hence not able to run KUDOS in FS mode).¶

In either case, both KUDOS peers delete the OSCORE Security Contexts CTX_1 and CTX_NEW.¶

4.5.1. Management of Observations

As per Section 3.1 of [RFC7641], a client can register its interest in observing a resource at a server, by sending a registration request including the Observe Option with value 0.¶

If the server registers the observation as ongoing, the server sends back a successful response also including the Observe Option, hence confirming that an entry has been successfully added for that client.¶

If the client receives back the successful response above from the server, then the client also registers the observation as ongoing.¶

In case the client can ever consider to preserve ongoing observations beyond a key update as defined below, then the client MUST NOT simply forget about an ongoing observation if not interested in it anymore. Instead, the client MUST send an explicit cancellation request to the server, i.e., a request including the Observe Option with value 1 (see Section 3.6 of [RFC7641]). After sending this cancellation request, if the client does not receive back a response confirming that the observation has been terminated, the client MUST NOT consider the observation terminated. The client MAY try again to terminate the observation by sending a new cancellation request.¶

In case a peer A performs a KUDOS execution with another peer B, and A has ongoing observations with B that it is interested to preserve beyond the key update, then A can explicitly indicate its interest to do so. To this end, the peer A sets to 1 the bit "Preserve Observations", 'b', in the 'x' byte of the OSCORE Option value (see Section 4.1), in the KUDOS message it sends to the other peer B.¶

If a peer acting as responder receives the first KUDOS message with the bit 'b' set to 0, then the peer MUST set to 0 the bit 'b' in the KUDOS message it sends as follow-up, regardless of its wish to preserve ongoing observations with the other peer.¶

If a peer acting as initiator has sent the first KUDOS message with the bit 'b' set to 0, the peer MUST ignore the bit 'b' in the follow-up KUDOS message that it receives from the other peer.¶

After successfully completing the KUDOS execution (i.e., after having successfully derived the new OSCORE Security Context CTX_NEW), both peers have expressed their interest in preserving their common ongoing observations if and only if the bit 'b' was set to 1 in both the exchanged KUDOS messages. In such a case, each peer X performs the following actions.¶

1. The peer X considers all the still ongoing observations that it has with the other peer, such that X acts as client in those observations. If there are no such observations, the peer X takes no further actions. Otherwise, it moves to step 2.¶
2. The peer X considers all the OSCORE Partial IV values used in the Observe registration request associated with any of the still ongoing observations determined at step 1.¶
3. The peer X determines the value PIV* as the highest OSCORE Partial IV value among those considered at step 2.¶
4. In the Sender Context of the OSCORE Security Context shared with the other peer, the peer X sets its own Sender Sequence Number to (PIV* + 1), rather than to 0.¶

As a result, each peer X will "jump" beyond the OSCORE Partial IV (PIV) values that are occupied and in use for ongoing observations with the other peer where X acts as client.¶

Note that, each time it runs KUDOS, a peer must determine if it wishes to preserve ongoing observations with the other peer or not, before sending its KUDOS message.¶

To this end, the peer should also assess the new value that PIV* would take after a successful completion of KUDOS, in case ongoing observations with the other peer are going to be preserved. If the peer considers such a new value of PIV* to be too close to the maximum possible value admitted for the OSCORE Partial IV, then the peer may choose to run KUDOS with no intention to preserve its ongoing observations with the other peer, in order to "start over" from a fresh, entirely unused PIV space.¶

Application policies can further influence whether attempting to preserve observations beyond a key update is appropriate or not.¶

5.1.1. Client-Initiated OSCORE IDs Update

Figure 10 shows the stand-alone OSCORE IDs update workflow, with the client acting as initiator.¶

On each peer, SID and RID denote the OSCORE Sender ID and Recipient ID of that peer, respectively.¶

          Client                             Server
       (initiator)                         (responder)
            |                                   |
CTX_A {     |                                   | CTX_A {
 SID = 1    |                                   |  SID = 0
 RID = 0    |                                   |  RID = 1
}           |                                   | }
            |                                   |
            |            Request #1             |
Protect     |---------------------------------->|
with CTX_A  | OSCORE Option: ..., kid:1         | Verify
            | Encrypted_Payload {               | with CTX_A
            |    ...                            |
            |    RecipientID: 42                |
            |    ...                            |
            |    Application Payload            |
            | }                                 |
            |                                   |

          // When embedded in KUDOS, CTX_1 is CTX_A,
          // and there cannot be application payload.

            |                                   |
            |            Response #1            |
            |<----------------------------------| Protect
Verify      | OSCORE Option: ...                | with CTX_A
with CTX_A  | Encrypted_Payload {               |
            |    ...                            |
            |    Recipient-ID: 78               |
            |    ...                            |
            |    Application Payload            |
            | }                                 |
            |                                   |

           // When embedded in KUDOS, this message
           // is protected using CTX_NEW, and there
           // cannot be application payload.
           //
           // Then, CTX_B builds on CTX_NEW by updating
           // the new Sender/Recipient IDs

            |                                   |
CTX_B {     |                                   | CTX_B {
 SID = 78   |                                   |  SID = 42
 RID = 42   |                                   |  RID = 78
}           |                                   | }
            |                                   |
            |            Request #2             |
Protect     |---------------------------------->|
with CTX_B  | OSCORE Option: ..., kid:78        | Verify
            | Encrypted_Payload {               | with  CTX_B
            |    ...                            |
            |    Application Payload            |
            | }                                 |
            |                                   |
            |            Response #2            |
            |<----------------------------------| Protect
Verify      | OSCORE Option: ...                | with CTX_B
with CTX_B  | Encrypted_Payload {               |
            |    ...                            |
            |    Application Payload            |
            | }                                 |
            |                                   |
Discard     |                                   |
CTX_A       |                                   |
            |                                   |
            |            Request #3             |
Protect     |---------------------------------->|
with CTX_B  | OSCORE Option: ..., kid:78        | Verify
            | Encrypted_Payload {               | with CTX_B
            |    ...                            |
            |    Application Payload            |
            | }                                 |
            |                                   | Discard
            |                                   | CTX_A
            |                                   |
            |            Response #3            |
            |<----------------------------------| Protect
Verify      | OSCORE Option: ...                | with CTX_B
with CTX_B  | Encrypted_Payload {               |
            |    ...                            |
            |    Application Payload            |
            | }                                 |
            |                                   |

[TODO: discuss the example]¶

5.1.2. Server-Initiated OSCORE IDs Update

Figure 11 shows the stand-alone OSCORE IDs update workflow, with the server acting as initiator.¶

On each peer, SID and RID denote the OSCORE Sender ID and Recipient ID of that peer, respectively.¶

          Client                             Server
       (responder)                         (initiator)
            |                                   |
CTX_A {     |                                   | CTX_A {
 SID = 1    |                                   |  SID = 0
 RID = 0    |                                   |  RID = 1
}           |                                   | }
            |                                   |
            |            Request #1             |
Protect     |---------------------------------->|
with CTX_A  | OSCORE Option: ..., kid:1         | Verify
            | Encrypted_Payload {               | with CTX_A
            |    ...                            |
            |    Application Payload            |
            | }                                 |
            |                                   |

          // When (to be) embedded in KUDOS,
          // CTX_OLD is CTX_A

            |                                   |
            |            Response #1            |
            |<----------------------------------| Protect
Verify      | OSCORE Option: ...                | with CTX_A
with CTX_A  | Encrypted_Payload {               |
            |    ...                            |
            |    Recipient-ID: 78               |
            |    Application Payload            |
            | }                                 |

          // When embedded in KUDOS, this message is
          // protected with CTX_1 instead, and
          // there cannot be application payload.

            |                                   |
CTX_A {     |                                   | CTX_A {
 SID = 1    |                                   |  SID = 0
 RID = 0    |                                   |  RID = 1
}           |                                   | }
            |                                   |
            |            Request #2             |
Protect     |---------------------------------->|
with CTX_A  | OSCORE Option: ..., kid:1         | Verify
            | Encrypted_Payload {               | with CTX_A
            |    ...                            |
            |    Recipient-ID: 42               |
            |    Application Payload            |
            | }                                 |
            |                                   |

          // When embedded in KUDOS, this message is
          // protected with CTX_NEW instead, and
          // there cannot be application payload.

            |                                   |
            |            Response #2            |
            |<----------------------------------| Protect
Verify      | OSCORE Option: ...                | with CTX_A
with CTX_A  | Encrypted_Payload {               |
            |    ...                            |
            |    Application Payload            |
            | }                                 |
            |                                   |

          // When embedded in KUDOS, this message is
          // protected with CTX_NEW instead, and
          // there cannot be application payload.

            |                                   |
CTX_B {     |                                   | CTX_B {
 SID = 78   |                                   |  SID = 42
 RID = 42   |                                   |  RID = 78
}           |                                   | }
            |                                   |
            |            Request #3             |
Protect     |---------------------------------->|
with CTX_B  | OSCORE Option: ..., kid:78        | Verify
            | Encrypted_Payload {               | with CTX_B
            |    ...                            |
            |    Application Payload            |
            | }                                 |
            |                                   |
            |            Response #3            |
            |<----------------------------------| Protect
Verify      | OSCORE Option: ...                | with CTX_B
with CTX_B  | Encrypted_Payload {               |
            |    ...                            |
            |    Application Payload            |
            | }                                 |
            |                                   |
Discard     |                                   |
CTX_A       |                                   |
            |                                   |
            |            Request #4             |
Protect     |---------------------------------->|
with CTX_B  | OSCORE Option: ..., kid:78        | Verify
            | Encrypted_Payload {               | with CTX_B
            |    ...                            |
            |    Application Payload            |
            | }                                 |
            |                                   |
            |                                   | Discard
            |                                   | CTX_A
            |                                   |
            |            Response #4            |
            |<----------------------------------| Protect
Verify      | OSCORE Option: ...                | with CTX_B
with CTX_B  | Encrypted_Payload {               |
            |    ...                            |
            |    Application Payload            |
            | }                                 |
            |                                   |

[TODO: discuss the example]¶

5.1.3. Additional Actions for Stand-Alone Execution

After having experienced a loss of state, a peer MUST NOT participate in a stand-alone OSCORE IDs 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 or the EDHOC protocol [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 reboot.¶

Furthermore, when participating in a stand-alone OSCORE IDs update procedure, a peer performs the following additional steps.¶

• When sending an OSCORE IDs update message, the peer MUST specify its new intended OSCORE Recipient ID as value of the Recipient-ID Option only if such a Recipient ID is not only available (see Section 3.3 of [RFC8613], but it has also never been used as Recipient ID with the current triplet (Master Secret, Master Salt, ID Context).¶
• When receiving an OSCORE IDs 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 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 OSCORE Master Secret (e.g, performed by running KUDOS).¶