Key Update for OSCORE (KUDOS)

4.3.1. Forward Message Flow

Figure 3 shows an example of KUDOS run in the forward message flow, with the client acting as KUDOS initiator. Even though in this example the first KUDOS message is a request and the second is a response, KUDOS is not constrained to this request/response model and a KUDOS execution can be performed with any combination of CoAP requests and responses. Appendix A shows an example where both KUDOS messages are CoAP requests. Furthermore, Appendix B presents an example where KUDOS Response #2 is a response to a different request than KUDOS Request #1.¶

                     Client                  Server
                   (initiator)            (responder)
                        |                      |
Generate N1             |                      |
                        |                      |
CTX_1 = updateCtx(      |                      |
        X1,             |                      |
        N1,             |                      |
        CTX_OLD)        |                      |
                        |                      |
                        |      Request #1      |
Protect with CTX_1      |--------------------->| /.well-known/kudos
                        | OSCORE {             |
                        |  ...                 |
                        |  Partial IV: 0       |
                        |  ...                 |
                        |  d flag: 1           | CTX_1 = updateCtx(
                        |  x: X1               |         X1,
                        |  nonce: N1           |         N1,
                        |  ...                 |         CTX_OLD)
                        | }                    |
                        | Encrypted Payload {  | Verify with CTX_1
                        |  ...                 |
                        | }                    | Generate N2
                        |                      |
                        |                      | 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),  |  d flag: 1           |
          CTX_OLD)      |  x: X2               |
                        |  nonce: N2           |
Verify with CTX_NEW     |  ...                 |
                        | }                    |
Discard CTX_OLD         | Encrypted Payload {  |
                        |  ...                 |
                        | }                    |
                        |                      |

// 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 {             |
                        |  ...                 |
                        | }                    | 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 |
                        | }                    |
                        |                      |

First, the client generates a 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.¶

Then, the client prepares a CoAP request targeting the well-known KUDOS resource (see Section 4.8.3) at "/.well-known/kudos". The client protects this CoAP request using CTX_1 and sends it to the server. When the client protects this request using OSCORE, it MUST use 0 as the value of Partial IV. 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 OSCORE Option, the value X1 from the 'x' byte of the OSCORE Option, and provides the updateCtx() function with the input N = N1, X = X1, and CTX_OLD, in order to derive the temporary Security Context CTX_1.¶

Figure 4 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 = 0x07
   N1 = 0x018a278f7faab55a

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

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

   In updateCtx(), X_N is the byte concatenation of X_cbor and N_cbor
   X_N = 0x410748018a278f7faab55a

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

After that, the server generates a value N2, and uses N = Comb(N1, N2) and X = Comb(X1, X2) together with 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 5.¶

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

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

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

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

   In updateCtx(), X_N is the byte concatenation of X_cbor and N_cbor
   X_N = 0x44410741075248018a278f7faab55a4825a8991cd700ac01

Then, the server sends an OSCORE response to the client, protected with CTX_NEW. In particular, the response has the 'd' flag bit set to 1 and specifies N2 as 'nonce'. Consistently with Section 3, the server includes its Sender Sequence Number as Partial IV in the response. After that, the server deletes CTX_1.¶

Upon receiving the OSCORE response, the client retrieves the value N2 from the 'nonce' field of the OSCORE Option, and the value X2 from the 'x' byte of the OSCORE Option. Since the client has received a response to an OSCORE request that 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 CTX_OLD, in order to derive CTX_NEW. Finally, the client verifies the response by using CTX_NEW and deletes CTX_OLD.¶

From then on, the two peers can protect their message exchanges by using CTX_NEW. As soon as the server successfully verifies an incoming message protected with CTX_NEW, the server deletes CTX_OLD.¶

In the example in Figure 3, the client takes the initiative and sends a new OSCORE request protected with CTX_NEW.¶

In case the server does not successfully verify the request, the same error handling specified in Section 8.2 of [RFC8613] applies. This does not result in deleting CTX_NEW. If the server successfully verifies the request using CTX_NEW, the server deletes CTX_OLD and can reply with an OSCORE response protected with CTX_NEW.¶

