Tech-invite   3GPPspecs   Glossaries   IETFRFCs   Groups   SIP   ABNFs   Ti+   Search in Tech-invite

in Index   Prev   Next
in Index   Prev   None  Group: CORE

RFC 8613

Object Security for Constrained RESTful Environments (OSCORE)

Pages: 94
Proposed STD
Updates:  7252
Part 1 of 6 – Pages 1 to 14
None   None   Next

Top   ToC   RFC8613 - Page 1
Internet Engineering Task Force (IETF)                       G. Selander
Request for Comments: 8613                                   J. Mattsson
Updates: 7252                                               F. Palombini
Category: Standards Track                                    Ericsson AB
ISSN: 2070-1721                                                 L. Seitz
                                                                    RISE
                                                               July 2019


     Object Security for Constrained RESTful Environments (OSCORE)

Abstract

   This document defines Object Security for Constrained RESTful
   Environments (OSCORE), a method for application-layer protection of
   the Constrained Application Protocol (CoAP), using CBOR Object
   Signing and Encryption (COSE).  OSCORE provides end-to-end protection
   between endpoints communicating using CoAP or CoAP-mappable HTTP.
   OSCORE is designed for constrained nodes and networks supporting a
   range of proxy operations, including translation between different
   transport protocols.

   Although an optional functionality of CoAP, OSCORE alters CoAP
   options processing and IANA registration.  Therefore, this document
   updates RFC 7252.

Status of This Memo

   This is an Internet Standards Track document.

   This document is a product of the Internet Engineering Task Force
   (IETF).  It represents the consensus of the IETF community.  It has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Further information on
   Internet Standards is available in Section 2 of RFC 7841.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   https://www.rfc-editor.org/info/rfc8613.
