Tech-invite3GPPspaceIETF RFCsSIP
93929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 8613

Object Security for Constrained RESTful Environments (OSCORE)

Pages: 94
Proposed Standard
Updates:  7252
Part 5 of 6 – Pages 68 to 86
First   Prev   Next

Top   ToC   RFC8613 - Page 68   prevText

Appendix B. Deployment Examples

For many Internet of Things (IoT) deployments, a 128-bit uniformly random Master Key is sufficient for encrypting all data exchanged with the IoT device throughout its lifetime. Two examples are given in this section. In the first example, the security context is only derived once from the Master Secret. In the second example, security contexts are derived multiple times using random inputs.

B.1. Security Context Derived Once

An application that only derives the security context once needs to handle the loss of mutable security context parameters, e.g., due to reboot.

B.1.1. Sender Sequence Number

In order to handle loss of Sender Sequence Numbers, the device may implement procedures for writing to nonvolatile memory during normal operations and updating the security context after reboot, provided that the procedures comply with the requirements on the security context parameters (Section 3.3). This section gives an example of such a procedure. There are known issues related to writing to nonvolatile memory. For example, flash drives may have a limited number of erase operations during its lifetime. Also, the time for a write operation to nonvolatile memory to be completed may be unpredictable, e.g., due to caching, which could result in important security context data not being stored at the time when the device reboots. However, many devices have predictable limits for writing to nonvolatile memory, are physically limited to only send a small amount of messages per minute, and may have no good source of randomness. To prevent reuse of Sender Sequence Number, an endpoint may perform the following procedure during normal operations: o Before using a Sender Sequence Number that is evenly divisible by K, where K is a positive integer, store the Sender Sequence Number (SSN1) in nonvolatile memory. After booting, the endpoint initiates the new Sender Sequence Number (SSN2) to the value stored in persistent memory plus K plus F: SSN2 = SSN1 + K + F, where F is a positive integer.
Top   ToC   RFC8613 - Page 69
      *  Writing to nonvolatile memory can be costly; the value K gives
         a trade-off between frequency of storage operations and
         efficient use of Sender Sequence Numbers.

      *  Writing to nonvolatile memory may be subject to delays, or
         failure; F MUST be set so that the last Sender Sequence Number
         used before reboot is never larger than SSN2.

   If F cannot be set so SSN2 is always larger than the last Sender
   Sequence Number used before reboot, the method described in this
   section MUST NOT be used.

B.1.2. Replay Window

In case of loss of security context on the server, to prevent accepting replay of previously received requests, the server may perform the following procedure after booting: o The server updates its Sender Sequence Number as specified in Appendix B.1.1 to be used as Partial IV in the response containing the Echo option (next bullet). o For each stored security context, the first time after booting, the server receives an OSCORE request, the server responds with an OSCORE protected 4.01 (Unauthorized), containing only the Echo option [CoAP-ECHO-REQ-TAG] and no diagnostic payload. The server MUST use its Partial IV when generating the AEAD nonce and MUST include the Partial IV in the response (see Section 5). If the server with use of the Echo option can verify a second OSCORE request as fresh, then the Partial IV of the second request is set as the lower limit of the Replay Window of that security context.

B.1.3. Notifications

To prevent the acceptance of replay of previously received notifications, the client may perform the following procedure after booting: o The client forgets about earlier registrations and removes all Notification Numbers. The client then registers again using the Observe option.
Top   ToC   RFC8613 - Page 70

B.2. Security Context Derived Multiple Times