Note that the server achieves key confirmation only when receiving a message from the client as protected with 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 CTX_NEW and start a new KUDOS execution acting as CoAP client, i.e., as initiator in the forward message flow.¶

Also note that, if both peers reboot simultaneously, they will run the KUDOS forward message flow as defined in this section. That is, one of the two peers implementing a CoAP client will send KUDOS Request #1 in Figure 3.¶

In case the KUDOS message Request #1 in Figure 3 targets a non-KUDOS resource and the application at the server requires freshness for the received requests, then the server does not deliver the request to the application even if the request has been succesfully verified, and the following KUDOS message (i.e., Response #1 in Figure 3) MUST be a 4.01 (Unauthorized) error response.¶

Upon receiving the 4.01 (Unauthorized) error response as the second KUDOS message Response #1, the client processes it like described above. After successfully completing the KUDOS execution, the client can send to the server a non-KUDOS request protected with CTX_NEW (i.e., Request #2 in Figure 3). Presumably, this request targets the same resource targeted by the previous Request #1, as the same application request or a different one, if the application permits it. Upon receiving, decrypting, and successfully verifying this request protected with CTX_NEW, the server asserts the request as fresh, leveraging the recent establishment of CTX_NEW.¶

An example of a KUDOS execution where Request #1 targets a non-KUDOS resource is shown in Appendix C.¶

4.3.2. Reverse Message Flow

Figure 6 shows an example of KUDOS run in the reverse message flow, with the server acting as initiator.¶

                      Client                 Server
                   (responder)            (initiator)
                        |                      |
                        |      Request #1      |
Protect with CTX_OLD    |--------------------->| /temp
                        | OSCORE {             |
                        |  ...                 |
                        | }                    | 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(    | }                    |
          Comb(X1,X2),  |                      |
          Comb(N1,N2),  |                      |
          CTX_OLD)      |                      |
                        |                      |
                        |      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       |
                        |  ...                 |
                        | }                    |
                        | Encrypted Payload {  | Verify with CTX_NEW
                        |  ...                 |
                        |  Application Payload |
                        | }                    | 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
                        | OSCORE {             |
                        |  ...                 |
Verify with CTX_NEW     | }                    |
                        | Encrypted Payload {  |
Discard CTX_OLD         |  ...                 |
                        |  Application Payload |
                        | }                    |
                        |                      |

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 CTX_OLD as usual, the server generates a value N1 and provides the updateCtx() function with the input N = N1, X = X1, and CTX_OLD, in order to derive the temporary Security Context CTX_1.¶

Then, the server sends an OSCORE response to the client, protected with 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. Consistently with Section 3, the server includes its Sender Sequence Number as Partial IV in the response. After that, the server deletes CTX_1.¶

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

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

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

Upon receiving the OSCORE request, the server retrieves the values N1 from the 'old_nonce' field of the OSCORE Option, the value N2 from the 'nonce' field of the OSCORE Option, 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 CTX_OLD, in order to derive the new Security Context CTX_NEW. Finally, the server verifies the request by using CTX_NEW and deletes CTX_OLD.¶

From then on, the two peers can protect their message exchanges by using CTX_NEW. In particular, as shown in the example in Figure 6, the server can send an OSCORE response protected with CTX_NEW.¶

In case the client does not successfully verify the response, the same error handling specified in Section 8.4 of [RFC8613] applies. This does not result in deleting CTX_NEW. If the client successfully verifies the response using CTX_NEW, the client deletes CTX_OLD. Note that, if the verification of the response fails, the client may want to send again the normal OSCORE request to the server it initially sent (to /temp in the example above), in order to ensure the retrieval of the resource representation.¶

More generally, as soon as the client successfully verifies an incoming message protected with CTX_NEW, the client deletes CTX_OLD.¶