Top   ToC   RFC8613 - Page 2
Copyright Notice

   Copyright (c) 2019 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (https://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.
Top   ToC   RFC8613 - Page 3
Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   5
     1.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   7
   2.  The OSCORE Option . . . . . . . . . . . . . . . . . . . . . .   8
   3.  The Security Context  . . . . . . . . . . . . . . . . . . . .   8
     3.1.  Security Context Definition . . . . . . . . . . . . . . .   9
     3.2.  Establishment of Security Context Parameters  . . . . . .  11
     3.3.  Requirements on the Security Context Parameters . . . . .  14
   4.  Protected Message Fields  . . . . . . . . . . . . . . . . . .  15
     4.1.  CoAP Options  . . . . . . . . . . . . . . . . . . . . . .  16
     4.2.  CoAP Header Fields and Payload  . . . . . . . . . . . . .  24
     4.3.  Signaling Messages  . . . . . . . . . . . . . . . . . . .  25
   5.  The COSE Object . . . . . . . . . . . . . . . . . . . . . . .  26
     5.1.  ID Context and 'kid context'  . . . . . . . . . . . . . .  27
     5.2.  AEAD Nonce  . . . . . . . . . . . . . . . . . . . . . . .  28
     5.3.  Plaintext . . . . . . . . . . . . . . . . . . . . . . . .  29
     5.4.  Additional Authenticated Data . . . . . . . . . . . . . .  30
   6.  OSCORE Header Compression . . . . . . . . . . . . . . . . . .  31
     6.1.  Encoding of the OSCORE Option Value . . . . . . . . . . .  32
     6.2.  Encoding of the OSCORE Payload  . . . . . . . . . . . . .  33
     6.3.  Examples of Compressed COSE Objects . . . . . . . . . . .  33
   7.  Message Binding, Sequence Numbers, Freshness, and Replay
       Protection  . . . . . . . . . . . . . . . . . . . . . . . . .  36
     7.1.  Message Binding . . . . . . . . . . . . . . . . . . . . .  36
     7.2.  Sequence Numbers  . . . . . . . . . . . . . . . . . . . .  36
     7.3.  Freshness . . . . . . . . . . . . . . . . . . . . . . . .  36
     7.4.  Replay Protection . . . . . . . . . . . . . . . . . . . .  37
     7.5.  Losing Part of the Context State  . . . . . . . . . . . .  38
   8.  Processing  . . . . . . . . . . . . . . . . . . . . . . . . .  39
     8.1.  Protecting the Request  . . . . . . . . . . . . . . . . .  39
     8.2.  Verifying the Request . . . . . . . . . . . . . . . . . .  40
     8.3.  Protecting the Response . . . . . . . . . . . . . . . . .  41
     8.4.  Verifying the Response  . . . . . . . . . . . . . . . . .  43
   9.  Web Linking . . . . . . . . . . . . . . . . . . . . . . . . .  44
   10. CoAP-to-CoAP Forwarding Proxy . . . . . . . . . . . . . . . .  45
   11. HTTP Operations . . . . . . . . . . . . . . . . . . . . . . .  46
     11.1.  The HTTP OSCORE Header Field . . . . . . . . . . . . . .  46
     11.2.  CoAP-to-HTTP Mapping . . . . . . . . . . . . . . . . . .  47
     11.3.  HTTP-to-CoAP Mapping . . . . . . . . . . . . . . . . . .  48
     11.4.  HTTP Endpoints . . . . . . . . . . . . . . . . . . . . .  48
     11.5.  Example: HTTP Client and CoAP Server . . . . . . . . . .  48
     11.6.  Example: CoAP Client and HTTP Server . . . . . . . . . .  50
   12. Security Considerations . . . . . . . . . . . . . . . . . . .  51
     12.1.  End-to-end Protection  . . . . . . . . . . . . . . . . .  51
     12.2.  Security Context Establishment . . . . . . . . . . . . .  52
     12.3.  Master Secret  . . . . . . . . . . . . . . . . . . . . .  52
     12.4.  Replay Protection  . . . . . . . . . . . . . . . . . . .  53
Top   ToC   RFC8613 - Page 4
     12.5.  Client Aliveness . . . . . . . . . . . . . . . . . . . .  53
     12.6.  Cryptographic Considerations . . . . . . . . . . . . . .  53
     12.7.  Message Segmentation . . . . . . . . . . . . . . . . . .  54
     12.8.  Privacy Considerations . . . . . . . . . . . . . . . . .  54
   13. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  55
     13.1.  COSE Header Parameters Registry  . . . . . . . . . . . .  55
     13.2.  CoAP Option Numbers Registry . . . . . . . . . . . . . .  55
     13.3.  CoAP Signaling Option Numbers Registry . . . . . . . . .  56
     13.4.  Header Field Registrations . . . . . . . . . . . . . . .  57
     13.5.  Media Type Registration  . . . . . . . . . . . . . . . .  57
     13.6.  CoAP Content-Formats Registry  . . . . . . . . . . . . .  58
     13.7.  OSCORE Flag Bits Registry  . . . . . . . . . . . . . . .  58
     13.8.  Expert Review Instructions . . . . . . . . . . . . . . .  59
   14. References  . . . . . . . . . . . . . . . . . . . . . . . . .  60
     14.1.  Normative References . . . . . . . . . . . . . . . . . .  60
     14.2.  Informative References . . . . . . . . . . . . . . . . .  62
   Appendix A.  Scenario Examples  . . . . . . . . . . . . . . . . .  65
     A.1.  Secure Access to Sensor . . . . . . . . . . . . . . . . .  65
     A.2.  Secure Subscribe to Sensor  . . . . . . . . . . . . . . .  66
   Appendix B.  Deployment Examples  . . . . . . . . . . . . . . . .  68
     B.1.  Security Context Derived Once . . . . . . . . . . . . . .  68
     B.2.  Security Context Derived Multiple Times . . . . . . . . .  70
   Appendix C.  Test Vectors . . . . . . . . . . . . . . . . . . . .  75
     C.1.  Test Vector 1: Key Derivation with Master Salt  . . . . .  75
     C.2.  Test Vector 2: Key Derivation without Master Salt . . . .  77
     C.3.  Test Vector 3: Key Derivation with ID Context . . . . . .  78
     C.4.  Test Vector 4: OSCORE Request, Client . . . . . . . . . .  80
     C.5.  Test Vector 5: OSCORE Request, Client . . . . . . . . . .  81
     C.6.  Test Vector 6: OSCORE Request, Client . . . . . . . . . .  82
     C.7.  Test Vector 7: OSCORE Response, Server  . . . . . . . . .  84
     C.8.  Test Vector 8: OSCORE Response with Partial IV, Server  .  85
   Appendix D.  Overview of Security Properties  . . . . . . . . . .  86
     D.1.  Threat Model  . . . . . . . . . . . . . . . . . . . . . .  86
     D.2.  Supporting Proxy Operations . . . . . . . . . . . . . . .  87
     D.3.  Protected Message Fields  . . . . . . . . . . . . . . . .  87
     D.4.  Uniqueness of (key, nonce)  . . . . . . . . . . . . . . .  88
     D.5.  Unprotected Message Fields  . . . . . . . . . . . . . . .  89
   Appendix E.  CDDL Summary . . . . . . . . . . . . . . . . . . . .  93
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  94
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  94
Top   ToC   RFC8613 - Page 5
1.  Introduction

   The Constrained Application Protocol (CoAP) [RFC7252] is a web
   transfer protocol designed for constrained nodes and networks
   [RFC7228]; CoAP may be mapped from HTTP [RFC8075].  CoAP specifies
   the use of proxies for scalability and efficiency and references DTLS
   [RFC6347] for security.  CoAP-to-CoAP, HTTP-to-CoAP, and CoAP-to-HTTP
   proxies require DTLS or TLS [RFC8446] to be terminated at the proxy.
   Therefore, the proxy not only has access to the data required for
   performing the intended proxy functionality, but is also able to
   eavesdrop on, or manipulate any part of, the message payload and
   metadata in transit between the endpoints.  The proxy can also
   inject, delete, or reorder packets since they are no longer protected
   by (D)TLS.

   This document defines the Object Security for Constrained RESTful
   Environments (OSCORE) security protocol, protecting CoAP and CoAP-
   mappable HTTP requests and responses end-to-end across intermediary
   nodes such as CoAP forward proxies and cross-protocol translators
   including HTTP-to-CoAP proxies [RFC8075].  In addition to the core
   CoAP features defined in [RFC7252], OSCORE supports the Observe
   [RFC7641], Block-wise [RFC7959], and No-Response [RFC7967] options,
   as well as the PATCH and FETCH methods [RFC8132].  An analysis of
   end-to-end security for CoAP messages through some types of
   intermediary nodes is performed in [CoAP-E2E-Sec].  OSCORE
   essentially protects the RESTful interactions: the request method,
   the requested resource, the message payload, etc. (see Section 4),
   where "RESTful" refers to the Representational State Transfer (REST)
   Architecture [REST].  OSCORE protects neither the CoAP messaging
   layer nor the CoAP Token, which may change between the endpoints;
   therefore, those are processed as defined in [RFC7252].
   Additionally, since the message formats for CoAP over unreliable
   transport [RFC7252] and for CoAP over reliable transport [RFC8323]
   differ only in terms of CoAP messaging layer, OSCORE can be applied
   to both unreliable and reliable transports (see Figure 1).

   OSCORE works in very constrained nodes and networks, thanks to its
   small message size and the restricted code and memory requirements in
   addition to what is required by CoAP.  Examples of the use of OSCORE
   are given in Appendix A.  OSCORE may be used over any underlying
   layer, such as UDP or TCP, and with non-IP transports (e.g.,
   [CoAP-802.15.4]).  OSCORE may also be used in different ways with
   HTTP.  OSCORE messages may be transported in HTTP, and OSCORE may
   also be used to protect CoAP-mappable HTTP messages, as described
   below.
Top   ToC   RFC8613 - Page 6
               +-----------------------------------+
               |            Application            |
               +-----------------------------------+
               +-----------------------------------+  \
               |  Requests / Responses / Signaling |  |
               |-----------------------------------|  |
               |               OSCORE              |  | CoAP
               |-----------------------------------|  |
               | Messaging Layer / Message Framing |  |
               +-----------------------------------+  /
               +-----------------------------------+
               |          UDP / TCP / ...          |
               +-----------------------------------+

              Figure 1: Abstract Layering of CoAP with OSCORE

   OSCORE is designed to protect as much information as possible while
   still allowing CoAP proxy operations (Section 10).  It works with
   existing CoAP-to-CoAP forward proxies [RFC7252], but an OSCORE-aware
   proxy will be more efficient.  HTTP-to-CoAP proxies [RFC8075] and
   CoAP-to-HTTP proxies can also be used with OSCORE, as specified in
   Section 11.  OSCORE may be used together with TLS or DTLS over one or
   more hops in the end-to-end path, e.g., transported with HTTPS in one
   hop and with plain CoAP in another hop.  The use of OSCORE does not
   affect the URI scheme; therefore, OSCORE can be used with any URI
   scheme defined for CoAP or HTTP.  The application decides the
   conditions for which OSCORE is required.

   OSCORE uses pre-shared keys that may have been established out-of-
   band or with a key establishment protocol (see Section 3.2).  The
   technical solution builds on CBOR Object Signing and Encryption
   (COSE) [RFC8152], providing end-to-end encryption, integrity, replay
   protection, and binding of response to request.  A compressed version
   of COSE is used, as specified in Section 6.  The use of OSCORE is
   signaled in CoAP with a new option (Section 2), and in HTTP with a
   new header field (Section 11.1) and content type (Section 13.5).  The
   solution transforms a CoAP/HTTP message into an "OSCORE message"
   before sending, and vice versa after receiving.  The OSCORE message
   is a CoAP/HTTP message related to the original message in the
   following way: the original CoAP/HTTP message is translated to CoAP
   (if not already in CoAP) and protected in a COSE object.  The
   encrypted message fields of this COSE object are transported in the
   CoAP payload/HTTP body of the OSCORE message, and the OSCORE option/
   header field is included in the message.  A sketch of an exchange of
   OSCORE messages, in the case of the original message being CoAP, is
   provided in Figure 2.  The use of OSCORE with HTTP is detailed in
   Section 11.
Top   ToC   RFC8613 - Page 7
          Client                                          Server
             |      OSCORE request - POST example.com:      |
             |        Header, Token,                        |
             |        Options: OSCORE, ...,                 |
             |        Payload: COSE ciphertext              |
             +--------------------------------------------->|
             |                                              |
             |<---------------------------------------------+
             |      OSCORE response - 2.04 (Changed):       |
             |        Header, Token,                        |
             |        Options: OSCORE, ...,                 |
             |        Payload: COSE ciphertext              |
             |                                              |

                   Figure 2: Sketch of CoAP with OSCORE

   An implementation supporting this specification MAY implement only
   the client part, MAY implement only the server part, or MAY implement
   only one of the proxy parts.

1.1.  Terminology

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

   Readers are expected to be familiar with the terms and concepts
   described in CoAP [RFC7252], COSE [RFC8152], Concise Binary Object
   Representation (CBOR) [RFC7049], Concise Data Definition Language
   (CDDL) [RFC8610] as summarized in Appendix E, and constrained
   environments [RFC7228].  Additional optional features include Observe
   [RFC7641], Block-wise [RFC7959], No-Response [RFC7967] and CoAP over
   reliable transport [RFC8323].

   The term "hop" is used to denote a particular leg in the end-to-end
   path.  The concept "hop-by-hop" (as in "hop-by-hop encryption" or
   "hop-by-hop fragmentation") opposed to "end-to-end", is used in this
   document to indicate that the messages are processed accordingly in
   the intermediaries, rather than just forwarded to the next node.

   The term "stop processing" is used throughout the document to denote
   that the message is not passed up to the CoAP request/response layer
   (see Figure 1).
Top   ToC   RFC8613 - Page 8
   The terms Common Context, Sender Context, Recipient Context, Master
   Secret, Master Salt, Sender ID, Sender Key, Recipient ID, Recipient
   Key, ID Context, and Common IV are defined in Section 3.1.

2.  The OSCORE Option

   The OSCORE option defined in this section (see Figure 3, which
   extends "Table 4: Options" of [RFC7252]) indicates that the CoAP
   message is an OSCORE message and that it contains a compressed COSE
   object (see Sections 5 and 6).  The OSCORE option is critical, safe
   to forward, part of the cache key, and not repeatable.

   +------+---+---+---+---+----------------+--------+--------+---------+
   | No.  | C | U | N | R | Name           | Format | Length | Default |
   +------+---+---+---+---+----------------+--------+--------+---------+
   |   9  | x |   |   |   | OSCORE         |  (*)   | 0-255  | (none)  |
   +------+---+---+---+---+----------------+--------+--------+---------+

       C = Critical,   U = Unsafe,   N = NoCacheKey,   R = Repeatable
       (*) See below.

                        Figure 3: The OSCORE Option

   The OSCORE option includes the OSCORE flag bits (Section 6), the
   Sender Sequence Number, the Sender ID, and the ID Context when these
   fields are present (Section 3).  The detailed format and length is
   specified in Section 6.  If the OSCORE flag bits are all zero (0x00),
   the option value SHALL be empty (Option Length = 0).  An endpoint
   receiving a CoAP message without payload that also contains an OSCORE
   option SHALL treat it as malformed and reject it.

   A successful response to a request with the OSCORE option SHALL
   contain the OSCORE option.  Whether error responses contain the
   OSCORE option depends on the error type (see Section 8).

   For CoAP proxy operations, see Section 10.

3.  The Security Context

   OSCORE requires that client and server establish a shared security
   context used to process the COSE objects.  OSCORE uses COSE with an
   Authenticated Encryption with Associated Data (AEAD, [RFC5116])
   algorithm for protecting message data between a client and a server.
   In this section, we define the security context and how it is derived
   in client and server based on a shared secret and a key derivation
   function.
Top   ToC   RFC8613 - Page 9
3.1.  Security Context Definition

   The security context is the set of information elements necessary to
   carry out the cryptographic operations in OSCORE.  For each endpoint,
   the security context is composed of a "Common Context", a "Sender
   Context", and a "Recipient Context".

   The endpoints protect messages to send using the Sender Context and
   verify messages received using the Recipient Context; both contexts
   being derived from the Common Context and other data.  Clients and
   servers need to be able to retrieve the correct security context to
   use.

   An endpoint uses its Sender ID (SID) to derive its Sender Context;
   the other endpoint uses the same ID, now called Recipient ID (RID),
   to derive its Recipient Context.  In communication between two
   endpoints, the Sender Context of one endpoint matches the Recipient
   Context of the other endpoint, and vice versa.  Thus, the two
   security contexts identified by the same IDs in the two endpoints are
   not the same, but they are partly mirrored.  Retrieval and use of the
   security context are shown in Figure 4.

             .---------------------.   .---------------------.
             |    Common Context   | = |    Common Context   |
             +---------------------+   +---------------------+
             |    Sender Context   | = |  Recipient Context  |
             +---------------------+   +---------------------+
             |  Recipient Context  | = |    Sender Context   |
             '---------------------'   '---------------------'
                      Client                   Server
                         |                       |
   Retrieve context for  | OSCORE request:       |
    target resource      |   Token = Token1,     |
   Protect request with  |   kid = SID, ...      |
     Sender Context      +---------------------->| Retrieve context with
                         |                       |  RID = kid
                         |                       | Verify request with
                         |                       |  Recipient Context
                         | OSCORE response:      | Protect response with
                         |   Token = Token1, ... |  Sender Context
   Retrieve context with |<----------------------+
    Token = Token1       |                       |
   Verify request with   |                       |
    Recipient Context    |                       |

            Figure 4: Retrieval and Use of the Security Context
Top   ToC   RFC8613 - Page 10
   The Common Context contains the following parameters:

   o  AEAD Algorithm.  The COSE AEAD algorithm to use for encryption.

   o  HKDF Algorithm.  An HMAC-based key derivation function (HKDF,
      [RFC5869]) used to derive the Sender Key, Recipient Key, and
      Common IV.

   o  Master Secret.  Variable length, random byte string (see
      Section 12.3) used to derive AEAD keys and Common IV.

   o  Master Salt.  Optional variable-length byte string containing the
      salt used to derive AEAD keys and Common IV.

   o  ID Context.  Optional variable-length byte string providing
      additional information to identify the Common Context and to
      derive AEAD keys and Common IV.  The use of ID Context is
      described in Section 5.1.

   o  Common IV.  Byte string derived from the Master Secret, Master
      Salt, and ID Context.  Used to generate the AEAD nonce (see
      Section 5.2).  Same length as the nonce of the AEAD Algorithm.

   The Sender Context contains the following parameters:

   o  Sender ID.  Byte string used to identify the Sender Context, to
      derive AEAD keys and Common IV, and to contribute to the
      uniqueness of AEAD nonces.  Maximum length is determined by the
      AEAD Algorithm.

   o  Sender Key. Byte string containing the symmetric AEAD key to
      protect messages to send.  Derived from Common Context and Sender
      ID.  Length is determined by the AEAD Algorithm.

   o  Sender Sequence Number.  Non-negative integer used by the sender
      to enumerate requests and certain responses, e.g., Observe
      notifications.  Used as "Partial IV" [RFC8152] to generate unique
      AEAD nonces.  Maximum value is determined by the AEAD Algorithm.
      Initialization is described in Section 3.2.2.

   The Recipient Context contains the following parameters:

   o  Recipient ID.  Byte string used to identify the Recipient Context,
      to derive AEAD keys and Common IV, and to contribute to the
      uniqueness of AEAD nonces.  Maximum length is determined by the
      AEAD Algorithm.
Top   ToC   RFC8613 - Page 11
   o  Recipient Key. Byte string containing the symmetric AEAD key to
      verify messages received.  Derived from Common Context and
      Recipient ID.  Length is determined by the AEAD Algorithm.

   o  Replay Window (Server only).  The replay window used to verify
      requests received.  Replay protection is described in Section 7.4
      and Section 3.2.2.

   All parameters except Sender Sequence Number and Replay Window are
   immutable once the security context is established.  An endpoint may
   free up memory by not storing the Common IV, Sender Key, and
   Recipient Key, deriving them when needed.  Alternatively, an endpoint
   may free up memory by not storing the Master Secret and Master Salt
   after the other parameters have been derived.

   Endpoints MAY operate as both client and server and use the same
   security context for those roles.  Independent of being client or
   server, the endpoint protects messages to send using its Sender
   Context, and verifies messages received using its Recipient Context.
   The endpoints MUST NOT change the Sender/Recipient ID when changing
   roles.  In other words, changing the roles does not change the set of
   AEAD keys to be used.

3.2.  Establishment of Security Context Parameters

   Each endpoint derives the parameters in the security context from a
   small set of input parameters.  The following input parameters SHALL
   be preestablished:

   o  Master Secret

   o  Sender ID

   o  Recipient ID

   The following input parameters MAY be preestablished.  In case any of
   these parameters is not preestablished, the default value indicated
   below is used:

   o  AEAD Algorithm

      *  Default is AES-CCM-16-64-128 (COSE algorithm encoding: 10)

   o  Master Salt

      *  Default is the empty byte string
Top   ToC   RFC8613 - Page 12
   o  HKDF Algorithm

      *  Default is HKDF SHA-256

   o  Replay Window

      *  The default mechanism is an anti-replay sliding window (see
         Section 4.1.2.6 of [RFC6347] with a window size of 32

   All input parameters need to be known and agreed on by both
   endpoints, but the Replay Window may be different in the two
   endpoints.  The way the input parameters are preestablished is
   application specific.  Considerations of security context
   establishment are given in Section 12.2 and examples of deploying
   OSCORE in Appendix B.

3.2.1.  Derivation of Sender Key, Recipient Key, and Common IV

   The HKDF MUST be one of the HMAC-based HKDF [RFC5869] algorithms
   defined for COSE [RFC8152].  HKDF SHA-256 is mandatory to implement.
   The security context parameters Sender Key, Recipient Key, and Common
   IV SHALL be derived from the input parameters using the HKDF, which
   consists of the composition of the HKDF-Extract and HKDF-Expand steps
   [RFC5869]:

      output parameter = HKDF(salt, IKM, info, L)

   where:

   o  salt is the Master Salt as defined above

   o  IKM is the Master Secret as defined above

   o  info is the serialization of a CBOR array consisting of (the
      notation follows [RFC8610] as summarized in Appendix E):

      info = [
        id : bstr,
        id_context : bstr / nil,
        alg_aead : int / tstr,
        type : tstr,
        L : uint,
      ]
Top   ToC   RFC8613 - Page 13
   where:

   o  id is the Sender ID or Recipient ID when deriving Sender Key and
      Recipient Key, respectively, and the empty byte string when
      deriving the Common IV.

   o  id_context is the ID Context, or nil if ID Context is not
      provided.

   o  alg_aead is the AEAD Algorithm, encoded as defined in [RFC8152].

   o  type is "Key" or "IV".  The label is an ASCII string and does not
      include a trailing NUL byte.

   o  L is the size of the key/nonce for the AEAD Algorithm used, in
      bytes.

   For example, if the algorithm AES-CCM-16-64-128 (see Section 10.2 in
   [RFC8152]) is used, the integer value for alg_aead is 10, the value
   for L is 16 for keys and 13 for the Common IV.  Assuming use of the
   default algorithms HKDF SHA-256 and AES-CCM-16-64-128, the extract
   phase of HKDF produces a pseudorandom key (PRK) as follows:

      PRK = HMAC-SHA-256(Master Salt, Master Secret)

   and as L is smaller than the hash function output size, the expand
   phase of HKDF consists of a single HMAC invocation; therefore, the
   Sender Key, Recipient Key, and Common IV are the first 16 or 13 bytes
   of

      output parameter = HMAC-SHA-256(PRK, info || 0x01)

   where different values of info are used for each derived parameter
   and where || denotes byte string concatenation.

   Note that [RFC5869] specifies that if the salt is not provided, it is
   set to a string of zeros.  For implementation purposes, not providing
   the salt is the same as setting the salt to the empty byte string.
   OSCORE sets the salt default value to empty byte string, which is
   converted to a string of zeroes (see Section 2.2 of [RFC5869]).
Top   ToC   RFC8613 - Page 14
3.2.2.  Initial Sequence Numbers and Replay Window

   The Sender Sequence Number is initialized to 0.

   The supported types of replay protection and replay window size is
   application specific and depends on how OSCORE is transported (see
   Section 7.4).  The default mechanism is the anti-replay window of
   received messages used by IPsec AH/ESP and DTLS (see Section 4.1.2.6
   of [RFC6347]) with a window size of 32.

3.3.  Requirements on the Security Context Parameters

   To ensure unique Sender Keys, the quartet (Master Secret, Master
   Salt, ID Context, Sender ID) MUST be unique, i.e., the pair (ID
   Context, Sender ID) SHALL be unique in the set of all security
   contexts using the same Master Secret and Master Salt.  This means
   that Sender ID SHALL be unique in the set of all security contexts
   using the same Master Secret, Master Salt, and ID Context; such a
   requirement guarantees unique (key, nonce) pairs for the AEAD.

   Different methods can be used to assign Sender IDs: a protocol that
   allows the parties to negotiate locally unique identifiers, a trusted
   third party (e.g., [ACE-OAuth]), or the identifiers can be assigned
   out-of-band.  The Sender IDs can be very short (note that the empty
   string is a legitimate value).  The maximum length of Sender ID in
   bytes equals the length of the AEAD nonce minus 6, see Section 5.2.
   For AES-CCM-16-64-128 the maximum length of Sender ID is 7 bytes.

   To simplify retrieval of the right Recipient Context, the Recipient
   ID SHOULD be unique in the sets of all Recipient Contexts used by an
   endpoint.  If an endpoint has the same Recipient ID with different
   Recipient Contexts, i.e., the Recipient Contexts are derived from
   different Common Contexts, then the endpoint may need to try multiple
   times before verifying the right security context associated to the
   Recipient ID.

   The ID Context is used to distinguish between security contexts.  The
   methods used for assigning Sender ID can also be used for assigning
   the ID Context.  Additionally, the ID Context can be used to
   introduce randomness into new Sender and Recipient Contexts (see
   Appendix B.2).  ID Context can be arbitrarily long.


Next Section