An application that does not require forward secrecy may allow multiple security contexts to be derived from one Master Secret. The requirements on the security context parameters MUST be fulfilled (Section 3.3) even if the client or server is rebooted, recommissioned, or in error cases. This section gives an example of a protocol that adds randomness to the ID Context parameter and uses that together with input parameters preestablished between client and server, in particular Master Secret, Master Salt, and Sender/Recipient ID (see Section 3.2), to derive new security contexts. The random input is transported between client and server in the 'kid context' parameter. This protocol MUST NOT be used unless both endpoints have good sources of randomness. During normal requests, the ID Context of an established security context may be sent in the 'kid context', which, together with 'kid', facilitates for the server to locate a security context. Alternatively, the 'kid context' may be omitted since the ID Context is expected to be known to both client and server; see Section 5.1. The protocol described in this section may only be needed when the mutable part of security context is lost in the client or server, e.g., when the endpoint has rebooted. The protocol may additionally be used whenever the client and server need to derive a new security context. For example, if a device is provisioned with one fixed set of input parameters (including Master Secret, Sender and Recipient Identifiers), then a randomized ID Context ensures that the security context is different for each deployment. Note that the server needs to be configured to run this protocol when it is not able to retrieve an existing security context, instead of stopping processing the message as described in step 2 of Section 8.2. The protocol is described below with reference to Figure 14. The client or the server may initiate the protocol, in the latter case step 1 is omitted.
Top   ToC   RFC8613 - Page 71
                      Client                Server
                        |                      |
1. Protect with         |      request #1      |
   ID Context = ID1     |--------------------->| 2. Verify with
                        |  kid_context = ID1   |    ID Context = ID1
                        |                      |
                        |      response #1     |    Protect with
3. Verify with          |<---------------------|    ID Context = R2||ID1
   ID Context = R2||ID1 |   kid_context = R2   |
                        |                      |
   Protect with         |      request #2      |
   ID Context = R2||R3  |--------------------->| 4. Verify with
                        | kid_context = R2||R3 |    ID Context = R2||R3
                        |                      |
                        |      response #2     |    Protect with
5. Verify with          |<---------------------|    ID Context = R2||R3
   ID Context = R2||R3  |                      |

        Figure 14: Protocol for Establishing a New Security Context

   1.  (Optional) If the client does not have a valid security context
       with the server, e.g., because of reboot or because this is the
       first time it contacts the server, then it generates a random
       string R1 and uses this as ID Context together with the input
       parameters shared with the server to derive a first security
       context.  The client sends an OSCORE request to the server
       protected with the first security context, containing R1 wrapped
       in a CBOR bstr as 'kid context'.  The request may target a
       special resource used for updating security contexts.

   2.  The server receives an OSCORE request for which it does not have
       a valid security context, either because the client has generated
       a new security context ID1 = R1 or because the server has lost
       part of its security context, e.g., ID Context, Sender Sequence
       Number or Replay Window.  If the server is able to verify the
       request (see Section 8.2) with the new derived first security
       context using the received ID1 (transported in 'kid context') as
       ID Context and the input parameters associated to the received
       'kid', then the server generates a random string R2 and derives a
       second security context with ID Context = ID2 = R2 || ID1.  The
       server sends a 4.01 (Unauthorized) response protected with the
       second security context, containing R2 wrapped in a CBOR bstr as
       'kid context', and caches R2.  R2 MUST NOT be reused as that may
       lead to reuse of key and nonce in response #1.  Note that the
       server may receive several requests #1 associated with one
       security context, leading to multiple parallel protocol runs.
       Multiple instances of R2 may need to be cached until one of the
       protocol runs is completed, see Appendix B.2.1.
