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.

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

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.

                      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.

   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.

   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

   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.

   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)

   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)

   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)

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)

   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)

   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

   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)

   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

   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)

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)

   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)

   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)