Note that the client achieves key confirmation only when receiving a message from the server as protected with 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 CTX_NEW and start a new KUDOS execution acting again as CoAP client, i.e., as initiator in the forward message flow (see Section 4.3.1).¶

4.4.1. Scenario 1

In this scenario, an execution of KUDOS fails at PEER_1 acting as initiator, but successfully completes at PEER_2 acting as responder. After that, PEER_1 still stores CTX_OLD, while PEER_2 stores CTX_OLD and the just derived CTX_NEW.¶

Then, PEER_1 starts a new KUDOS execution acting again as initiator, by sending the first KUDOS message as a CoAP request. This is protected with a temporary Security Context CTX_1, which is newly derived from the retained CTX_OLD, and from the new values X1 and N1 exchanged in the present KUDOS execution.¶

Upon receiving the first KUDOS message, PEER_2, acting again as responder, proceeds as follows.¶

1. PEER_2 attempts to verify the first KUDOS message by using a temporary Security Context CTX_1'. This is derived from the Security Context CTX_NEW established during the latest successfully completed KUDOS execution.¶

2. The message verification inevitably fails. If PEER_2 is acting as CoAP server, it MUST NOT reply with an unprotected 4.01 (Unauthorized) CoAP response yet.¶

3. PEER_2 MUST attempt to verify the first KUDOS message by using a temporary Security Context CTX_1. This is newly derived from the Security Context CTX_OLD retained after the latest successfully completed KUDOS execution, and from the values X1 and N1 exchanged in the present KUDOS execution.¶

   If the message verification fails, PEER_2: i) retains CTX_OLD and CTX_NEW from the latest successfully completed KUDOS execution; ii) if acting as CoAP server, replies with an unprotected 4.01 (Unauthorized) CoAP response.¶

   If the message verification succeeds, PEER_2: i) retains CTX_OLD from the latest successfully completed KUDOS execution; ii) replaces CTX_NEW from the latest successfully completed KUDOS execution with a new Security Context CTX_NEW', derived from CTX_OLD and from the values X1, X2, N1, and N2 exchanged in the present KUDOS execution; iii) replies with the second KUDOS message, which is protected with the just derived CTX_NEW'.¶

4.4.2. Scenario 2

In this scenario, an execution of KUDOS fails at PEER_1 acting as initiator, but successfully completes at PEER_2 acting as responder. After that, PEER_1 still stores CTX_OLD, while PEER_2 stores CTX_OLD and the just derived CTX_NEW.¶

Then, PEER_2 starts a new KUDOS execution, this time acting as initiator, by sending the first KUDOS message as a CoAP request. This is protected with a temporary Security Context CTX_1, which is newly derived from CTX_NEW established during the latest successfully completed KUDOS execution, as well as from the new values X1 and N1 exchanged in the present KUDOS execution.¶

Upon receiving the first KUDOS message, PEER_1, this time acting as responder, proceeds as follows.¶

1. PEER_1 attempts to verify the first KUDOS message by using a temporary Security Context CTX_1', which is derived from the retained Security Context CTX_OLD and from the values X1 and N1 exchanged in the present KUDOS execution.¶

2. The message verification inevitably fails. If PEER_1 is acting as CoAP server, it replies with an unprotected 4.01 (Unauthorized) CoAP response.¶

3. If PEER_2 does not receive the second KUDOS message for a pre-defined amount of time, or if it receives a 4.01 (Unauthorized) CoAP response when acting as CoAP client, then PEER_2 can start a new KUDOS execution for a maximum, pre-defined number of times.¶

   In this case, PEER_2 sends a new first KUDOS message protected with a temporary Security Context CTX_1', which is derived from the retained CTX_OLD, as well as from the new values X1 and N1 exchanged in the present KUDOS execution.¶

   During this time, PEER_2 does not delete CTX_NEW established during the latest successfully completed KUDOS execution, and does not delete CTX_OLD unless it successfully verifies an incoming message protected with CTX_NEW.¶