Top   ToC   RFC8613 - Page 72
   3.  The client receives a response with 'kid context' containing a
       CBOR bstr wrapping R2 to an OSCORE request it made with ID
       Context = ID1.  The client derives a second security context
       using ID Context = ID2 = R2 || ID1.  If the client can verify the
       response (see Section 8.4) using the second security context,
       then the client makes a request protected with a third security
       context derived from ID Context = ID3 = R2 || R3, where R3 is a
       random byte string generated by the client.  The request includes
       R2 || R3 wrapped in a CBOR bstr as 'kid context'.

   4.  If the server receives a request with 'kid context' containing a
       CBOR bstr wrapping ID3, where the first part of ID3 is identical
       to an R2 sent in a previous response #1, which it has not
       received before, then the server derives a third security context
       with ID Context = ID3.  The server MUST NOT accept replayed
       request #2 messages.  If the server can verify the request (see
       Section 8.2) with the third security context, then the server
       marks the third security context to be used with this client and
       removes all instances of R2 associated to this security context
       from the cache.  This security context replaces the previous
       security context with the client, and the first and the second
       security contexts are deleted.  The server responds using the
       same security context as in the request.

   5.  If the client receives a response to the request with the third
       security context and the response verifies (see Section 8.4),
       then the client marks the third security context to be used with
       this server.  This security context replaces the previous
       security context with the server, and the first and second
       security contexts are deleted.

   If verification fails in any step, the endpoint stops processing that
   message.

   The length of the nonces R1, R2, and R3 is application specific.  The
   application needs to set the length of each nonce such that the
   probability of its value being repeated is negligible; typically, at
   least 8 bytes long.  Since R2 may be generated as the result of a
   replayed request #1, the probability for collision of R2s is impacted
   by the birthday paradox.  For example, setting the length of R2 to 8
   bytes results in an average collision after 2^32 response #1
   messages, which should not be an issue for a constrained server
   handling on the order of one request per second.
Top   ToC   RFC8613 - Page 73
   Request #2 can be an ordinary request.  The server performs the
   action of the request and sends response #2 after having successfully
   completed the operations related to the security context in step 4.
   The client acts on response #2 after having successfully completed
   step 5.

   When sending request #2, the client is assured that the Sender Key
   (derived with the random value R3) has never been used before.  When
   receiving response #2, the client is assured that the response
   (protected with a key derived from the random value R3 and the Master
   Secret) was created by the server in response to request #2.

   Similarly, when receiving request #2, the server is assured that the
   request (protected with a key derived from the random value R2 and
   the Master Secret) was created by the client in response to response
   #1.  When sending response #2, the server is assured that the Sender
   Key (derived with the random value R2) has never been used before.

   Implementation and denial-of-service considerations are made in
   Appendix B.2.1 and Appendix B.2.2.

B.2.1. Implementation Considerations

This section add some implementation considerations to the protocol described in the previous section. The server may only have space for a few security contexts or only be able to handle a few protocol runs in parallel. The server may legitimately receive multiple request #1 messages using the same immutable security context, e.g., because of packet loss. Replays of old request #1 messages could be difficult for the server to distinguish from legitimate. The server needs to handle the case when the maximum number of cached R2s is reached. If the server receives a request #1 and is not capable of executing it then it may respond with an unprotected 5.03 (Service Unavailable) error message. The server may clear up state from protocol runs that never complete, e.g., set a timer when caching R2, and remove R2 and the associated security contexts from the cache at timeout. Additionally, state information can be flushed at reboot. As an alternative to caching R2, the server could generate R2 in such a way that it can be sent (in response #1) and verified (at reception of request #2) as the value of R2 it had generated. Such a procedure MUST NOT lead to the server accepting replayed request #2 messages. One construction described in the following is based on using a secret random HMAC key K_HMAC per set of immutable security context parameters associated with a client. This construction allows the
Top   ToC   RFC8613 - Page 74
   server to handle verification of R2 in response #2 at the cost of
   storing the K_HMAC keys and a slightly larger message overhead in
   response #1.  Steps below refer to modifications to Appendix B.2:

   o  In step 2, R2 is generated in the following way.  First, the
      server generates a random K_HMAC (unless it already has one
      associated with the security context), then it sets R2 = S2 ||
      HMAC(K_HMAC, S2) where S2 is a random byte string, and the HMAC is
      truncated to 8 bytes.  K_HMAC may have an expiration time, after
      which it is erased.  Note that neither R2, S2, nor the derived
      first and second security contexts need to be cached.

   o  In step 4, instead of verifying that R2 coincides with a cached
      value, the server looks up the associated K_HMAC and verifies the
      truncated HMAC, and the processing continues accordingly depending
      on verification success or failure.  K_HMAC is used until a run of
      the protocol is completed (after verification of request #2), or
      until it expires (whatever comes first), after which K_HMAC is
      erased.  (The latter corresponds to removing the cached values of
      R2 in step 4 of Appendix B.2 and makes the server reject replays
      of request #2.)

   The length of S2 is application specific and the probability for
   collision of S2s is impacted by the birthday paradox.  For example,
   setting the length of S2 to 8 bytes results in an average collision
   after 2^32 response #1 messages, which should not be an issue for a
   constrained server handling on the order of one request per second.

   Two endpoints sharing a security context may accidentally initiate
   two instances of the protocol at the same time, each in the role of
   client, e.g., after a power outage affecting both endpoints.  Such a
   race condition could potentially lead to both protocols failing, and
   both endpoints repeatedly reinitiating the protocol without
   converging.  Both endpoints can detect this situation, and it can be
   handled in different ways.  The requests could potentially be more
   spread out in time, for example, by only initiating this protocol
   when the endpoint actually needs to make a request, potentially
   adding a random delay before requests immediately after reboot or if
   such parallel protocol runs are detected.

B.2.2. Attack Considerations

An on-path attacker may inject a message causing the endpoint to process verification of the message. A message crafted without access to the Master Secret will fail to verify.
Top   ToC   RFC8613 - Page 75
   Replaying an old request with a value of 'kid_context' that the
   server does not recognize could trigger the protocol.  This causes
   the server to generate the first and second security context and send
   a response.  But if the client did not expect a response, it will be
   discarded.  This may still result in a denial-of-service attack
   against the server, e.g., because of not being able to manage the
   state associated with many parallel protocol runs, and it may prevent
   legitimate client requests.  Implementation alternatives with less
   data caching per request #1 message are favorable in this respect;
   see Appendix B.2.1.

   Replaying response #1 in response to some request other than request
   #1 will fail to verify, since response #1 is associated to request
   #1, through the dependencies of ID Contexts and the Partial IV of
   request #1 included in the external_aad of response #1.

   If request #2 has already been well received, then the server has a
   valid security context, so a replay of request #2 is handled by the
   normal replay protection mechanism.  Similarly, if response #2 has
   already been received, a replay of response #2 to some other request
   from the client will fail by the normal verification of binding of
   response to request.

Appendix C. Test Vectors

This appendix includes the test vectors for different examples of CoAP messages using OSCORE. Given a set of inputs, OSCORE defines how to set up the Security Context in both the client and the server. Note that in Appendix C.4 and all following test vectors the Token and the Message ID of the OSCORE-protected CoAP messages are set to the same value of the unprotected CoAP message to help the reader with comparisons.

C.1. Test Vector 1: Key Derivation with Master Salt

In this test vector, a Master Salt of 8 bytes is used. The default values are used for AEAD Algorithm and HKDF.

C.1.1. Client

Inputs: o Master Secret: 0x0102030405060708090a0b0c0d0e0f10 (16 bytes) o Master Salt: 0x9e7ca92223786340 (8 bytes) o Sender ID: 0x (0 byte)
Top   ToC   RFC8613 - Page 76
   o  Recipient ID: 0x01 (1 byte)

   From the previous parameters,

   o  info (for Sender Key): 0x8540f60a634b657910 (9 bytes)

   o  info (for Recipient Key): 0x854101f60a634b657910 (10 bytes)

   o  info (for Common IV): 0x8540f60a6249560d (8 bytes)

   Outputs:

   o  Sender Key: 0xf0910ed7295e6ad4b54fc793154302ff (16 bytes)

   o  Recipient Key: 0xffb14e093c94c9cac9471648b4f98710 (16 bytes)

   o  Common IV: 0x4622d4dd6d944168eefb54987c (13 bytes)

   From the previous parameters and a Partial IV equal to 0 (both for
   sender and recipient):

   o  sender nonce: 0x4622d4dd6d944168eefb54987c (13 bytes)

   o  recipient nonce: 0x4722d4dd6d944169eefb54987c (13 bytes)

C.1.2. Server

Inputs: o Master Secret: 0x0102030405060708090a0b0c0d0e0f10 (16 bytes) o Master Salt: 0x9e7ca92223786340 (8 bytes) o Sender ID: 0x01 (1 byte) o Recipient ID: 0x (0 byte) From the previous parameters, o info (for Sender Key): 0x854101f60a634b657910 (10 bytes) o info (for Recipient Key): 0x8540f60a634b657910 (9 bytes) o info (for Common IV): 0x8540f60a6249560d (8 bytes) Outputs: o Sender Key: 0xffb14e093c94c9cac9471648b4f98710 (16 bytes)
Top   ToC   RFC8613 - Page 77
   o  Recipient Key: 0xf0910ed7295e6ad4b54fc793154302ff (16 bytes)

   o  Common IV: 0x4622d4dd6d944168eefb54987c (13 bytes)

   From the previous parameters and a Partial IV equal to 0 (both for
   sender and recipient):

   o  sender nonce: 0x4722d4dd6d944169eefb54987c (13 bytes)

   o  recipient nonce: 0x4622d4dd6d944168eefb54987c (13 bytes)

C.2. Test Vector 2: Key Derivation without Master Salt

In this test vector, the default values are used for AEAD Algorithm, HKDF, and Master Salt.

C.2.1. Client

Inputs: o Master Secret: 0x0102030405060708090a0b0c0d0e0f10 (16 bytes) o Sender ID: 0x00 (1 byte) o Recipient ID: 0x01 (1 byte) From the previous parameters, o info (for Sender Key): 0x854100f60a634b657910 (10 bytes) o info (for Recipient Key): 0x854101f60a634b657910 (10 bytes) o info (for Common IV): 0x8540f60a6249560d (8 bytes) Outputs: o Sender Key: 0x321b26943253c7ffb6003b0b64d74041 (16 bytes) o Recipient Key: 0xe57b5635815177cd679ab4bcec9d7dda (16 bytes) o Common IV: 0xbe35ae297d2dace910c52e99f9 (13 bytes) From the previous parameters and a Partial IV equal to 0 (both for sender and recipient): o sender nonce: 0xbf35ae297d2dace910c52e99f9 (13 bytes) o recipient nonce: 0xbf35ae297d2dace810c52e99f9 (13 bytes)
Top   ToC   RFC8613 - Page 78

C.2.2. Server

Inputs: o Master Secret: 0x0102030405060708090a0b0c0d0e0f10 (16 bytes) o Sender ID: 0x01 (1 byte) o Recipient ID: 0x00 (1 byte) From the previous parameters, o info (for Sender Key): 0x854101f60a634b657910 (10 bytes) o info (for Recipient Key): 0x854100f60a634b657910 (10 bytes) o info (for Common IV): 0x8540f60a6249560d (8 bytes) Outputs: o Sender Key: 0xe57b5635815177cd679ab4bcec9d7dda (16 bytes) o Recipient Key: 0x321b26943253c7ffb6003b0b64d74041 (16 bytes) o Common IV: 0xbe35ae297d2dace910c52e99f9 (13 bytes) From the previous parameters and a Partial IV equal to 0 (both for sender and recipient): o sender nonce: 0xbf35ae297d2dace810c52e99f9 (13 bytes) o recipient nonce: 0xbf35ae297d2dace910c52e99f9 (13 bytes)

C.3. Test Vector 3: Key Derivation with ID Context

In this test vector, a Master Salt of 8 bytes and an ID Context of 8 bytes are used. The default values are used for AEAD Algorithm and HKDF.

C.3.1. Client

Inputs: o Master Secret: 0x0102030405060708090a0b0c0d0e0f10 (16 bytes) o Master Salt: 0x9e7ca92223786340 (8 bytes) o Sender ID: 0x (0 byte)
Top   ToC   RFC8613 - Page 79
   o  Recipient ID: 0x01 (1 byte)

   o  ID Context: 0x37cbf3210017a2d3 (8 bytes)

   From the previous parameters,

   o  info (for Sender Key): 0x85404837cbf3210017a2d30a634b657910 (17
      bytes)

   o  info (for Recipient Key): 0x8541014837cbf3210017a2d30a634b657910
      (18 bytes)

   o  info (for Common IV): 0x85404837cbf3210017a2d30a6249560d (16
      bytes)

   Outputs:

   o  Sender Key: 0xaf2a1300a5e95788b356336eeecd2b92 (16 bytes)

   o  Recipient Key: 0xe39a0c7c77b43f03b4b39ab9a268699f (16 bytes)

   o  Common IV: 0x2ca58fb85ff1b81c0b7181b85e (13 bytes)

   From the previous parameters and a Partial IV equal to 0 (both for
   sender and recipient):

   o  sender nonce: 0x2ca58fb85ff1b81c0b7181b85e (13 bytes)

   o  recipient nonce: 0x2da58fb85ff1b81d0b7181b85e (13 bytes)

C.3.2. Server

Inputs: o Master Secret: 0x0102030405060708090a0b0c0d0e0f10 (16 bytes) o Master Salt: 0x9e7ca92223786340 (8 bytes) o Sender ID: 0x01 (1 byte) o Recipient ID: 0x (0 byte) o ID Context: 0x37cbf3210017a2d3 (8 bytes) From the previous parameters, o info (for Sender Key): 0x8541014837cbf3210017a2d30a634b657910 (18 bytes)
Top   ToC   RFC8613 - Page 80
   o  info (for Recipient Key): 0x85404837cbf3210017a2d30a634b657910 (17
      bytes)

   o  info (for Common IV): 0x85404837cbf3210017a2d30a6249560d (16
      bytes)

   Outputs:

   o  Sender Key: 0xe39a0c7c77b43f03b4b39ab9a268699f (16 bytes)

   o  Recipient Key: 0xaf2a1300a5e95788b356336eeecd2b92 (16 bytes)

   o  Common IV: 0x2ca58fb85ff1b81c0b7181b85e (13 bytes)

   From the previous parameters and a Partial IV equal to 0 (both for
   sender and recipient):

   o  sender nonce: 0x2da58fb85ff1b81d0b7181b85e (13 bytes)

   o  recipient nonce: 0x2ca58fb85ff1b81c0b7181b85e (13 bytes)

C.4. Test Vector 4: OSCORE Request, Client

This section contains a test vector for an OSCORE-protected CoAP GET request using the security context derived in Appendix C.1. The unprotected request only contains the Uri-Path and Uri-Host options. Unprotected CoAP request: 0x44015d1f00003974396c6f63616c686f737483747631 (22 bytes) Common Context: o AEAD Algorithm: 10 (AES-CCM-16-64-128) o Key Derivation Function: HKDF SHA-256 o Common IV: 0x4622d4dd6d944168eefb54987c (13 bytes) Sender Context: o Sender ID: 0x (0 byte) o Sender Key: 0xf0910ed7295e6ad4b54fc793154302ff (16 bytes) o Sender Sequence Number: 20
Top   ToC   RFC8613 - Page 81
   The following COSE and cryptographic parameters are derived:

   o  Partial IV: 0x14 (1 byte)

   o  kid: 0x (0 byte)

   o  aad_array: 0x8501810a40411440 (8 bytes)

   o  AAD: 0x8368456e63727970743040488501810a40411440 (20 bytes)

   o  plaintext: 0x01b3747631 (5 bytes)

   o  encryption key: 0xf0910ed7295e6ad4b54fc793154302ff (16 bytes)

   o  nonce: 0x4622d4dd6d944168eefb549868 (13 bytes)

   From the previous parameter, the following is derived:

   o  OSCORE option value: 0x0914 (2 bytes)

   o  ciphertext: 0x612f1092f1776f1c1668b3825e (13 bytes)

   From there:

   o  Protected CoAP request (OSCORE message): 0x44025d1f00003974396c6f6
      3616c686f7374620914ff612f1092f1776f1c1668b3825e (35 bytes)

C.5. Test Vector 5: OSCORE Request, Client

This section contains a test vector for an OSCORE-protected CoAP GET request using the security context derived in Appendix C.2. The unprotected request only contains the Uri-Path and Uri-Host options. Unprotected CoAP request: 0x440171c30000b932396c6f63616c686f737483747631 (22 bytes) Common Context: o AEAD Algorithm: 10 (AES-CCM-16-64-128) o Key Derivation Function: HKDF SHA-256 o Common IV: 0xbe35ae297d2dace910c52e99f9 (13 bytes) Sender Context: o Sender ID: 0x00 (1 bytes)
Top   ToC   RFC8613 - Page 82
   o  Sender Key: 0x321b26943253c7ffb6003b0b64d74041 (16 bytes)

   o  Sender Sequence Number: 20

   The following COSE and cryptographic parameters are derived:

   o  Partial IV: 0x14 (1 byte)

   o  kid: 0x00 (1 byte)

   o  aad_array: 0x8501810a4100411440 (9 bytes)

   o  AAD: 0x8368456e63727970743040498501810a4100411440 (21 bytes)

   o  plaintext: 0x01b3747631 (5 bytes)

   o  encryption key: 0x321b26943253c7ffb6003b0b64d74041 (16 bytes)

   o  nonce: 0xbf35ae297d2dace910c52e99ed (13 bytes)

   From the previous parameter, the following is derived:

   o  OSCORE option value: 0x091400 (3 bytes)

   o  ciphertext: 0x4ed339a5a379b0b8bc731fffb0 (13 bytes)

   From there:

   o  Protected CoAP request (OSCORE message): 0x440271c30000b932396c6f6
      3616c686f737463091400ff4ed339a5a379b0b8bc731fffb0 (36 bytes)

C.6. Test Vector 6: OSCORE Request, Client

This section contains a test vector for an OSCORE-protected CoAP GET request for an application that sets the ID Context and requires it to be sent in the request, so 'kid context' is present in the protected message. This test vector uses the security context derived in Appendix C.3. The unprotected request only contains the Uri-Path and Uri-Host options. Unprotected CoAP request: 0x44012f8eef9bbf7a396c6f63616c686f737483747631 (22 bytes) Common Context: o AEAD Algorithm: 10 (AES-CCM-16-64-128) o Key Derivation Function: HKDF SHA-256
Top   ToC   RFC8613 - Page 83
   o  Common IV: 0x2ca58fb85ff1b81c0b7181b85e (13 bytes)

   o  ID Context: 0x37cbf3210017a2d3 (8 bytes)

   Sender Context:

   o  Sender ID: 0x (0 bytes)

   o  Sender Key: 0xaf2a1300a5e95788b356336eeecd2b92 (16 bytes)

   o  Sender Sequence Number: 20

   The following COSE and cryptographic parameters are derived:

   o  Partial IV: 0x14 (1 byte)

   o  kid: 0x (0 byte)

   o  kid context: 0x37cbf3210017a2d3 (8 bytes)

   o  aad_array: 0x8501810a40411440 (8 bytes)

   o  AAD: 0x8368456e63727970743040488501810a40411440 (20 bytes)

   o  plaintext: 0x01b3747631 (5 bytes)

   o  encryption key: 0xaf2a1300a5e95788b356336eeecd2b92 (16 bytes)

   o  nonce: 0x2ca58fb85ff1b81c0b7181b84a (13 bytes)

   From the previous parameter, the following is derived:

   o  OSCORE option value: 0x19140837cbf3210017a2d3 (11 bytes)

   o  ciphertext: 0x72cd7273fd331ac45cffbe55c3 (13 bytes)

   From there:

   o  Protected CoAP request (OSCORE message):
      0x44022f8eef9bbf7a396c6f63616c686f73746b19140837cbf3210017a2d3ff
      72cd7273fd331ac45cffbe55c3 (44 bytes)
Top   ToC   RFC8613 - Page 84

C.7. Test Vector 7: OSCORE Response, Server

This section contains a test vector for an OSCORE-protected 2.05 (Content) response to the request in Appendix C.4. The unprotected response has payload "Hello World!" and no options. The protected response does not contain a 'kid' nor a Partial IV. Note that some parameters are derived from the request. Unprotected CoAP response: 0x64455d1f00003974ff48656c6c6f20576f726c6421 (21 bytes) Common Context: o AEAD Algorithm: 10 (AES-CCM-16-64-128) o Key Derivation Function: HKDF SHA-256 o Common IV: 0x4622d4dd6d944168eefb54987c (13 bytes) Sender Context: o Sender ID: 0x01 (1 byte) o Sender Key: 0xffb14e093c94c9cac9471648b4f98710 (16 bytes) o Sender Sequence Number: 0 The following COSE and cryptographic parameters are derived: o aad_array: 0x8501810a40411440 (8 bytes) o AAD: 0x8368456e63727970743040488501810a40411440 (20 bytes) o plaintext: 0x45ff48656c6c6f20576f726c6421 (14 bytes) o encryption key: 0xffb14e093c94c9cac9471648b4f98710 (16 bytes) o nonce: 0x4622d4dd6d944168eefb549868 (13 bytes) From the previous parameter, the following is derived: o OSCORE option value: 0x (0 bytes) o ciphertext: 0xdbaad1e9a7e7b2a813d3c31524378303cdafae119106 (22 bytes)
Top   ToC   RFC8613 - Page 85
   From there:

   o  Protected CoAP response (OSCORE message):
      0x64445d1f0000397490ffdbaad1e9a7e7b2a813d3c31524378303cdafae119106
      (32 bytes)

C.8. Test Vector 8: OSCORE Response with Partial IV, Server

This section contains a test vector for an OSCORE protected 2.05 (Content) response to the request in Appendix C.4. The unprotected response has payload "Hello World!" and no options. The protected response does not contain a 'kid', but contains a Partial IV. Note that some parameters are derived from the request. Unprotected CoAP response: 0x64455d1f00003974ff48656c6c6f20576f726c6421 (21 bytes) Common Context: o AEAD Algorithm: 10 (AES-CCM-16-64-128) o Key Derivation Function: HKDF SHA-256 o Common IV: 0x4622d4dd6d944168eefb54987c (13 bytes) Sender Context: o Sender ID: 0x01 (1 byte) o Sender Key: 0xffb14e093c94c9cac9471648b4f98710 (16 bytes) o Sender Sequence Number: 0 The following COSE and cryptographic parameters are derived: o Partial IV: 0x00 (1 byte) o aad_array: 0x8501810a40411440 (8 bytes) o AAD: 0x8368456e63727970743040488501810a40411440 (20 bytes) o plaintext: 0x45ff48656c6c6f20576f726c6421 (14 bytes) o encryption key: 0xffb14e093c94c9cac9471648b4f98710 (16 bytes) o nonce: 0x4722d4dd6d944169eefb54987c (13 bytes)
Top   ToC   RFC8613 - Page 86
   From the previous parameter, the following is derived:

   o  OSCORE option value: 0x0100 (2 bytes)

   o  ciphertext: 0x4d4c13669384b67354b2b6175ff4b8658c666a6cf88e (22
      bytes)

   From there:

   o  Protected CoAP response (OSCORE message): 0x64445d1f00003974920100
      ff4d4c13669384b67354b2b6175ff4b8658c666a6cf88e (34 bytes)



(page 86 continued on part 6)

Next Section