4. Upon receiving such a new, first KUDOS message, PEER_1 verifies it by using the temporary Security Context CTX_1', which is derived from the Security Context CTX_OLD, and from the values X1 and N1 exchanged in the present KUDOS execution.¶

   If the message verification succeeds, PEER_1 derives an OSCORE Security Context CTX_NEW' from CTX_OLD and from the values X1, X2, N1, and N2 exchanged in the present KUDOS execution. Then, it replies with the second KUDOS message, which is protected with the latest, just derived CTX_NEW'.¶

5. Upon receiving such second KUDOS message, PEER_2 derives CTX_NEW' from the retained CTX_OLD and from the values X1, X2, N1, and N2 exchanged in the present KUDOS execution. Then, PEER_2 attempts to verify the KUDOS message using the just derived CTX_NEW'.¶

   If the message verification succeeds, PEER_2 deletes the retained CTX_OLD as well as the retained CTX_NEW established during the immediately previously, successfully completed KUDOS execution.¶

4.4.3. Scenario 3

When KUDOS is run in the reverse message flow (see Section 4.3.2), the two peers risk to run into a deadlock, if all the following conditions hold.¶

• The client is a client-only device, i.e., it does not act as CoAP server and thus does not listen for incoming requests.¶

• The server needs to execute KUDOS, which, due to the previous point, can only be performed in its reverse message flow. That is, the server has to wait for an incoming non KUDOS request, in order to initiate KUDOS by replying with the first KUDOS message as a response.¶

• The client sends only Non-confirmable CoAP requests to the server and does not expect responses sent back as reply, hence freeing up a request's Token value once the request is sent.¶

In such a case, in order to avoid experiencing a deadlock situation where the server needs to execute KUDOS but cannot practically initiate it, a client-only device that supports KUDOS SHOULD intersperse Non-confirmable requests it sends to that server with confirmable requests.¶

4.5.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. If that is not the case, the device is denoted as "non-CAPABLE".¶

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.¶

• A peer that is a non-CAPABLE device MUST support the no-FS mode.¶

• A peer that is a CAPABLE device MUST support the FS mode and the no-FS mode.¶

• As an exception to the nonces being generated as random values (see Section Section 4.3), a peer that is a CAPABLE device MAY use a value obtained from a monotonically incremented counter as nonce N1 or N2. This has privacy implications, which are described in Section Section 5. In such a case, the peer MUST enforce measures to ensure freshness of the nonce values. For example, the peer can use the same procedure described in Appendix B.1.1 of [RFC8613] for handling the OSCORE Sender Sequence Number values. These measures require to regularly store the used counter values in non-volatile memory, which makes non-CAPABLE devices unable to safely use counter values as nonce values.¶

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 are not 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.5.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 a non-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. 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 be a non-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 a 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 a non-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 such latter value is 0 and the responder is a non-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 non-CAPABLE devices or only the peer acting as initiator is a non-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 non-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 non-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 consider the KUDOS execution unsuccessful and 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. This response is a KUDOS message, and it MUST have the 'd' bit and the 'p' bit set to 1.¶

    When receiving the error response, the initiator learns that the responder is a non-CAPABLE device (and hence not able to run KUDOS in FS mode), since the 'p' bit in the error response is set to 1, while the 'p' bit in the corresponding request was set to 0. Hence, the initiator MUST consider the KUDOS execution unsuccessful, and 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 MUST consider the KUDOS execution unsuccessful and MUST send 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, the initiator learns that the responder is a non-CAPABLE device (and hence not able to run KUDOS in FS mode), since the 'p' bit in the request is set to 1, while the 'p' bit in the response previously sent as first KUDOS message was set to 0. Also, the initiator SHOULD NOT send any response to such a request, and the responder SHOULD NOT expect any such response.¶

  In either case, both KUDOS peers delete the OSCORE Security Contexts CTX_1 and CTX_NEW. Also, both peers MUST retain CTX_OLD for use during the next KUDOS execution in the no-FS mode. This is in contrast with the typical behavior where CTX_OLD is deleted upon reception of a message protected with CTX_NEW.¶

4.6.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 or equal 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.¶

4.8.1. KUDOS Interleaved with Other Message Exchanges

During a KUDOS execution, a peer that is a CoAP Client must be ready to receive CoAP responses that are not KUDOS messages and that are protected with a different OSCORE Security Context than the one that was used to protect the corresponding request.¶

This can happen, for instance, when a CoAP client sends a request and, shortly after that, it executes KUDOS. In such a case, the CoAP request is protected with CTX_OLD, while the CoAP response from the server is protected with CTX_NEW. Another case is when incoming responses are Observe notifications protected with CTX_NEW, while the corresponding request from the CoAP client that started the observation was protected with CTX_OLD.¶

Another case is when running KUDOS in the reverse message flow, if the client uses NSTART > 1 and one of its requests triggers a KUDOS execution, i.e., the server replies with the first KUDOS message by acting as responder. The other requests would be latest served by the server after KUDOS has been completed.¶

4.8.2. Communication Overhead

Each of the two KUDOS messages displays a small communication overhead. This is determined by the following, additional information conveyed in the OSCORE option (see Section 4.1).¶

• The second byte of the OSCORE option.¶

• The byte 'x' of the OSCORE option.¶

• The nonce conveyed in the 'nonce' field of the OSCORE option. Its size ranges from 1 to 16 bytes as indicated in the 'x' byte, and is typically of 8 bytes.¶

Assuming nonces of the same size in both messages of the same KUDOS execution, this results in the following minimum, typical, and maximum communication overhead, when considering a nonce with size 1, 8, and 16 bytes, respectively. All the indicated values are in bytes.¶

+-------+---------------------------+---------------------------+
|       | Forward message flow      | Reverse message flow      |
+-------+---------+---------+-------+---------------------------+
| Nonce | First   | Second  | Total | First   | Second  | Total |
| size  | KUDOS   | KUDOS   |       | KUDOS   | KUDOS   |       |
|       | message | message |       | message | message |       |
+-------+---------+---------+-------+---------+---------+-------+
| 1     | 3       | 3       | 6     | 3       | 4       | 7     |
+-------+-------------------+-------+---------+---------+-------+
| 8     | 10      | 10      | 20    | 10      | 11      | 21    |
+-------+---------+-----------------+---------+---------+-------+
| 16    | 18      | 18      | 36    | 18      | 19      | 37    |
+-------+---------+-----------------+---------+---------+-------+

4.8.3. Well-Known KUDOS Resource

According to this specification, KUDOS is transferred in POST requests and 2.04 (Changed) responses. If a client wishes to execute the KUDOS procedure as initiator without triggering any application processing on the server, then the request sent as first KUDOS message must target a KUDOS resource, e.g., at the Uri-Path "/.well-known/kudos" (see Section 6.3), or at an alternative Uri-Path that can be discovered, e.g., by using a resource directory [RFC9176]. In order to discover a server's KUDOS resource, client applications can use the resource type "core.kudos" (see Section 6.4).¶

4.8.4. Rekeying when Using SCHC with OSCORE

In the interest of rekeying, the following points must be taken into account when using the Static Context Header Compression and fragmentation (SCHC) framework [RFC8724] for compressing CoAP messages protected with OSCORE, as defined in [RFC8824].¶

Compression of the OSCORE Partial IV has implications for the frequency of rekeying. That is, if the Partial IV is compressed, the communicating peers must perform rekeying more often, as the available Partial IV space becomes smaller due to the compression. For instance, if only 3 bits of the Partial IV are sent, then the maximum PIV before having to rekey is only 2^3 - 1 = 7.¶

Furthermore, any time the SCHC context Rules are updated on an OSCORE endpoint, that endpoint must perform a rekeying (see Section 9 of [RFC8824]).¶

That is, the use of SCHC plays a role in triggering KUDOS executions and in affecting their cadence. Hence, the used SCHC Rules and their update policies should ensure that the KUDOS executions occurring as their side effect do not significantly impair the gain from message compression.¶