CoRE Working Group                                           G. Selander
Internet-Draft                                               J. Mattsson
Intended status: Standards Track                            F. Palombini
Expires: January April 2, 2018                                       Ericsson AB
                                                                L. Seitz
                                                        SICS Swedish ICT
                                                           July 01,
                                                      September 29, 2017

     Object Security of CoAP (OSCOAP)
                   draft-ietf-core-object-security-04 for Constrained RESTful Environments (OSCORE)
                   draft-ietf-core-object-security-05

Abstract

   This document defines Object Security of CoAP (OSCOAP), for Constrained RESTful
   Environments (OSCORE), a method for
   application layer application-layer protection of
   the Constrained Application Protocol (CoAP), using the CBOR Object
   Signing and Encryption (COSE).  OSCOAP  OSCORE provides end-to-end
   encryption, integrity and replay protection to
   CoAP payload, options, and header fields, protection, as well as a secure
   message binding.  OSCOAP  OSCORE is designed for constrained nodes and
   networks and can be used across intermediaries and over any layer.  The use of
   OSCOAP is signaled with the CoAP option Object-Security, layer and across intermediaries,
   and also defined with HTTP.  OSCORE may be used to protect group
   communications as is specified in this document. a separate draft.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/. https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on January April 2, 2018.

Copyright Notice

   Copyright (c) 2017 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
   (http://trustee.ietf.org/license-info)
   (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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   4   5
   2.  The CoAP Object-Security Option . . . . . . . . . . . . . . . . .   5
   3.  The Security Context  . . . . . . . . . . . . . . . . . . . .   6
     3.1.  Security Context Definition . . . . . . . . . . . . . . .   6
     3.2.  Derivation  Establishment of Security Context Parameters  . . . . . . . .   9   8
     3.3.  Requirements on the Security Context Parameters . . . . .  10
   4.  Protected CoAP Message Fields  . . . . . . . . . . . . . . . . . .  11
     4.1.  CoAP Payload  . . . . . . . . . . . . . . . . . . . . . .  12
     4.2.  CoAP Header . Options  . . . . . . . . . . . . . . . . . . . . . .  12
     4.3.  CoAP Options Header . . . . . . . . . . . . . . . . . . . . . .  12 .  18
   5.  The COSE Object . . . . . . . . . . . . . . . . . . . . . . .  18  19
     5.1.  Plaintext  Nonce . . . . . . . . . . . . . . . . . . . . . . . .  19 . .  20
     5.2.  Plaintext . . . . . . . . . . . . . . . . . . . . . . . .  20
     5.3.  Additional Authenticated Data . . . . . . . . . . . . . .  19  21
   6.  Sequence Numbers, Replay, Message Binding, and Freshness  . .  20  22
     6.1.  AEAD Nonce Uniqueness  Message Binding . . . . . . . . . . . . . . . . . . .  20
     6.2.  Replay Protection . .  22
     6.2.  AEAD Nonce Uniqueness . . . . . . . . . . . . . . . . . .  21  22
     6.3.  Sequence Number and Replay Window State  Freshness . . . . . . . . . .  21
     6.4.  Freshness . . . . . . . . . . . . . .  22
     6.4.  Replay Protection . . . . . . . . . . . .  23
     6.5.  Delay and Mismatch Attacks . . . . . . . .  23
     6.5.  Losing Part of the Context State  . . . . . . . . . . . .  23
   7.  Processing  . . . . . . . . . . . . . . . . . . . . . . . . .  23  24
     7.1.  Protecting the Request  . . . . . . . . . . . . . . . . .  23  24
     7.2.  Verifying the Request . . . . . . . . . . . . . . . . . .  24  25
     7.3.  Protecting the Response . . . . . . . . . . . . . . . . .  25  26
     7.4.  Verifying the Response  . . . . . . . . . . . . . . . . .  26  27
   8.  OSCOAP  OSCORE Compression  . . . . . . . . . . . . . . . . . . . . .  27  28
     8.1.  Encoding of the Object-Security Option Value . . . . . . . . .  27 .  28
     8.2.  Examples  Encoding of the OSCORE Payload  . . . . . . . . . . . . .  29
     8.3.  Context Hint  . . . . . . . . . . .  28
   9.  Web Linking . . . . . . . . . . .  30
     8.4.  Compression Examples  . . . . . . . . . . . . . .  29
   10. Security Considerations . . . .  30
   9.  Web Linking . . . . . . . . . . . . . . .  30
   11. Privacy Considerations . . . . . . . . . .  32
   10. Proxy Operations  . . . . . . . . .  32
   12. IANA Considerations . . . . . . . . . . . . .  32
     10.1.  CoAP-to-CoAP Forwarding Proxy  . . . . . . . .  32
     12.1.  CoAP Option Numbers Registry . . . . .  33
     10.2.  HTTP-to-CoAP Translation Proxy . . . . . . . . .  32
     12.2.  Media Type Registrations . . . .  33
     10.3.  CoAP-to-HTTP Translation Proxy . . . . . . . . . . . .  32
     12.3.  CoAP Content Format Registration .  34
   11. Security Considerations . . . . . . . . . . .  33
   13. Acknowledgments . . . . . . . .  35
   12. Privacy Considerations  . . . . . . . . . . . . . . .  34
   14. References . . . .  37
   13. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  34
     14.1.  Normative References  38
     13.1.  CoAP Option Numbers Registry . . . . . . . . . . . . . .  38
     13.2.  Header Field Registrations . . . .  34
     14.2.  Informative References . . . . . . . . . . .  38
   14. Acknowledgments . . . . . .  35
   Appendix A.  Test Vectors . . . . . . . . . . . . . . . . .  38
   15. References  . . .  36
   Appendix B.  Examples . . . . . . . . . . . . . . . . . . . . . .  36
     B.1.  Secure Access to Sensor  38
     15.1.  Normative References . . . . . . . . . . . . . . . . .  36
     B.2.  Secure Subscribe to Sensor .  38
     15.2.  Informative References . . . . . . . . . . . . . .  37
   Appendix C.  Object Security of Content (OSCON) . . .  40
   Appendix A.  Test Vectors . . . . . .  39
     C.1.  Overhead OSCON . . . . . . . . . . . . . .  41
   Appendix B.  Examples . . . . . . .  40
     C.2.  MAC Only . . . . . . . . . . . . . . .  41
     B.1.  Secure Access to Sensor . . . . . . . . .  41
     C.3.  Signature Only . . . . . . . .  41
     B.2.  Secure Subscribe to Sensor  . . . . . . . . . . . . .  41
     C.4.  Authenticated Encryption with Additional Data (AEAD) . .  42
     C.5.  Symmetric Encryption with Asymmetric Signature (SEAS) . .  43
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  43  44

1.  Introduction

   The Constrained Application Protocol (CoAP) is a web application
   protocol, designed for constrained nodes and networks [RFC7228].
   CoAP specifies the use of proxies for scalability and efficiency.  At
   the same time efficiency, and
   a mapping to HTTP is also specified [RFC8075].  CoAP [RFC7252]
   references DTLS [RFC6347] for security.
   Proxy operations on  CoAP messages and HTTP proxies
   require DTLS (D)TLS to be terminated at the proxy.  The proxy therefore
   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 CoAP message payload and metadata, in transit between client and server. the
   endpoints.  The proxy can also inject, delete, or reorder packages packets
   since they are no longer protected by DTLS. (D)TLS.

   This document defines the Object Security of CoAP (OSCOAP), a data object
   based for Constrained RESTful
   Environments (OSCORE) security protocol, protecting CoAP message exchanges end-to-
   end, and CoAP-
   mappable HTTP requests and responses end-to-end across intermediary nodes.
   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 Observe [RFC7641]
   and Blockwise [RFC7959].  An analysis of end-to-end security for CoAP
   messages through some types of intermediary nodes is performed in
   [I-D.hartke-core-e2e-security-reqs], this specification addresses
   [I-D.hartke-core-e2e-security-reqs].  OSCORE protects the
   forwarding case.  In addition Request/
   Response layer only, and not the CoAP Messaging Layer (Section 2 of
   [RFC7252]).  Therefore, all the CoAP messages mentioned in this
   document refer to non-empty CON, NON, and ACK messages.
   Additionally, since the core features defined message formats for CoAP over unreliable
   transport [RFC7252] and for CoAP over reliable transport
   [I-D.ietf-core-coap-tcp-tls] differ only in
   [RFC7252], OSCOAP supports Observe [RFC7641] terms of Messaging Layer,
   OSCORE can be applied to both unreliable and Blockwise [RFC7959].

   OSCOAP reliable transports.

   OSCORE is designed for constrained nodes and networks and provides an
   in-layer security protocol for CoAP which that does not depend on underlying layers.  OSCOAP
   OSCORE can be used anywhere that where CoAP or HTTP can be used, including unreliable transport [RFC7228], reliable transport
   [I-D.ietf-core-coap-tcp-tls], and
   non-IP transport
   [I-D.bormann-6lo-coap-802-15-ie].  OSCOAP transports (e.g., [I-D.bormann-6lo-coap-802-15-ie]).  An
   extension of OSCORE may also be used to protect group communication
   for CoAP [I-D.tiloca-core-multicast-oscoap].  The use of OSCOAP OSCORE does
   not affect the URI scheme and OSCOAP OSCORE can therefore be used with any
   URI scheme defined for CoAP. CoAP or HTTP.  The application decides the
   conditions for which OSCOAP OSCORE is required.

   OSCOAP

   OSCORE builds on CBOR Object Signing and Encryption (COSE)
   [I-D.ietf-cose-msg], [RFC8152],
   providing end-to-end encryption, integrity, replay protection, and
   secure message binding.  A compressed version of COSE is used, see as
   discussed in Section 8.  The use of OSCOAP OSCORE is signaled with the
   Object-Security CoAP option Object-Security, or HTTP header, defined in Section 2.  OSCOAP
   provides protection of CoAP payload, certain options, 2 and header
   fields.  The solution transforms a CoAP message
   Section 10.2.  OSCORE is designed to protect as much information as
   possible, while still allowing proxy operations (Section 10).  OSCORE
   provides protection of message payload, almost all CoAP options, and
   the RESTful method.  The solution transforms a message into an "OSCOAP
   "OSCORE message" before sending, and vice versa after receiving.  The OSCOAP
   OSCORE message is a CoAP message related to the original CoAP message in the following
   way: the original CoAP message is protected by including translated to CoAP (if not already in
   CoAP) and the resulting message payload (if present), certain options, options not
   processed by a proxy, and header fields the request/response method (CoAP Code) are
   protected in a COSE object.  The message fields of the original
   messages that have been are encrypted are removed from not present in the message whereas OSCORE message,
   and instead the Object-Security option option/header and the compressed COSE
   object are added, included, see Figure 1.

          Client                                          Server
             |  OSCOAP request:                              |
             |    GET example.com      OSCORE request - POST example.com:      |
             |    [Header,        Header, Token, Options:{...,                        |
             |     Object-Security:COSE object}]        Options: {Object-Security, ...},      |
             +---------------------------------------------->|
             |  OSCOAP response:        Payload: Compressed COSE object       |
             +--------------------------------------------->|
             |    2.05 (Content)      OSCORE response - 2.04 (Changed):       |
             |    [Header,        Header, Token, Options:{...,                        |
             |     Object-Security:-}, Payload:COSE object]        Options: {Object-Security, ...},      |
             |        Payload: Compressed COSE object       |
             |<----------------------------------------------+
             |<---------------------------------------------+
             |                                              |

                   Figure 1: Sketch of OSCOAP

   OSCOAP OSCORE with CoAP

   OSCORE may be used in very constrained settings, thanks to its small
   message size, its size and the restricted code and memory requirements, and requirements in
   addition to what is
   independent of underlying layer below required by CoAP.  OSCOAP  OSCORE can be combined with DTLS,
   transport layer security such as DTLS or TLS, thereby enabling end-to-end end-
   to-end security of e.g.  CoAP payload Payload, Options and options, Code, in
   combination with hop-by-hop protection of the entire
   CoAP message, Messaging Layer, during
   transport between end-point and intermediary node.  Examples of the
   use of OSCOAP OSCORE are given in Appendix B.

   The message protection provided by OSCOAP can alternatively be
   applied

   An implementation supporting this specification MAY only to implement
   the payload of individual messages.  We call this
   object security client part, MAY only implement the server part, or MAY only
   implement one of content (OSCON), which the proxy parts.  OSCORE is defined in Appendix C. designed to work with
   legacy 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 need to implement respective parts of this
   specification to work with OSCORE (see Section 10).

1.1.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].  These
   words may also appear in this document in lowercase, absent their
   normative meanings.

   Readers are expected to be familiar with the terms and concepts
   described in CoAP [RFC7252], Observe [RFC7641], Blockwise [RFC7959],
   COSE [I-D.ietf-cose-msg], [RFC8152], CBOR [RFC7049], CDDL
   [I-D.greevenbosch-appsawg-cbor-cddl], and constrained environments
   [RFC7228].

   The terms Common/Sender/Recipient Context, Master Secret/Salt, Sender
   ID/Key/IV, Recepient ID/Key/IV
   ID/Key, Recipient ID/Key, and Context Common IV are defined in Section 3.1.

2.  The CoAP Object-Security Option

   The CoAP Object-Security option (see Figure 2) indicates that OSCOAP is
   used to protect the
   CoAP message exchange. is an OSCORE message and that it contains a compressed
   COSE object (see Section 5 and Section 8).  The Object-Security
   option is critical, safe to forward, part of the cache key, not
   repeatable, and opaque.

        +-----+---+---+---+---+-----------------+--------+--------+ not
   repeatable.

+-----+---+---+---+---+-----------------+-----------+--------+---------+
| No. | C | U | N | R | Name            | Format    | Length |
        +-----+---+---+---+---+-----------------+--------+--------| Default |
+-----+---+---+---+---+-----------------+-----------+--------+---------+
| TBD | x |   |   |   | Object-Security | opaque see below | 0- 0-255  |
        +-----+---+---+---+---+-----------------+--------+--------+
             C=Critical, U=Unsafe, N=NoCacheKey, R=Repeatable (none)  |
+-----+---+---+---+---+-----------------+-----------+--------+---------+
     C = Critical,   U = Unsafe,   N = NoCacheKey,   R = Repeatable

                   Figure 2: The Object-Security Option

   A successful response to a request with the

   The Object-Security option contains the OSCORE flag byte and for
   requests, the Sender ID (see Section 8).  If the flag byte is all
   zero (0x00) the Option value SHALL be empty (Option Length = 0).  An
   endpoint receiving a CoAP message without payload, that also contains
   an Object-Security option SHALL treat it as malformed and reject it.

   A successful response to a request with the Object-Security option
   SHALL contain the Object-Security option.  Whether error responses
   contain the Object-Security option depends on the error type (see
   Section 7).

   Since the payload and most options are encrypted Section 4, and the
   corresponding plain text message fields of the original are not
   included in the OSCORE message, the processing of these fields does
   not expand the total message size.

   A CoAP endpoint proxy SHOULD NOT cache a response to a request with an Object-Security Object-
   Security option, since the response is only applicable to the
   original client's request.
   The Object-Security option request, see Section 10.1.  As the compressed COSE
   Object is included in the cache key for backward
   compatibility with proxies not recognizing the Object-Security
   option.  The effect is that key, messages with the Object-Security Object-
   Security option will never generate cache hits.  For Max-Age
   processing, see Section 4.3.1.1. 4.2.3.1.

3.  The protection is achieved by means of a COSE object (see Section 5),
   which is compressed Security Context

   OSCORE requires that client and then included in the OSCOAP message.  The
   placement of server establish a shared security
   context used to process the COSE object depends on whether the method/response
   code allows payload (see [RFC7252]):

   o  If the method/response code allows payload, then the compressed objects.  OSCORE uses COSE object Section 8 is the payload of the OSCOAP message, and
      the Object-Security option has length zero.  An endpoint receiving
      a CoAP message with payload, that also contains an
   Authenticated Encryption with Additional Data (AEAD) algorithm for
   protecting message data between a non-empty
      Object-Security option SHALL treat it as malformed client and reject it.

   o  If a server.  In this
   section, we define the method/response code does not allow payload, then the
      compressed COSE object Section 8 is the value of the Object-
      Security option and the length of the Object-Security option is
      equal to the size of the compressed COSE object.  An endpoint
      receiving a CoAP message without payload, that also contains an
      empty Object-Security option SHALL treat it as malformed and
      reject it.

   The size of the COSE object depends on whether the method/response
   code allows payload, if the message is a request or response, on the
   set of options that are included in the original message, the AEAD
   algorithm, the length of the information identifying the security
   context, and the length of the sequence number.

3.  The Security Context

   OSCOAP uses COSE with an Authenticated Encryption with Additional
   Data (AEAD) algorithm between a CoAP client and a CoAP server.  An
   implementation supporting this specification MAY only implement the
   client part or MAY only implement the server part.

   This specification requires that client and server establish a security context to apply to the COSE objects protecting the CoAP
   messages.  In this section we define the security context, and also
   specify how to derive the initial security contexts it is derived in
   client and server based on a common shared master secret and a key
   derivation function (KDF).

3.1.  Security Context Definition

   The security context is the set of information elements necessary to
   carry out the cryptographic operations in OSCOAP. 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,
   and 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  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 3.

                  .------------.           .------------.

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

            Figure 3: Retrieval and use of the Security Context

   The Common Context contains the following parameters:

   o  AEAD Algorithm (Alg).  Value that identifies the (alg).  The COSE AEAD algorithm to use for
      encryption.  Its value is immutable once the security context is
      established.

   o  Key Derivation Function.  The HMAC based HKDF [RFC5869] used to
      derive Sender Key, Recipient Key, and Common IV.

   o  Master Secret.  Variable length, uniformly random byte string
      containing the key used to derive traffic keys and IVs.  Its value
      is immutable once the security context is established.

   o  Master Salt (OPTIONAL).  Variable length byte string containing
      the salt used to derive traffic keys and IVs.  Its value is
      immutable once the security context is established.

   The Sender Context contains the following parameters:

   o  Sender ID.  Variable length byte  Common IV.  Byte string identifying derived from Master Secret and Master
      Salt.  Length is determined by the Sender
      Context. AEAD Algorithm.  Its value is
      immutable once the security context is established.

   o

   The Sender Key. Byte string containing Context contains the symmetric key to protect
      messages following parameters:

   o  Sender ID.  Non-negative integer used to send.  Derived from Common identify the Sender
      Context and Sender ID. to assure unique nonces.  Length is determined by the
      AEAD Algorithm.  Its value is immutable once the security context
      is established.

   o  Sender IV. Key. Byte string containing the IV symmetric key to protect
      messages to send.  Derived from Common Context and Sender ID.
      Length is determined by the AEAD Algorithm.  Its value is
      immutable once the security context is established.

   o  Sender Sequence Number.  Non-negative integer used by the sender
      to protect requests and observe responses to send. Observe notifications.  Used as partial IV
      [I-D.ietf-cose-msg] "Partial
      IV" [RFC8152] to generate unique nonces for the AEAD.  Maximum
      value is determined by the AEAD Algorithm.

   The Recipient Context contains the following parameters:

   o  Recipient ID.  Variable length byte string identifying the
      Recipient Context.  Its value is immutable once  Non-negative integer used to identify the security
      context is established.

   o Recipient Key. Byte string containing the symmetric key to verify
      messages received.  Derived from Common
      Context and Recipient ID. to assure unique nonces.  Length is determined by the
      AEAD Algorithm.  Its value is immutable once the security context
      is established.

   o  Recipient IV. Key. Byte string containing the IV symmetric key to verify
      messages received.  Derived from Common Context and Recipient ID.
      Length is determined by the AEAD Algorithm.  Its value is
      immutable once the security context is established.

   o  Replay Window. Window (Server only).  The replay window to verify requests and observe
      responses
      received.

   When it is understood which context is referred to (Sender Context or
   Recipient Context), the term "Context IV" is used to denote the IV
   currently used with this context.

   An endpoint may free up memory by not storing the Sender Key, Sender Common IV, Recipient Sender
   Key, and Recipient IV, Key, deriving them from the Common
   Context Master Key and Master
   Salt 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.

   The endpoints MAY interchange the client and server roles while
   maintaining the same security context.  When this happens, the former
   server still protects messages to send using its Sender Context, and
   verifies messages received using its Recipient Context.  The same is
   also true for the former client.  The endpoints MUST NOT change the
   Sender/Recipient ID. ID when changing roles.  In other words, changing
   the roles does not change the set of keys to be used.

3.2.  Derivation  Establishment of Security Context Parameters

   The parameters in the security context are derived from a small set
   of input parameters.  The following input parameters SHALL be pre-
   established:

   o  Master Secret

   o  Sender ID

   o  Recipient ID

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

   o  AEAD Algorithm (Alg) (alg)

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

   o  Master Salt

      *  Default is the empty string

   o  Key Derivation Function (KDF)

      *  Default is HKDF SHA-256

   o  Replay Window Type and Size

      *  Default is DTLS-type replay protection with a window size of 32
         ([RFC6347])

   All input parameters need to be known to and agreed on by both
   endpoints, but the replay window may be different in the two
   endpoints.  The replay window type and size is used by the client in
   the processing of the Request-Tag
   [I-D.amsuess-core-repeat-request-tag].  How the input parameters are
   pre-established, is application specific.  The EDHOC protocol [I-D.selander-ace-cose-ecdhe] enables ACE framework may be
   used to establish the establishment of necessary input parameters with the property of forward
   secrecy and negotiation of KDF and AEAD, it thus provides all
   necessary pre-requisite steps for using OSCOAP as defined here.
   [I-D.ietf-ace-oauth-authz].

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

   The KDF MUST be one of the HMAC based HKDF [RFC5869] algorithms
   defined in COSE.  HKDF SHA-256 is mandatory to implement.  The
   security context parameters Sender Key/IV and Key, Recipient Key/IV 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 is defined above

   o  info is a CBOR array consisting of:

      info = [
          id : bstr, bstr / nil,
          alg : int,
          type : tstr,
          L : int uint
      ]

      *

   where:

   o  id is the Sender ID or Recipient ID

      * when deriving keys and nil
      when deriving the Common IV.  Sender ID and Recipient ID are
      encoded as described in Section 5

   o  type is "Key" or "IV"

   o  L is the size of the key/IV for the AEAD algorithm used, in
      octets. octets

   For example, if the algorithm AES-CCM-64-64-128 AES-CCM-16-64-128 (see Section 10.2 in
   [I-D.ietf-cose-msg])
   [RFC8152]) is used, the value for L is 16 for keys and 7 13 for IVs. the
   Common IV.

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 length is application specific
   and depends on the lower layers.  Default  The default is DTLS-type replay
   protection with a window size of 32 initiated as described in
   Section 4.1.2.6 of [RFC6347].

3.3.  Requirements on the Security Context Parameters

   As collisions may lead to the loss of both confidentiality and
   integrity, Sender ID SHALL be unique in the set of all security
   contexts using the same Master Secret.  Normally (e.g. when Secret and Master Salt.  When a
   trusted third party assigns identifiers (e.g., using
   [I-D.ietf-ace-oauth-authz]) or by using
   EDHOC [I-D.selander-ace-cose-ecdhe]) a protocol that allows the
   parties to negotiate locally unique identifiers in each endpoint, the
   Sender IDs can be very short.
   Note that  The maximum Sender IDs of different lengths can be used with the same
   Master Secret.  E.g. the SID with value 0x00 ID is different from the
   SID with 2^(nonce
   length in bits - 40) - 1, For AES-CCM-16-64-128 the value 0x0000. maximum Sender ID
   is 2^64 - 1.  If Sender ID uniqueness cannot be guaranteed, random
   Sender IDs MUST be used.  Random Sender IDs MUST be long enough so
   that the probability of collisions is negligible.

   To enable retrieval of the right Recipient Context, the Recipient ID
   SHOULD be unique in the sets of all Recipient Contexts used by an
   endpoint.  The Client MAY provide a Context Hint Section 8.3 to help
   the Server find the right context.

   While the triple (Master Secret, Master Salt, Sender ID) MUST be
   unique, the same Master Salt MAY be used with several Master Secrets. Secrets
   and the same Master Secret MAY be used with several Master Salts.

4.  Protected CoAP Message Fields

   OSCOAP

   OSCORE transforms a CoAP message (which may have been generated from
   an HTTP message) into an OSCOAP OSCORE message, and vice versa.  This section defines how the CoAP message fields are
   protected.  Note that OSCOAP protects messages from the CoAP
   Requests/Responses layer only, and not from the Messaging layer
   (Section 2 of [RFC7252]): this means that RST and ACK empty messages
   are not protected, while ACK with piggybacked responses are protected
   using the process defined in this document.  All the messages
   mentioned in this document refer to CON, NON and non-empty ACK
   messages.

   OSCOAP  OSCORE
   protects as much of the original CoAP message as possible, possible while still
   allowing forward certain proxy operations
   [I-D.hartke-core-e2e-security-reqs].  Message fields may either be

   o  Class E: encrypted and integrity protected,

   o  Class I: integrity protected only, or

   o  Class U: unprotected. (see Section 10).  This section also outlines
   defines how OSCORE protects the message fields are transferred, a
   detailed description and transfers them
   end-to-end between client and server (in any direction).

   The remainder of this section and later sections discuss the processing is provided behavior
   in Section 7.
   Message fields terms of the original CoAP message are either transferred messages.  If HTTP is used for a particular leg in
   the header/options part of end-to-end path, then this section applies to the OSCOAP message, or in the plaintext of
   the COSE object.  Depending on which, the location of conceptual CoAP
   message that is mappable to/from the original HTTP message
   field as
   discussed in the OSCOAP Section 10.  That is, an HTTP message is called "outer" or "inner":

   o  Inner message field: conceptually
   transformed to a CoAP message field included and then to an OSCORE message, and
   similarly in the plaintext of reverse direction.  An actual implementation might
   translate directly from HTTP to OSCORE without the COSE object intervening CoAP
   representation.

   Message fields of the OSCOAP message (see Section 5.1).  The
      inner CoAP message fields are by definition may be protected end-to-end
   between CoAP client and CoAP server in different ways:

   o  Class E: encrypted and integrity protected,

   o  Class I: integrity protected by the COSE object (Class E). only, or

   o  Outer message field:  Class U: unprotected.

   The sending endpoint SHALL transfer Class E message field included fields in the header or
      options part
   ciphertext of the OSCOAP COSE object in the OSCORE message.  The outer sending
   endpoint SHALL include Class I message fields are
      not encrypted and thus visible to an intermediary, but may be
      integrity protected by including the message field values in the Additional
   Authenticated Data (AAD) of the COSE object (see
      Section 5.2).  I.e. outer AEAD algorithm, allowing the
   receiving endpoint to detect if the value has changed in transfer.
   Class U message fields may SHALL NOT be protected in transfer.  Class I or
   and Class
      U.

   Note that, even though the U message formats field values are slightly different,
   OSCOAP complies with CoAP over unreliable transport [RFC7252] as well
   as CoAP over reliable transport [I-D.ietf-core-coap-tcp-tls].

4.1.  CoAP Payload

   The CoAP Payload SHALL be encrypted and integrity protected (Class
   E), and thus is an inner message field.

   The sending endpoint writes transferred in the payload header or
   options part of the original CoAP OSCORE message
   into which is visible to proxies.

   Message fields not visible to proxies, i.e., transported in the plaintext
   ciphertext of the COSE object.

   The receiving endpoint verifies and decrypts the COSE object, and
   recreates the payload of are called "Inner" (Class E).  Message
   fields transferred in the original CoAP message.

4.2.  CoAP Header

   Many CoAP header fields are required or options part of the OSCORE
   message, which is visible to be read and changed during a
   normal proxies, are called "Outer" (Class I or
   U).

   CoAP message exchange fields are either Inner or when traversing Outer: Inner if the value is
   intended for the destination endpoint, Outer if the value is intended
   for a proxy proxy.  An OSCORE message may contain both an Inner and thus cannot in
   general be protected between the endpoints, e.g. an
   Outer message field of certain CoAP message layer fields.  Inner and Outer
   message fields such as Message ID.

   The are processed independently.

4.1.  CoAP header field Code MUST be sent in plaintext to support
   RESTful processing, but MUST be integrity protected (Class I) to
   prevent an intermediary from changing, e.g. from GET to DELETE. Payload

   The CoAP version number MUST be integrity protected to prevent potential
   future version-based attacks (Class I).  Note that while the version
   number is not sent Payload, if present in each CoAP message over reliable transport
   [I-D.ietf-core-coap-tcp-tls], its value is known to client and
   server.

   The other the original CoAP header fields message, SHALL neither be
   encrypted and integrity protected nor
   encrypted (Class U).  All CoAP header fields are and is thus outer an Inner message
   fields. field.
   The sending endpoint SHALL copy writes the header fields from payload of the original CoAP message to
   into the header of plaintext (Section 5.2) input to the OSCOAP message. COSE object.  The
   receiving endpoint SHALL copy the header fields from the OSCOAP message to the
   header of the decrypted CoAP message.  Both sender verifies and receiver
   include decrypts the CoAP version number COSE object, and header field Code in
   recreates the AAD payload of the COSE object (see Section 5.2).

4.3. original CoAP message.

4.2.  CoAP Options

   Most

   A summary of how options are encrypted and integrity protected (Class E), and
   thus inner message fields.  But to allow certain proxy operations,
   some options have outer values, i.e. are present as options in the
   OSCOAP message.  Certain options may have both an inner value and a
   potentially different outer value, where the inner value is intended
   for the destination endpoint and the outer value is intended for a
   proxy.

   A summary of how options are protected and processed is shown in Figure 4.  Options within each class are protected and processed in a
   similar way, but certain options
   which require special processing as
   indicated by a * processing, in Figure 4 particular those which may have
   both Inner and described in the processing of the
   respective option. Outer message fields, are labelled with asterisks.

                +----+----------------+---+---+---+
                | No.| Name           | E | I | U |
                +----+----------------+---+---+---+
                |  1 | If-Match       | x |   |   |
                |  3 | Uri-Host       |   |   | x |
                |  4 | ETag           | x |   |   |
                |  5 | If-None-Match  | x |   |   |
                |  6 | Observe        |   | *   | * |
                |  7 | Uri-Port       |   |   | x |
                |  8 | Location-Path  | x |   |   |
                | 11 | Uri-Path       | x |   |   |
                | 12 | Content-Format | x |   |   |
                | 14 | Max-Age        | * |   | * |
                | 15 | Uri-Query      | x |   |   |
                | 17 | Accept         | x |   |   |
                | 20 | Location-Query | x |   |   |
                | 23 | Block2         | * |   | * |
                | 27 | Block1         | * |   | * |
                | 28 | Size2          | * |   | * |
                | 35 | Proxy-Uri      | * |   | * |
                | 39 | Proxy-Scheme   |   |   | x |
                | 60 | Size1          | * |   | * |
                +----+----------------+---+---+---+

        E=Encrypt

                 E = Encrypt and Integrity Protect, I=Integrity Protect only,
        U=Unprotected, *=Special (Inner)
                 I = Integrity Protect only (Outer)
                 U = Unprotected (Outer)
                 * = Special

                   Figure 4: Protection of CoAP Options

   Unless specified otherwise,

   Unknown CoAP options not listed in Figure 4 SHALL be encrypted and integrity protected and processed as class E
   options. (and no special
   processing).  Specifications of new CoAP options SHOULD define how
   they are processed with OSCOAP.  New OSCORE.  A new COAP options option SHOULD be of class
   E and
   SHOULD NOT have outer values unless a forwarding it requires proxy needs to read
   that option value.  If a certain option has both inner and outer
   values, the two values SHOULD NOT be the same.

4.3.1.  Class E processing.

4.2.1.  Inner Options

   For options

   When using OSCORE, Inner option message fields (marked in class column E (see of
   Figure 4) the option value are sent in the
   original CoAP message, if present, SHALL be encrypted and integrity
   protected between the endpoints.  Hence the actions resulting from
   the use of such options is a way analogous to communicating in a protected
   manner directly with the other endpoint.  For example, a client using an
   If-Match option will not be served by a proxy.

   The sending endpoint SHALL write the class E Inner option from message fields
   present in the original CoAP message into the plaintext of the COSE object.

   Except for
   object Section 5.2, and then remove the special options (* in Figure 4), Inner option message fields
   from the OSCORE message.

   The processing of Inner option message fields by the receiving
   endpoint is specified in Section 7.2 and Section 7.4.

4.2.2.  Outer Options

   Outer option message fields (marked in column U or I of Figure 4) are
   used to support proxy operations.

   The sending endpoint SHALL NOT use include the Outer option message field
   present in the original message in the outer options part of class E.  However, note that an
   intermediary may, legitimately or not, add, change or remove the
   value OSCORE
   message.  All Outer option message fields, including Object-Security,
   SHALL be encoded as described in Section 3.1 of an outer option.

   Except for [RFC7252], where the special options,
   delta is the difference to the previously included Outer option
   message field.

   The processing of Outer options by the receiving endpoint SHALL discard
   any outer options is
   specified in Section 7.2 and Section 7.4.

   A procedure for integrity-protection-only of class E from the OSCOAP Class I option message and SHALL write
   the
   fields is specified in Section 5.3.

   Note: There are currently no Class E I option message fields defined.

4.2.3.  Special Options

   Some options present require special processing, marked with an asterisk '*'
   in Figure 4.  An asterisk in the plaintext of columns E and U indicate that the COSE object into
   option may be added as an Inner and/or Outer message by the decrypted CoAP message.

4.3.1.1. sending
   endpoint; the processing is specified in this section.

4.2.3.1.  Max-Age

   An inner

   The Inner Max-Age option, like other class E options, option is used as to specify the freshness (as defined
   in [RFC7252] [RFC7252]) of the resource, end-to-end from the server to the
   client, taking into account that it the option is not accessible to
   proxies.

   Since OSCOAP binds CoAP responses to requests, a cached response
   would not  The Inner Max-Age SHALL be possible processed by OSCORE as specified
   in Section 4.2.1.

   The Outer Max-Age option is used to use for any other request.  To avoid unnecessary caching, a server MAY add an outer caching of
   OSCORE responses at OSCORE unaware intermediary nodes.  A server MAY
   set a Class U Max-Age option with value zero to OSCOAP Observe responses
   (see Section 5.6.1 of [RFC7252]). [RFC7252]) which is then processed according to
   Section 4.2.2.  The
   outer Outer Max-Age option is value SHALL be discarded by
   the OSCORE client.

   Non-Observe OSCORE responses do not integrity protected.

4.3.1.2. need to include a Max-Age option
   since the responses are non-cacheable by construction (see
   Section 4.3).

4.2.3.2.  The Block Options

   Blockwise [RFC7959] is an optional feature.  An implementation MAY
   comply with
   support [RFC7252] and the Object-Security option without
   implementing supporting
   [RFC7959].  The Block options (Block1, Block2, Size1 and Size2) MAY be either
   only inner options, only outer options are used to secure message
   fragmentation end-to-end (Inner options) or both inner for proxies to fragment
   the OSCORE message for the next hop (Outer options).  Inner and outer
   options. Outer
   block processing may have different performance properties depending
   on the underlying transport.  The inner integrity of the message can be
   verified end-to-end both in case of Inner and outer options Outer Blockwise
   provided all blocks are processed independently.

4.3.1.2.1. received (see Section 4.2.3.2.2).

4.2.3.2.1.  Inner Block Options

   The inner Block options are used for endpoint-to-endpoint secure
   fragmentation of payload into blocks and protection of information
   about the fragmentation (block number, block size, last block).  In
   this case, the sending CoAP endpoint fragments the MAY fragment a CoAP message as defined in
   [RFC7959] before the message is processed by OSCOAP. OSCORE.  In this case
   the Block options SHALL be processed by OSCORE as Inner options
   (Section 4.2.1).  The receiving CoAP endpoint first processes SHALL process the OSCOAP
   OSCORE message according to Section 4.2.1 before processing blockwise
   as defined in [RFC7959].

   Applications using OSCOAP with inner Block options MUST specify a
   security policy defining a maximum unfragmented message size for
   inner Block options such that messages exceeding this size SHALL be
   fragmented by the sending endpoint.

   For blockwise request operations (using Block1) the client using Block1, an endpoint MUST use
   and process
   comply with the Request-Tag as processing defined in Section 3 of
   [I-D.amsuess-core-repeat-request-tag].  In particular, the rules in
   section 3.3.1 of [I-D.amsuess-core-repeat-request-tag] MUST be
   followed, which guarantee that a specific request body is assembled
   only from the corresponding request blocks.

   For blockwise response operations (using Block2) the server using Block2, an endpoint MUST use
   and process
   comply with the ETag as processing defined in Section 4 of
   [I-D.amsuess-core-repeat-request-tag].

4.3.1.2.2.

4.2.3.2.2.  Outer Block Options

   A CoAP proxy may do block fragmentation on any CoAP

   Proxies MAY fragment an OSCORE message
   (including OSCOAP messages) as defined in [RFC7959], and thereby
   decompose it into multiple blocks using outer Block options.  The
   outer block [RFC7959], which then
   introduces Outer Block options not generated by the sending endpoint.
   Note that the Outer Block options are thus neither encrypted nor integrity
   protected.

   To allow multiple concurrent request operations to the same server
   (not only same resource),  As a consequence, a CoAP proxy should use can maliciously inject block
   fragments indefinitely, since the receiving endpoint needs to receive
   the last block (see [RFC7959]) to be able to compose the OSCORE
   message and process verify its integrity.  Therefore, applications supporting
   OSCORE and [RFC7959] MUST specify a security policy defining a
   maximum unfragmented message size (MAX_UNFRAGMENTED_SIZE) considering
   the
   Request-Tag as specified in section 3.3.2 maximum size of
   [I-D.amsuess-core-repeat-request-tag]; an OSCOAP server that supports
   outer message which can be handled by the endpoints.
   Messages exceeding this size SHOULD be fragmented by the sending
   endpoint using Inner Block options MUST support the Request-Tag option. (Section 4.2.3.2.1).

   An endpoint receiving an OSCOAP OSCORE message with an outer Outer Block option
   SHALL first process this option according to [RFC7959], until all
   blocks of the OSCOAP OSCORE message have been received, or the cumulated
   message size of the blocks exceeds the maximum unfragmented message
   size.  In the latter case the message SHALL be discarded. MAX_UNFRAGMENTED_SIZE.  In the
   former case, the processing of the OSCOAP OSCORE message continues as
   defined in this document.

4.3.2.  Class I Options

   A Class I option is an outer option and hence visible in the options
   part of the OSCOAP message.  Except for special options described in  In the subsections, for options in Class I (see Figure 4) latter case the option
   value message SHALL be integrity protected between
   discarded.

   To allow multiple concurrent request operations to the endpoints, see
   (Section 5.2).  Unless otherwise specified, same server
   (not only same resource), a CoAP proxy SHOULD follow the Request-Tag
   processing specified in section 3.3.2 of
   [I-D.amsuess-core-repeat-request-tag].

4.2.3.3.  Proxy-Uri

   Proxy-Uri, when present, is split by OSCORE into class U options and
   class E options, which are processed accordingly.  When Proxy-Uri is
   used in the original CoAP message, Uri-* are not present [RFC7252].

   The sending endpoint SHALL encode first decompose the Class I options in Proxy-Uri value of the OSCOAP
   original CoAP message as described
   in Section 4.3.4.

4.3.2.1.  Observe

   Observe [RFC7641] is into the Proxy-Scheme, Uri-Host, Uri-Port, Uri-
   Path, and Uri-Query options (if present) according to section 6.4 of
   [RFC7252].

   Uri-Path and Uri-Query are class E options and SHALL be protected and
   processed as Inner options (Section 4.2.1).

   The Proxy-Uri option of the OSCORE message SHALL be set to the
   composition of Proxy-Scheme, Uri-Host and Uri-Port options (if
   present) as specified in section 6.5 of [RFC7252], and processed as
   an Outer option of Class U (Section 4.2.2).

   Note that replacing the Proxy-Uri value with the Proxy-Scheme and
   Uri-* options works by design for all CoAP URIs (see Section 6 of
   [RFC7252].  OSCORE-aware HTTP servers should not use the userinfo
   component of the HTTP URI (as defined in section 3.2.1. of
   [RFC3986]), so that this type of replacement is possible in the
   presence of CoAP-to-HTTP proxies.  In other documents specifying
   cross-protocol proxying behavior using different URI structures, it
   is expected that the authors will create Uri-* options that allow
   decomposing the Proxy-Uri, and specify in which OSCORE class they
   belong.

   An example of how Proxy-Uri is processed is given here.  Assume that
   the original CoAP message contains:

   o  Proxy-Uri = "coap://example.com/resource?q=1"
   During OSCORE processing, Proxy-Uri is split into:

   o  Proxy-Scheme = "coap"

   o  Uri-Host = "example.com"

   o  Uri-Port = "5683"

   o  Uri-Path = "resource"

   o  Uri-Query = "q=1"

   Uri-Path and Uri-Query follow the processing defined in
   Section 4.2.1, and are thus encrypted and transported in the COSE
   object.  The remaining options are composed into the Proxy-Uri
   included in the options part of the OSCORE message, which has value:

   o  Proxy-Uri = "coap://example.com"

   See Section 6.1 and 12.6 of [RFC7252] for more information.

4.2.3.4.  Observe

   Observe [RFC7641] is an optional feature.  An implementation MAY
   support [RFC7252] and the Object-Security option without supporting
   [RFC7641].  The Observe option as used here targets the requirements
   on forwarding of [I-D.hartke-core-e2e-security-reqs]
   (Section 2.2.1.2).

   In order for a an OSCORE-unaware proxy to support forwarding of Observe messages,
   messages ([RFC7641]), there
   must SHALL be an Outer Observe option option, i.e.,
   present in the options part of the OSCOAP
   message ([RFC7641]), so Observe must have an outer value:

   o OSCORE message.  The Observe option processing of
   the original CoAP request SHALL be encoded
      in the OSCOAP request as Code for Observe messages is described in Section 4.3.4. 4.3.

   To secure the order of the notifications, responses with the Observe
   option client SHALL be integrity protected in the following way:

   o maintain a
   Notification Number for each Observation it registers.  The Observe option SHALL be included in
   Notification Number is a non-negative integer containing the external_aad largest
   Partial IV of the
      response (see successfully received notifications for the
   associated Observe registration, see Section 5.2), with value set 6.4.  The Notification
   Number is initialized to the 3 least
      significant bytes Partial IV of the Sequence Number first successfully
   received notification response to the registration request.  In
   contrast to [RFC7641], the received Partial IV MUST always be
   compared with the Notification Number, which thus MUST NOT be
   forgotten after 128 seconds.

   If the verification fails, the client SHALL stop processing the
   response, and in the case of CON respond with an empty ACK.  The
   client MAY ignore the response. Observe option value.

   The Observe option in the CoAP request SHALL NOT be integrity
   protected, since it may be legitimately removed by
   a proxy.  If the Observe option is removed from a CoAP request by a
   proxy, then the server can still verify the request (as a non-Observe
   request), and produce a non-Observe response.  If the OSCOAP OSCORE client
   receives a response to an Observe request without an outer Observe
   value, then it MUST verify the response as a non-Observe response, i.e. not
   include response.
   (The reverse case is covered in the Sequence Number verification of the response response, see
   Section 7.)

4.3.  CoAP Header

   Most CoAP header fields are required to be read and/or changed by
   CoAP proxies and thus cannot in general be protected end-to-end
   between the external_aad.

4.3.3.  Class U Options

   Options endpoints.  As mentioned in Class U have outer values Section 1, OSCORE protects
   the CoAP Request/Response layer only, and not the Messaging Layer
   (Section 2 of [RFC7252]), so fields such as Type and Message ID are used
   not protected with OSCORE.

   The CoAP header field Code is protected by OSCORE.  Code SHALL be
   encrypted and integrity protected (Class E) to support forward
   proxy operations.  Unless otherwise specified, prevent an
   intermediary from eavesdropping or manipulating the Code (e.g.,
   changing from GET to DELETE).

   The sending endpoint SHALL encode write the Class U options in Code of the options part original CoAP
   message into the plaintext of the COSE object Section 5.2.  After
   that, the Outer Code of the OSCOAP OSCORE message as described SHALL be set to 0.02
   (POST) for requests and to 2.04 (Changed) for responses, except for
   Observe messages.  For Observe messages, the Outer Code of the OSCORE
   message SHALL be set to 0.05 (FETCH) for requests and to 2.05
   (Content) for responses.  This exception allows OSCORE to be
   compliant with the Observe processing in Section 4.3.4.

4.3.3.1.  Uri-Host, Uri-Port, OSCORE-unaware proxies.  The
   choice of POST and Proxy-Scheme FETCH ([RFC8132]) allows all OSCORE messages to
   have payload.

   The sending receiving endpoint SHALL copy Uri-Host, Uri-Port, and Proxy-Scheme
   from discard the original CoAP Code in the OSCORE message to
   and write the options part Code of the OSCOAP
   message.  When Uri-Host, Uri-Port, or Proxy-Scheme options are
   present, Proxy-Uri is not used [RFC7252].

4.3.3.2.  Proxy-Uri

   Proxy-Uri, when present, is split by OSCOAP into class U options and
   class E options, which are processed accordingly.  When Proxy-Uri is
   used Plaintext in the original COSE object (Section 5.2)
   into the decrypted CoAP message, Uri-* message.

   The other CoAP header fields are not present [RFC7252]. Unprotected (Class U).  The sending
   endpoint SHALL first decompose the Proxy-Uri value write all other header fields of the original CoAP message
   into the Proxy-Scheme, Uri-Host, Uri-Port, Uri-
   Path and Uri-Query options (if present) according to section 6.4 header of
   [RFC7252].

   Uri-Path and Uri-Query are class E options and MUST be protected and
   processed as if obtained the OSCORE message.  The receiving endpoint SHALL
   write the header fields from the original received OSCORE message into the
   header of the decrypted CoAP message, see
   Section 4.3.1. message.

5.  The value of COSE Object

   This section defines how to use COSE [RFC8152] to wrap and protect
   data in the Proxy-Uri option of original message.  OSCORE uses the OSCOAP message MUST be
   replaced with Proxy-Scheme, Uri-Host and Uri-Port options (if
   present) composed according to section 6.5 of [RFC7252] and MUST be
   processed as a class U option, see Section 4.3.3.

   An example of how Proxy-Uri is processed is given here.  Assume that
   the original CoAP message contains:

   o  Proxy-Uri = "coap://example.com/resource?q=1"

   During OSCOAP processing, Proxy-Uri is split into:

   o  Proxy-Scheme = "coap"

   o  Uri-Host = "example.com"

   o  Uri-Port = "5863"

   o  Uri-Path = "resource"

   o  Uri-Query = "q=1"

   Uri-Path and Uri-Query follow the processing defined in
   Section 4.3.1, and are thus encrypted and transported in the COSE
   object.  The remaining options are composed into the Proxy-Uri
   included in the options part of the OSCOAP message, which has value:

   o  Proxy-Uri = "coap://example.com"

4.3.4.  Outer Options in the OSCOAP Message

   All options with outer values present in the OSCOAP message,
   including the Object-Security option, SHALL be encoded as described
   in Section 3.1 of [RFC7252], where the delta is the difference to the
   previously included outer option value.

5.  The COSE Object

   This section defines how to use COSE [I-D.ietf-cose-msg] to wrap and
   protect data in the original CoAP message.  OSCOAP uses the untagged
   COSE_Encrypt0 structure untagged COSE_Encrypt0
   structure with an Authenticated Encryption with Additional Data
   (AEAD) algorithm.  The key lengths, IV lengths, length, nonce length, and
   maximum sequence number Sender Sequence Number are algorithm dependent.

   The AEAD algorithm AES-CCM-64-64-128 AES-CCM-16-64-128 defined in Section 10.2 of
   [I-D.ietf-cose-msg]
   [RFC8152] is mandatory to implement.  For AES-CCM-64-64-128 AES-CCM-16-64-128 the
   length of Sender Key and Recipient Key is 128 bits, the length of
   nonce, Sender IV,
   nonce and Recipient Common IV is 7 13 bytes.  The maximum Sender Sequence Number
   is specified in Section 10.

   The nonce is constructed as described in Section 3.1 of
   [I-D.ietf-cose-msg], i.e. 11.

   We denote by padding Plaintext the partial IV (Sequence Number
   in network byte order) with zeroes data that is encrypted and XORing it with the Context IV
   (Sender IV or Recipient IV), with integrity
   protected, and by Additional Authenticated Data (AAD) the following addition: The most
   significant bit in the first byte of the Context IV SHALL be flipped
   for responses, in case there is a unique response (not Observe).  In
   this way, the same sequence number can be reused for requests and
   corresponding responses, which reduces the size of the responses in
   the most common case.  For detailed processing instructions, see
   Section 7.

   We denote by Plaintext the data that is encrypted and integrity
   protected, and by Additional Authenticated Data (AAD) the data that
   is integrity protected only. data that
   is integrity protected only.

   The COSE Object SHALL be a COSE_Encrypt0 object with fields defined
   as follows

   o  The "protected" field is empty.

   o  The "unprotected" field includes:

      *  The "Partial IV" parameter.  The value is set to the Sender
         Sequence Number.  The Partial IV  All leading zeroes SHALL be of minimum length needed to
         encode removed when
         encoding the sequence number. Partial IV, i.e. the first byte (if any) SHALL
         never be zero.  This parameter SHALL be present in requests.
         In case of Observe (Section 4.3.2.1) 4.2.3.4) the Partial IV SHALL be
         present in the response, responses, and otherwise the Partial IV SHALL NOT be
         present in the response. responses.

      *  The "kid" parameter.  The value is set to the Sender ID (see
         Section 3).  All leading zeroes SHALL be removed when encoding
         the Partial IV, i.e. the first byte (if any) SHALL never be
         zero.  This parameter SHALL be present in requests and SHALL
         NOT be present in responses.

   o  The "ciphertext" field is computed from the secret key (Sender Key
      or Recipient Key), Nonce (see Section 5.1), Plaintext (see
      Section 5.1) 5.2), and the Additional Authenticated Data (AAD) (see
      Section 5.2) 5.3) following Section 5.2 of [I-D.ietf-cose-msg]. [RFC8152].

   The encryption process is described in Section 5.3 of
   [I-D.ietf-cose-msg]. [RFC8152].

5.1.  Nonce

   The nonce is constructed by left-padding the Partial IV (in network
   byte order) with zeroes to exactly 5 bytes, left-padding the Sender
   ID of the endpoint that generated the Partial IV (in network byte
   order) with zeroes to exactly nonce length - 5 bytes, concatenating
   the padded Partial IV with the padded ID, and then XORing with the
   Common IV.

   When observe is not used, the request and the response uses the same
   nonce.  In this way, the Partial IV does not have to be sent in
   responses, which reduces the size.  For processing instructions, see
   Section 7.

             +--------------------------+--+--+--+--+--+
             |    ID of PIV generator   |  Partial IV  |---+
             +--------------------------+--+--+--+--+--+   |
                                                           |
             +-----------------------------------------+   |
             |                Common IV                |->(+)
             +-----------------------------------------+   |
                                                           |
             +-----------------------------------------+   |
             |                  Nonce                  |<--+
             +-----------------------------------------+

                      Figure 5: AEAD Nonce Formation

5.2.  Plaintext

   The Plaintext is formatted as a CoAP message without Header (see
   Figure 5) 6) consisting of:

   o  all Class E  the Code of the original CoAP message as defined in Section 3 of
      [RFC7252]; and

   o  all Inner option values message fields (see Section 4.3.1 4.2.1) present in the
      original CoAP message (see Section 4.3). 4.2).  The options are encoded
      as described in Section 3.1 of [RFC7252], where the delta is the
      difference to the previously included Class E option; and

   o  the Payload of original CoAP message, if present, and in that case
      prefixed by the one-byte Payload Marker (0xFF).

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Code      |    Class E options (if any) ...
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |1 1 1 1 1 1 1 1|    Payload (if any) ...
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      (only if there
        is payload)

                            Figure 5: 6: Plaintext

5.2.

5.3.  Additional Authenticated Data

   The external_aad SHALL be a CBOR array as defined below:

   external_aad = [
      ver : uint,
      code
      version : uint,
      options : bstr,
      alg : int,
      request_kid : bstr,
      request_seq
      request_piv : bstr,
      options : bstr
   ]

   where:

   o  ver:  version: contains the CoAP OSCORE version number, as defined in Section 3 of
      [RFC7252].

   o  code: contains is the CoAP Code of the original CoAP message, as
      defined in Section 3 of [RFC7252].

   o  options: contains the Class I options Section 4.3.2 present in the
      original CoAP message encoded as described in Section 3.1 number.  Implementations of
      [RFC7252], where the delta is the difference
      this specification MUST set this field to the previously
      included class I option 1.  Other values are
      reserved for future versions.

   o  alg: contains the AEAD Algorithm from the security context used
      for the exchange (see Section 3.1).

   o  request_kid: contains the value of the 'kid' in the COSE object of
      the request (see Section 5).

   o  request_seq:  request_piv: contains the value of the 'Partial IV' in the COSE
      object of the request (see Section 5).

   o  options: contains the (non-special) Class I options (see
      Section 4.2.2) present in the original CoAP message encoded as
      described in Section 3.1 of [RFC7252], where the delta is the
      difference to the previously included class I option.

6.  Sequence Numbers, Replay, Message Binding, and Freshness

   Sequence numbers

6.1.  Message Binding

   In order to prevent response delay and replay window are initialized as defined mismatch attacks
   [I-D.mattsson-core-coap-actuators] from on-path attackers and
   compromised proxies, OSCORE binds responses to the request by
   including the request's ID (Sender ID or Recipient ID) and Partial IV
   in
   Section 3.2.2.

6.1. the AAD of the response.  The server therefore needs to store the
   request's ID (Sender ID or Recipient ID) and Partial IV until all
   responses have been sent.

6.2.  AEAD Nonce Uniqueness

   An AEAD nonce MUST NOT be used more than once per AEAD key.  In order
   to assure unique nonces, each Sender Context contains a Sender
   Sequence Number used to protect requests, and - in case of Observe -
   responses.  If messages are processed concurrently, the operation of
   reading and increasing the Sender Sequence Number MUST be atomic.

   The maximum sequence number Sender Sequence Number is algorithm dependent, see
   Section 10. 11.  If the Sender Sequence Number exceeds the maximum sequence
   number, maximum, the
   endpoint MUST NOT process any more messages with the given Sender
   Context.  The endpoint SHOULD acquire a new security context (and
   consequently inform the other endpoint) before this happens.  The
   latter is out of scope of this document.

6.2.  Replay Protection

   In order to protect from replay of messages, each Recipient Context
   contains a Replay Window used

6.3.  Freshness

   For requests, OSCORE provides weak absolute freshness as the only
   guarantee is that the request is not older than the security context.
   For applications having stronger demands on request freshness (e.g.,
   control of actuators), OSCORE needs to verify request, be augmented with mechanisms
   providing freshness [I-D.amsuess-core-repeat-request-tag].

   For responses, the message binding guarantees that a response is not
   older than its request.  For responses without Observe, this gives
   strong absolute freshness.  For responses with Observe, the absolute
   freshness gets weaker with time, and - it is RECOMMENDED that the
   client regularly restart the observation.

   For requests, and responses with Observe, OSCORE also provides
   relative freshness in case the sense that the received Partial IV allows a
   recipient to determine the relative order of
   Observe - responses.

6.4.  Replay Protection

   In order to protect from replay of requests, the server's Recipient
   Context includes a Replay Window.  A receiving endpoint server SHALL verify that a
   Sequence Number (Partial IV)
   Partial IV received in the COSE object has not been received before in the Recipient Context.  For requests, if before.
   If this verification fails and the message received is a CON message,
   the server SHALL respond with a 4.00 Bad Request 5.03 Service Unavailable error message.
   message with the inner Max-Age option set to 0.  The diagnostic
   payload MAY contain the "Replay protection failed" string.
   For responses, if this verification fails and the message received is
   a CON message, the client SHALL respond with an empty ACK and stop
   processing the response.  The size
   and type of the Replay Window depends on the use case and lower
   protocol layers.  In case of reliable and ordered transport from
   endpoint to endpoint, the recipient server MAY just store the last received sequence number
   Partial IV and require that newly received Sequence
   Numbers Partial IVs equals the
   last received Sequence Number Partial IV + 1.

6.3.  Sequence Number and Replay Window State

   To prevent reuse of

   Responses to non-Observe requests are protected against replay as
   they are cryptographically bound to the Nonce/Sequence Number with request.

   In the same key, or
   from accepting replayed messages, case of Observe, a node needs to handle client receiving a notification SHALL
   verify that the
   situation of suddenly losing sequence number Partial IV of a received notification is greater than
   the Notification Number bound to that Observe registration.  If the
   verification fails, the client SHALL stop processing the response,
   and replay window state in RAM, e.g. as the case of CON respond with an empty ACK.  If the
   verification succeeds, the client SHALL overwrite the corresponding
   Notification Number with the received Partial IV.

   If messages are processed concurrently, the Partial IV needs to be
   validated a result second time after decryption and before updating the
   replay protection data.  The operation of validating the Partial IV
   and updating the replay protection data MUST be atomic.

6.5.  Losing Part of the Context State

   To prevent reuse of the Nonce with the same key, or from accepting
   replayed messages, a node needs to handle the situation of losing
   rapidly changing parts of the context, such as the request Token,
   Sender Sequence Number, Replay Window, and Nofitifcation Numbers.
   These are typically stored in RAM and therefore lost in the case of
   an unplanned reboot.

   After boot, a node MAY reject to use existing security contexts from
   before it booted and MAY establish a new security context with each
   party it communicates, e.g. using EDHOC
   [I-D.selander-ace-cose-ecdhe]. communicates.  However, establishing a fresh security
   context may have a non-negligible cost in terms of e.g. of, e.g., power
   consumption.

   If

   After boot, a node MAY use a partly persistently stored security context is to be used after reboot,
   context, but then the node MUST NOT reuse a previous Sender Sequence
   Number and MUST NOT accept previously accepted messages.

6.3.1.  The Basic Case  Some ways
   to achieve this is described below:

6.5.1.  Sequence Number

   To prevent reuse of Sender Sequence Number, the Numbers, a node MAY perform the
   following procedure during normal operations:

   o  Before sending  Each time the Sender Sequence Number is evenly divisible by K,
      where K is a message, positive integer, store the client stores Sender Sequence Number in
      persistent memory a
      sequence number associated to the stored security context higher
      than any sequence number which has been or are being sent using
      this security context. memory.  After boot, the client does not use any
      lower sequence number in a request than what was persistently node initiates the Sender
      Sequence Number to the value stored with that security context.

      * in persistent memory + K - 1.
      Storing to persistent memory can be costly.  Instead of storing
         a sequence number for each request, the client may store Seq +
         K to persistent memory every K requests, where Seq is the
         current sequence number and  The value K > 1.  This is gives a
      trade-off between the number of storage operations and efficient
      use of sequence
         numbers. Sender Sequence Numbers.

6.5.2.  Replay Window

   To prevent accepting replay of previously received messages, requests, the node
   server MAY perform the following procedure: procedure after boot:

   o  After boot, before verifying a message using a security context
      stored before boot, the server synchronizes the replay window so
      that no old messages are being accepted.  The server uses the
      Repeat option [I-D.amsuess-core-repeat-request-tag] for
      synchronizing the replay window:  For each stored security context, the first time after boot the
      server receives an OSCOAP OSCORE request,
      it generates a pseudo-random nonce and responds with the server uses the Repeat
      option set [I-D.amsuess-core-repeat-request-tag] to the nonce as described in
      [I-D.amsuess-core-repeat-request-tag].  If the server receives get a
      repeated OSCOAP request containing the Repeat option with
      verifiable freshness and uses that to synchronize the same
      nonce, and if replay
      window.  If the server can verify the fresh request, then the sequence
      number obtained Partial
      IV in the repeated message fresh request is set as the lower limit of the replay
      window.

6.3.2.  The

6.5.3.  Replay Protection of Observe Case Notifications

   To prevent reuse of Sequence Number in case accepting replay of Observe, previously received notification
   responses, the node client MAY perform the following procedure during normal operations: after boot:

   o  Before sending a notification, the server stores in persistent
      memory a sequence number associated  The client rejects notifications bound to the stored security context
      higher than any sequence number for which a notification has been
      or are being sent earlier
      registration, removes all Notification Numbers and re-register
      using this security context.  After boot, Observe.

7.  Processing

   This section describes the
      server does not use any lower sequence number in an Observe
      response than what was persistently stored with that security
      context.

      *  Storing to persistent memory can be costly.  Instead of storing OSCORE message processing.

7.1.  Protecting the Request

   Given a sequence number for each notification, CoAP request, the server may store
         Seq + K client SHALL perform the following steps to persistent memory every K requests, where Seq is the
         current sequence number and K > 1.  This is a trade-off between
         the number of storage operations and efficient use of sequence
         numbers.

   Note that a client MAY continue an ongoing observation after reboot
   using a stored security context.  With Observe, the client can only
   verify the order of the notifications, as they may be delayed.  If
   the client wants to synchronize with a server resource it MAY restart
   an observation.

6.4.  Freshness

   For responses without Observe, OSCOAP provides absolute freshness.
   For requests, and responses with Observe, OSCOAP provides relative
   freshness in the sense that the sequence numbers allows a recipient
   to determine the relative order of messages.

   For applications having stronger demands on freshness (e.g. control
   of actuators), OSCOAP needs to be augmented with mechanisms providing
   absolute freshness [I-D.mattsson-core-coap-actuators].

6.5.  Delay and Mismatch Attacks

   In order to prevent response delay and mismatch attacks
   [I-D.mattsson-core-coap-actuators] from on-path attackers and
   compromised proxies, OSCOAP binds responses to the request by
   including the request's ID (Sender ID or Recipient ID) and sequence
   number in the AAD of the response.  The server therefore needs to
   store the request's ID (Sender ID or Recipient ID) and sequence
   number until all responses have been sent.

7.  Processing

7.1.  Protecting the Request

   Given a CoAP request, the client SHALL perform the following steps to
   create an OSCOAP request:

   1.  Retrieve
   create an OSCORE request:

   1.  Retrieve the Sender Context associated with the target resource.

   2.  Compose the Additional Authenticated Data, as described in
       Section 5.

   3.  Compose  Compute the AEAD nonce by XORing from the Context Sender ID, Common IV, and Partial
       IV (Sender IV) with
       the partial IV (Sequence Sequence Number in network byte order).  Then (in one
       atomic operation, see Section 6.2) increment the Sender Sequence
       Number by one.

   4.  Encrypt the COSE object using the Sender Key. Compress the COSE
       Object as specified in Section 8.

   5.  Format the OSCOAP OSCORE message according to Section 4.  The Object-
       Security option is added, see Section 4.3.4. 4.2.2.

   6.  Store the association Token - Security Context.  The client SHALL
       be able to find the Recipient Context from the Token in the
       response.

   7.  Increment the Sequence Number by one.

7.2.  Verifying the Request

   A server receiving a request containing the Object-Security option
   SHALL perform the following steps:

   1.   Process outer Block options according to [RFC7959], until all
        blocks of the request have been received, see Section 4.3.1.2. 4.2.3.2.

   2.  Decompress   Discard the COSE Object (Section 8) message Code and retrieve the Recipient
       Context associated all non-special Inner option
        message fields (marked with the 'x' in column E of Figure 4) present
        in the received message.  For example, an If-Match Outer option
        is discarded, but an Uri-Host Outer option is not discarded.

   3.   Decompress the COSE Object (Section 8) and retrieve the
        Recipient Context associated with the Recipient ID in the 'kid'
        parameter.  If the request is a NON message and either the
        decompression or the COSE message fails to decode, or the server
        fails to retrieve a Recipient Context with Recipient ID
        corresponding to the 'kid' parameter received, then the server
        SHALL stop processing the request.  If the request is a CON
        message, and:

        *  either the decompression or the COSE message fails to decode,
           the server SHALL respond with a 4.02 Bad Option error
           message.  The diagnostic payload SHOULD contain the string
           "Failed to decode COSE".

        *  the server fails to retrieve a Recipient Context with
           Recipient ID corresponding to the 'kid' parameter received,
           the server SHALL respond with a 4.01 Unauthorized error
           message.  The diagnostic payload MAY contain the string
           "Security context not found".

   If the request is a NON message and either the decompression or the
   COSE message fails to decode, or the server fails to retrieve a
   Recipient Context with Recipient ID corresponding to the 'kid'
   parameter received, then the server SHALL stop processing the
   request.

   1.

   4.   Verify the Sequence Number in the 'Partial IV' parameter, parameter using the Replay Window, as
        described in Section 6.

   2.

   5.   Compose the Additional Authenticated Data, as described in
        Section 5.

   3.  Compose

   6.   Compute the AEAD nonce by XORing from the Context IV (Recipient IV)
       with Recipient ID, Common IV, and the padded
        'Partial IV' parameter, received in the COSE Object.

   4.

   7.   Decrypt the COSE object using the Recipient Key.

        *  If decryption fails, the server MUST stop processing the
           request and, if the request is a CON message, the server MUST
           respond with a 4.00 Bad Request error message.  The
           diagnostic payload MAY contain the "Decryption failed"
           string.

        *  If decryption succeeds, update the Recipient Replay Window, as
           described in Section 6.

   5.

   8.   For each decrypted option, check if the option is also present
        as an Outer option: if it is, discard the Outer.  For example:
        the message contains a Max-Age Inner and a Max-Age Outer option.
        The Outer Max-Age is discarded.

   9.   Add decrypted code, options and payload to the decrypted request,
       processing the E options as described in (Section 4).
        request.  The Object-Security option is removed.

   6.

   10.  The decrypted CoAP request is processed according to [RFC7252]

7.3.  Protecting the Response

   Given a CoAP response, the server SHALL perform the following steps
   to create an OSCOAP response: OSCORE response.  Note that CoAP error responses derived
   from CoAP processing (point 10. in Section 7.2) are protected, as
   well as successful CoAP responses, while the OSCORE errors (point 3.,
   4., 7. in Section 7.2) do not follow the processing below, but are
   sent as simple CoAP responses, without OSCORE processing.

   1.  Retrieve the Sender Context in the Security Context used to
       verify the request.

   2.  Compose the Additional Authenticated Data, as described in
       Section 5.

   3.  Compose  Compute the AEAD nonce

       *  If Observe is not used, compose the AEAD nonce by XORing the
          Context IV (Sender IV with the most significant bit in the
          first byte flipped) with the padded Partial IV parameter from the request. request is used.

       *  If Observe is used, compose Compute the AEAD nonce by XORing the
          Context IV (Sender IV) with from the Sender ID,
          Common IV, and Partial IV of the response
          (Sequence (Sender Sequence Number in network
          byte order).  Then (in one atomic operation, see Section 6.2)
          increment the Sender Sequence Number by one.

   4.  Encrypt the COSE object using the Sender Key. Compress the COSE
       Object as specified in Section 8.

   5.  Format the OSCOAP OSCORE message according to Section 4.  The Object-
       Security option is added, see Section 4.3.4.

   6.  If Observe is used, increment the Sequence Number by one. 4.2.2.

7.4.  Verifying the Response

   A client receiving a response containing the Object-Security option
   SHALL perform the following steps:

   1.   Process outer Block options according to [RFC7959], until all
        blocks of the OSCOAP OSCORE message have been received, see
        Section 4.3.1.2. 4.2.3.2.

   2.   Discard the message Code and all non-special Class E options
        from the message.  For example, ETag Outer option is discarded,
        Max-Age Outer option is not discarded.

   3.   Retrieve the Recipient Context associated with the Token.
        Decompress the COSE Object (Section 8).  If the response is a CON
       message and either the
        decompression or the COSE message fails to decode, then the client SHALL send an empty ACK back and stop
       processing the response.  If the response is a NON message and
       any of the previous conditions appear, then the client SHALL
       simply stop processing the response.

   1. go to
        11.

   4.   For Observe notifications, verify the Sequence Number in the received 'Partial IV'
        parameter against the corresponding Notification Number as
        described in Section 6.

   2.  If the client receives a notification
        for which no Observe request was sent, then go to 11.

   5.   Compose the Additional Authenticated Data, as described in
        Section 5.

   3.  Compose

   6.   Compute the AEAD nonce

        *  If the Observe option is not present in the response, compose the AEAD
           nonce by XORing the Context IV (Recipient IV with the
          the most significant bit in the first byte flipped) with the
          padded Partial IV parameter from the request. request is used.

        *  If the Observe option is present in the response, compose compute the
           AEAD nonce by XORing from the Context IV (Recipient IV) with Recipient ID, Common IV, and the
          padded Partial IV parameter from 'Partial
           IV' parameter, received in the response.

   4. COSE Object.

   7.   Decrypt the COSE object using the Recipient Key.

        *  If decryption fails, the client MUST stop processing the
          response and, if the response is a CON message, the client
          MUST respond with an empty ACK back. then go to 11.

        *  If decryption succeeds and Observe is used, update the
          Recipient Replay Window,
           corresponding Notification Number, as described in Section 6.

   5.  Add

   8.   For each decrypted option, check if the option is also present
        as an Outer option: if it is, discard the Outer.  For example:
        the message contains a Max-Age Inner and a Max-Age Outer option.
        The Outer Max-Age is discarded.

   9.   Add decrypted code, options or and payload to the decrypted response
       overwriting any outer E options (see Section 4).
        request.  The Object-
       Security Object-Security option is removed.

       *  If Observe is used, replace the Observe value with the 3 least
          significant bytes in the sequence number.

   6.

   10.  The decrypted CoAP response is processed according to [RFC7252]

   11.  (Optional) In case any of the previous erroneous conditions
        apply: if the response is a CON message, then the client SHALL
        send an empty ACK back and stop processing the response; if the
        response is a ACK or a NON message, then the client SHALL simply
        stop processing the response.

8.  OSCOAP  OSCORE Compression

   The Concise Binary Object Representation (CBOR) [RFC7049] combines
   very small message sizes with extensibility.  The CBOR Object Signing
   and Encryption (COSE) [I-D.ietf-cose-msg] [RFC8152] uses CBOR to create compact encoding
   of signed and encrypted data.  COSE is however constructed to support
   a large number of different stateless use cases, and is not fully
   optimized for use as a stateful security protocol, leading to a
   larger than necessary message expansion.  In this section section, we define
   a simple stateless compression mechanism for OSCOAP, OSCORE called the
   "compressed COSE object", which significantly reduces the per-packet
   overhead.

8.1.  Encoding of the Object-Security Option Value

   The value of the Object-Security option SHALL be encoded contain the OSCORE flag
   byte and the kid parameter as follows:

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |0 0 0|h|k|  n  |    kid (if any) ...
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                      Figure 7: Object-Security Value

   o  The first byte MUST encode (= the OSCORE flag byte) encodes a set of flags and
      the length of the Partial IV parameter.

      *  The three least significant bits bits, n, encode the Partial IV size.
         length + 1.  If their value is 0, n = 0 then the Partial IV is not present in the
         compressed message. COSE object.  The value n = 7 is reserved.

      *  The fourth least significant bit is the kid flag, k: it is set
         to 1 if the kid is present in the compressed message. COSE object.

      *  The fifth-eighth fifth least significant bits (= most bit is the Context Hint flag, h: it
         is set to 1 if the compressed COSE object contains a Context
         Hint, see Section 8.3.

      *  The sixth-eighth least significant
         half-byte) bits are reserved and SHALL
         be set to zero when not in use.

   o  The following n remaining bytes (n being the value of the Partial IV size in
      the first byte) encode the value of the Partial IV, if the Partial
      IV is present (size not 0).

   o  The following byte encodes the size of the kid parameter, if the
      kid is present (flag bit set to 1)

   o  The following m bytes (m given by the previous byte) encode encode the value of the kid, if the kid is
      present (flag bit set to (k = 1)

   o  The remainining bytes encode the ciphertext.

   The presence of Partial IV and kid in requests and responses is
   specified in Section 5, and summarized in Figure 6.

              7 6 5 4 3 2 1 0
             +-+-+-+-+-+-+-+-+  k: kid flag bit
             |0 0 0 0|k|pivsz|  pivsz: Partial IV size (3 bits)
             +-+-+-+-+-+-+-+-+

           +-------+---------+------------+-----------+
           |       | Request 8.

                 +--------------------------+-----+-----+
                 | Resp with-                          | Resp with  k  |  n  |
                 +--------------------------+-----+-----+
                 | Request                  | out observe| observe  1  |
           +-------+---------+------------+-----------+ > 0 |     k
                 |    1 Response without Observe |  0  |   0 |
                 | pivsz |  > 0 Response with Observe    |  0  | > 0 |
           +-------+---------+------------+-----------+
                 +--------------------------+-----+-----+

           Figure 6: Flag 8: Presence of data fields in OSCORE flag byte for OSCOAP compression

8.2.  Examples

   This section provides examples  Encoding of COSE Objects before and after
   OSCOAP compression.

8.2.1.  Example: Request

   Before compression:

   [
   h'',
   { 4:h'25', 6:h'05' },
   h'aea0155667924dff8a24e4cb35b9'
   ]

   0x83 40 a2 04 41 25 06 41 05 4e ae a0 15 56 67 92
   4d ff 8a 24 e4 cb 35 b9 (24 bytes)

   After compression:

   First byte: 0b00001001 the OSCORE Payload

   The payload of the OSCORE message SHALL be encoded as follows:

   o  The first n - 1 bytes encode the value of the Partial IV, if the
      Partial IV is present (n > 0).

   o  The following 1 byte encode the length of the Context Hint
      (Section 8.3), s, if the Context Hint flag is set (h = 0x09

   0x09 05 01 25 ae a0 15 56 67 92 4d ff 8a 24 e4 cb
   35 b9 (18 bytes)

8.2.2.  Example: Response (without Observe)

   Before compression:

   [
   h'',
   {},
   h'aea0155667924dff8a24e4cb35b9'
   ] 1).

   o  The following s bytes encode the Context Hint, if the Context Hint
      flag is set (h = 1).

   o  The remaining bytes encode the ciphertext.

8.3.  Context Hint

   For certain use cases, e.g. deployments where the same Recipient ID
   is used with multiple contexts, it is necessary or favorable for the
   sending endpoint to provide a Context Hint in order for the receiving
   endpoint to retrieve the recipient context.  The Context Hint is
   implicitly integrity protected, as a manipulation leads to the wrong
   or no context being retrieved resulting in a verification error.

   Examples:

   o  If the sending endpoint has an identifier in some other namespace
      which can be used by the recipient endpoint to retrieve or
      establish the security context, then that identifier can be used
      as Context Hint.

   o  In case of a group communication scenario
      [I-D.tiloca-core-multicast-oscoap], if the recipient endpoint
      belongs to multiple groups, involving the same endpoints, then a
      group identifier can be used as Context Hint to enable the
      receiving endpoint to find the right group security context.

8.4.  Compression Examples

   This section provides examples of COSE Objects before and after
   OSCORE compression.

8.4.1.  Example: Request

   Before compression:

   [
   h'',
   { 4:h'25', 6:h'05' },
   h'aea0155667924dff8a24e4cb35b9'
   ]

   0x83 40 a0 a2 04 41 25 06 41 05 4e ae a0 15 56 67 92
   4d ff 8a 24 e4 cb 35 b9 (18 (24 bytes)
   After compression:

   First

   Flag byte: 0b00000000 0b00001010 = 0x00

   0x00 0x0a

   Option Value: 0a 25 (2 bytes)

   Payload: 05 ae a0 15 56 67 92 4d ff 8a 24 e4 cb 35 b9 (15 bytes)

8.2.3.

8.4.2.  Example: Response (with Observe) Request 2

   Before compression:

   [
   h'',
   { 6:h'07' 4:h'00', 6:h'00' },
   h'aea0155667924dff8a24e4cb35b9'
   ]

   0x83 40 a1 a2 04 41 00 06 41 07 00 4e ae a0 15 56 67 92
   4d ff 8a 24 e4 cb 35 b9 (21 (24 bytes)

   After compression:

   First

   Flag byte: 0b00000001 0b00001001 = 0x01

   0x01 07 0x09

   Option Value: 09 (1 bytes)

   Payload: ae a0 15 56 67 92 4d ff 8a 24 e4 cb 35 b9
   (16 (14 bytes)

9.  Web Linking

   The use of OSCOAP MAY be indicated by a target attribute "osc" in a
   web link [RFC5988] to a CoAP resource.  This attribute is a hint
   indicating that the destination of that link is to be accessed using
   OSCOAP.  Note that this

8.4.3.  Example: Response (without Observe)

   Before compression:

   [
   h'',
   {},
   h'aea0155667924dff8a24e4cb35b9'
   ]

   0x83 40 a0 4e ae a0 15 56 67 92 4d ff 8a 24 e4 cb
   35 b9 (18 bytes)

   After compression:

   Flag byte: 0b00000000 = 0x00

   Option Value: (0 bytes)

   Payload: ae a0 15 56 67 92 4d ff 8a 24 e4 cb 35 b9 (14 bytes)

8.4.4.  Example: Response (with Observe)

   Before compression:

   [
   h'',
   { 6:h'07' },
   h'aea0155667924dff8a24e4cb35b9'
   ]

   0x83 40 a1 06 41 07 4e ae a0 15 56 67 92 4d ff
   8a 24 e4 cb 35 b9 (21 bytes)

   After compression:

   Flag byte: 0b00000010 = 0x02

   Option Value: 02 (1 bytes)

   Payload: 07 ae a0 15 56 67 92 4d ff 8a 24 e4 cb 35 b9 (15 bytes)

9.  Web Linking

   The use of OSCORE MAY be indicated by a target attribute "osc" in a
   web link [RFC5988] to a resource.  This attribute is a hint
   indicating that the destination of that link is to be accessed using
   OSCORE.  Note that this is simply a hint, it does not include any
   security context material or any other information required to run
   OSCOAP.
   OSCORE.

   A value MUST NOT be given for the "osc" attribute; any present value
   MUST be ignored by parsers.  The "osc" attribute MUST NOT appear more
   than once in a given link-value; occurrences after the first MUST be
   ignored by parsers.

10.  Security Considerations

   In scenarios  Proxy Operations

   RFC 7252 defines operations for a CoAP-to-CoAP proxy (see Section 5.7
   of [RFC7252]) and for proxying between CoAP and HTTP (Section 10 of
   [RFC7252]).  A more detailed description of the HTTP-to-CoAP mapping
   is provided by [RFC8075].  This section describes the operations of
   OSCORE-aware proxies.

10.1.  CoAP-to-CoAP Forwarding Proxy

   OSCORE is designed to work with intermediary nodes such as legacy CoAP-to-CoAP forward proxies or brokers,
   transport layer security such
   [RFC7252], but OSCORE-aware proxies provide certain simplifications
   as DTLS only protects data hop-by-hop.
   As a consequence the intermediary nodes can read and modify
   information. specified in this section.

   The trust model where all intermediate nodes targeted proxy operations are
   considered trustworthy specified in Section 2.2.1 of
   [I-D.hartke-core-e2e-security-reqs].  In particular caching is problematic, not only from
   disabled since the CoAP response is only applicable to the original
   client's CoAP request.  An OSCORE-aware proxy SHALL NOT cache a privacy
   perspective, but also from
   response to a security perspective, as request with an Object-Security option.  As a
   consequence, the
   intermediaries are free to delete resources on sensors search for cache hits and falsify
   commands to actuators (such CoAP freshness/Max-Age
   processing can be omitted.

   Proxy processing of the (Outer) Proxy-Uri option is as "unlock door", "start fire alarm",
   "raise bridge").  Even defined in
   [RFC7252].

   Proxy processing of the rare cases, where all (Outer) Block options is as defined in
   [RFC7959] and [I-D.amsuess-core-repeat-request-tag].

   Proxy processing of the owners (Outer) Observe option is as defined in
   [RFC7641].  OSCORE-aware proxies MAY look at the Partial IV value
   instead of the
   intermediary nodes are fully trusted, attacks Outer Observe option.

10.2.  HTTP-to-CoAP Translation Proxy

   Section 10.2 of [RFC7252] and data breaches make
   such [RFC8075] specify the behavior of an architecture brittle.

   DTLS protects hop-by-hop
   HTTP-to-CoAP proxy.  As requested in Section 1 of [RFC8075], this
   section describes the entire CoAP message, including header,
   options, and payload.  OSCOAP protects end-to-end HTTP mapping for the payload, OSCORE protocol extension
   of CoAP.

   The presence of the Object-Security option, both in requests and
   all information
   responses, is expressed in an HTTP header field named Object-Security
   in the options and header, that mapped request or response.  The value of the field is not required for
   forwarding (see Section 4).  DTLS and OSCOAP can be combined, thereby
   enabling end-to-end security the
   value of CoAP payload, the Object-Security option Section 8.1 in combination with
   hop-by-hop protection base64url encoding
   (Section 5 of the entire CoAP message, during transport
   between end-point and intermediary node. [RFC4648]) without padding (see [RFC7515] Appendix C
   for implementation notes for this encoding).  The CoAP message layer, however, cannot be protected end-to-end
   through intermediary devices since value of the parameters Type and Message
   ID, as well as Token and Token Length may be changed by a proxy.
   Moreover, messages that are not possible to verify should for
   security reasons not always be acknowledged but in some cases be
   silently dropped.  This would not comply with CoAP message layer, but
   does not have an impact on
   payload is the application layer security solution,
   since message layer OSCORE payload Section 8.2, also base64url-encoded
   without padding.

   Example:

   Mapping and notation here is excluded from that.

   The use based on "Simple Form" (Section 5.4.1.1
   of COSE [RFC8075]).

 [HTTP request -- Before object security processing]

   GET http://proxy.url/hc/?target_uri=coap://device.url/orders HTTP/1.1

 [HTTP request -- HTTP Client to Proxy]

   POST http://proxy.url/hc/?target_uri=coap://device.url/ HTTP/1.1
   Object-Security: 0b 25
   Body: 09 07 01 13 61 f7 0f d2 97 b1 [binary]

 [CoAP request -- Proxy to protect CoAP messages as specified in this
   document requires an established security context.  The method Server]

   POST coap://device.url/
   Object-Security: 0b 25
   Payload: 09 07 01 13 61 f7 0f d2 97 b1 [binary]

 [CoAP response -- CoAP Server to
   establish the Proxy]

   2.04 Changed
   Object-Security: [empty]
   Payload: 00 31 d1 fc f6 70 fb 0c 1d d5 ... [binary]

 [HTTP response -- Proxy to HTTP Client]

   HTTP/1.1 200 OK
   Object-Security: [empty]
   Body: 00 31 d1 fc f6 70 fb 0c 1d d5 ... [binary]

 [HTTP response -- After object security context described processing]

   HTTP/1.1 200 OK
   Body: Exterminate! Exterminate!

   Note that the HTTP Status Code 200 in Section 3.2 the next-to-last message is based on a
   common shared secret material in client and server, which may be
   obtained e.g. by using EDHOC [I-D.selander-ace-cose-ecdhe] or the ACE
   framework [I-D.ietf-ace-oauth-authz].  An OSCOAP profile
   mapping of ACE is
   described in [I-D.seitz-ace-oscoap-profile].

   The mandatory-to-implement AEAD algorithm AES-CCM-64-64-128 is
   selected for broad applicability CoAP Code 2.04 (Changed), whereas the HTTP Status Code 200
   in terms of the last message size (2^64
   blocks) and maximum number of messages (2^56).  Compatibility with
   CCM* is achieved by using the algorithm AES-CCM-16-64-128
   [I-D.ietf-cose-msg].

   Most AEAD algorithms require a unique nonce for each message, for
   which mapping of the sequence numbers in CoAP Code 2.05 (Content),
   which was encrypted within the compressed COSE message field "Partial IV" is
   used.  If object carried in the recipient accepts any sequence number larger than
   Body of the
   one previously received, then HTTP response.

10.3.  CoAP-to-HTTP Translation Proxy

   Section 10.1 of [RFC7252] describes the problem behavior of sequence number
   synchronization is avoided.  With reliable transport it may be
   defined that only messages with sequence number which are equal to
   previous sequence number + 1 are accepted.  The alternatives to
   sequence numbers have their issues: very constrained devices may a CoAP-to-HTTP
   proxy.  RFC 8075 [RFC8075] does not
   be able to support accurate time, or to generate cover this direction in any more
   detail and store large
   numbers so an example instantiation of random nonces.  The requirement to change key at counter
   wrap is a complication, but it also forces the user Section 10.1 of this
   specification [RFC7252]
   is used below.

   Example:

   [CoAP request -- Before object security processing]

     GET coap://proxy.url/
     Proxy-Uri=http://device.url/orders

   [CoAP request -- CoAP Client to think about implementing key renewal.

   The maximum sequence number Proxy]

     POST coap://proxy.url/
     Proxy-Uri=http://device.url/
     Object-Security: 0b 25
     Payload: 09 07 01 13 61 f7 0f d2 97 b1 [binary]

   [HTTP request -- Proxy to guarantee nonce uniqueness
   (Section 6.1) is algorithm dependent.  Using AES_CCM, with HTTP Server]

     POST http://device.url/ HTTP/1.1
     Object-Security: 0b 25
     Body: 09 07 01 13 61 f7 0f d2 97 b1 [binary]

   [HTTP response -- HTTP Server to Proxy]

     HTTP/1.1 200 OK
     Object-Security: [empty]
     Body: 00 31 d1 fc f6 70 fb 0c 1d d5 ... [binary]

   [CoAP response -- CoAP Server to Proxy]

     2.04 Changed
     Object-Security: [empty]
     Payload: 00 31 d1 fc f6 70 fb 0c 1d d5 ... [binary]

   [CoAP response -- After object security processing]

     2.05 Content
     Payload: Exterminate! Exterminate!

   Note that the
   maximum sequence number SHALL be 2^(min(nonce length in bits, 56) -
   1) - 1.  The "-1" HTTP Code 2.04 (Changed) in the exponent stems from next-to-last message is
   the same partial IV and
   flipped bit mapping of IV (Section 5) is used HTTP Status Code 200, whereas the CoAP Code 2.05
   (Content) in request and response.  The
   compression algorithm (Section 8) assumes that the partial IV is 56
   bits or less (which last message is the reason for min(,) value that was encrypted within
   the compressed COSE object carried in the exponent).

   The inner block options enable Body of the sender to split large messages
   into OSCOAP-protected blocks HTTP response.

11.  Security Considerations

   In scenarios with intermediary nodes such that as proxies or brokers,
   transport layer security such as (D)TLS only protects data hop-by-
   hop.  As a consequence, the receiving node intermediary nodes can verify
   blocks before having received the complete message. read and modify
   information.  The outer block
   options allow for arbitrary proxy fragmentation operations that
   cannot be verified by the endpoints, trust model where all intermediate nodes are
   considered trustworthy is problematic, not only from a privacy
   perspective, but can by policy be restricted also from a security perspective, as the
   intermediaries are free to delete resources on sensors and falsify
   commands to actuators (such as "unlock door", "start fire alarm",
   "raise bridge").  Even in size since the encrypted options allow for secure fragmentation of
   very large messages.  A maximum message size (above which rare cases, where all the sending
   endpoint fragments owners of the message
   intermediary nodes are fully trusted, attacks and data breaches make
   such an architecture brittle.

   (D)TLS protects hop-by-hop the receiving endpoint discards
   the entire message, if complying to including header,
   options, and payload.  OSCORE protects end-to-end the policy) may be obtained as part of
   normal resource discovery.

   Applications need to use a padding scheme if payload, and
   all information in the content of a message options and header, that is not required for
   proxy operations (see Section 4).  (D)TLS and OSCORE can be determined solely from the length combined,
   thereby enabling end-to-end security of the payload.  As an
   example, message payload, in
   combination with hop-by-hop protection of the strings "YES" entire message, during
   transport between end-point and "NO" intermediary node.  The message
   layer, however, cannot be protected end-to-end through intermediary
   devices since, even if encrypted can be
   distinguished from each other as there is no padding supplied by the
   current set of encryption algorithms.  Some information can protocol itself isn't translated, the
   parameters Type, Message ID, Token, and Token Length may be
   determined even from looking at boundary conditions.  An example changed
   by a proxy.

   The use of
   this would be returning an integer between 0 and 100 where lengths of
   1, 2 and 3 will provide information about where in the range things
   are.  Three different methods COSE to deal with this are: 1) ensure that
   all protect messages are as specified in this document
   requires an established security context.  The method to establish
   the same length.  For example using 0 security context described in Section 3.2 is based on a common
   shared secret material in client and 1 instead server, which may be obtained,
   e.g., by using the ACE framework [I-D.ietf-ace-oauth-authz].  An
   OSCORE profile of 'yes' and 'no'.  2) Use ACE is described in [I-D.seitz-ace-oscoap-profile].

   Most AEAD algorithms require a character unique nonce for each message, for
   which the sender sequence numbers in the COSE message field "Partial
   IV" is not part of used.  If the
   responses to pad to a fixed length.  For example, pad with a space to
   three characters.  3) Use recipient accepts any sequence number larger
   than the PKCS #7 style padding scheme where m
   bytes are appended each having one previously received, then the value of m.  For example,
   appending a 0 to "YES" and two 1's to "NO".  This style problem of padding
   means sequence number
   synchronization is avoided.  With reliable transport, it may be
   defined that all values need only messages with sequence number which are equal to be padded.

11.  Privacy Considerations

   Privacy threats executed through intermediate nodes
   previous sequence number + 1 are considerably
   reduced by means of OSCOAP.  End-to-end integrity protection accepted.  The alternatives to
   sequence numbers have their issues: very constrained devices may not
   be able to support accurate time, or to generate and
   encryption store large
   numbers of CoAP random nonces.  The requirement to change key at counter
   wrap is a complication, but it also forces the user of this
   specification to think about implementing key renewal.

   The maximum sender sequence number is dependent on the AEAD
   algorithm.  The maximum sender sequence number SHALL be 2^40 - 1, or
   any algorithm specific lower limit.  The compression mechanism
   (Section 8) assumes that the Partial IV is 40 bits or less.  The
   mandatory-to-implement AEAD algorithm AES-CCM-16-64-128 is selected
   for compatibility with CCM*.

   The inner block options enable the sender to split large messages
   into OSCORE-protected blocks such that the receiving node can verify
   blocks before having received the complete message.  The outer block
   options allow for arbitrary proxy fragmentation operations that
   cannot be verified by the endpoints, but can by policy be restricted
   in size since the encrypted options allow for secure fragmentation of
   very large messages.  A maximum message size (above which the sending
   endpoint fragments the message and the receiving endpoint discards
   the message, if complying to the policy) may be obtained as part of
   normal resource discovery.

12.  Privacy Considerations

   Privacy threats executed through intermediate nodes are considerably
   reduced by means of OSCORE.  End-to-end integrity protection and
   encryption of the message payload and all options that are not used
   for
   forwarding, proxy operations, provide mitigation against attacks on sensor
   and actuator communication, which may have a direct impact on the
   personal sphere.

   The unprotected options (Figure 4) may reveal privacy sensitive
   information.  In particular Uri-Host SHOULD NOT contain privacy
   sensitive information.

   CoAP headers sent in plaintext allow for example matching of CON and
   ACK (CoAP Message Identifier), matching of request and responses
   (Token) and traffic analysis.

   Using the mechanisms described in Section 6.3 reveals 6.5 may reveal when a
   device goes through a reboot.  This can be mitigated by the device
   storing the precise state of sender sequence number and recipient replay window
   on a clean shutdown.

12.  IANA Considerations

   Note to RFC Editor: Please replace all occurrences

   The length of "[[this
   document]]" with message fields can reveal information about the RFC number of this specification.

12.1.  CoAP Option Numbers Registry

   The Object-Security option is added
   message.  Applications may use a padding scheme to protect against
   traffic analysis.  As an example, the CoAP Option Numbers strings "YES" and "NO" even if
   encrypted can be distinguished from each other as there is no padding
   supplied by the current set of encryption algorithms.  Some
   information can be determined even from looking at boundary
   conditions.  An example of this would be returning an integer between
   0 and 100 where lengths of 1, 2 and 3 will provide information about
   where in the range things are.  Three different methods to deal with
   this are: 1) ensure that all messages are the same length.  For
   example, using 0 and 1 instead of 'yes' and 'no'. 2) Use a character
   which is not part of the responses to pad to a fixed length.  For
   example, pad with a space to three characters. 3) Use the PKCS #7
   style padding scheme where m bytes are appended each having the value
   of m.  For example, appending a 0 to "YES" and two 1's to "NO".  This
   style of padding means that all values need to be padded.  Similar
   arguments apply to other message fields such as resource names.

13.  IANA Considerations

   Note to RFC Editor: Please replace all occurrences of "[[this
   document]]" with the RFC number of this specification.

13.1.  CoAP Option Numbers Registry

   The Object-Security option is added to the CoAP Option Numbers
   registry:

             +--------+-----------------+-------------------+
             | Number | Name            | Reference         |
             +--------+-----------------+-------------------+
             |  TBD   | Object-Security | [[this document]] |
             +--------+-----------------+-------------------+

12.2.  Media Type

13.2.  Header Field Registrations

   The "application/oscon" media type HTTP header field Object-Security is added to the Media Types Message Headers
   registry:

       Type name: application

       Subtype name: oscon

       Required parameters: N/A

       Optional parameters: N/A

       Encoding considerations: binary

       Security considerations: See Appendix C of this document.

       Interoperability considerations: N/A

       Published specification:

      +-------------------+----------+----------+-------------------+
      | Header Field Name | Protocol | Status   | Reference         |
      +-------------------+----------+----------+-------------------+
      | Object-Security   | http     | standard | [[this document]] (this document)

       Applications that use this media type: To be identified

       Fragment identifier considerations: N/A

       Additional information:

       * Magic number(s): N/A

       * File extension(s): N/A

       * Macintosh file type code(s): N/A

       Person & email address to contact for further information:
          Goeran Selander <goran.selander@ericsson.com>

       Intended usage: COMMON

       Restrictions on usage: N/A

       Author: Goeran Selander, goran.selander@ericsson.com

12.3.  CoAP Content Format Registration

   The "application/oscon" content format is added to the CoAP Content
   Format registry:

        +-------------------+----------+-----+-------------------+
        | Media type        | Encoding |  ID | Reference         |
        +-------------------+----------+-----+-------------------+
        | application/oscon | -        | TBD | [[this document]] |
        +-------------------+----------+-----+-------------------+

13.  Acknowledgments

   The following individuals provided input to |
      +-------------------+----------+----------+-------------------+

14.  Acknowledgments

   The following individuals provided input to this document: Christian
   Amsuess, Tobias Andersson, Carsten Bormann, Joakim Brorsson, Thomas
   Fossati, Martin Gunnarsson, Klaus Hartke, Jim Schaad, Dave Thaler,
   Marco Tiloca, and Malisa Vu&#269;ini&#263;.

   Ludwig Seitz and Goeran Selander worked on this document as part of
   the CelticPlus project CyberWI, with funding from Vinnova.

14.

15.  References

14.1.

15.1.  Normative References

   [I-D.amsuess-core-repeat-request-tag]
              Amsuess, C., Mattsson, J., and G. Selander, "Repeat And
              Request-Tag", draft-amsuess-core-repeat-request-tag-00
              (work in progress), July 2017.

   [I-D.ietf-cose-msg]
              Schaad, J., "CBOR Object Signing and Encryption (COSE)",
              draft-ietf-cose-msg-24 (work in progress), November 2016.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <http://www.rfc-editor.org/info/rfc2119>.
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC4648]  Josefsson, S., "The Base16, Base32, and Base64 Data
              Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
              <https://www.rfc-editor.org/info/rfc4648>.

   [RFC5988]  Nottingham, M., "Web Linking", RFC 5988,
              DOI 10.17487/RFC5988, October 2010,
              <http://www.rfc-editor.org/info/rfc5988>.
              <https://www.rfc-editor.org/info/rfc5988>.

   [RFC6347]  Rescorla, E. and N. Modadugu, "Datagram Transport Layer
              Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
              January 2012, <http://www.rfc-editor.org/info/rfc6347>. <https://www.rfc-editor.org/info/rfc6347>.

   [RFC7049]  Bormann, C. and P. Hoffman, "Concise Binary Object
              Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049,
              October 2013, <http://www.rfc-editor.org/info/rfc7049>. <https://www.rfc-editor.org/info/rfc7049>.

   [RFC7252]  Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
              Application Protocol (CoAP)", RFC 7252,
              DOI 10.17487/RFC7252, June 2014,
              <http://www.rfc-editor.org/info/rfc7252>.
              <https://www.rfc-editor.org/info/rfc7252>.

   [RFC7641]  Hartke, K., "Observing Resources in the Constrained
              Application Protocol (CoAP)", RFC 7641,
              DOI 10.17487/RFC7641, September 2015,
              <http://www.rfc-editor.org/info/rfc7641>.
              <https://www.rfc-editor.org/info/rfc7641>.

   [RFC7959]  Bormann, C. and Z. Shelby, Ed., "Block-Wise Transfers in
              the Constrained Application Protocol (CoAP)", RFC 7959,
              DOI 10.17487/RFC7959, August 2016,
              <http://www.rfc-editor.org/info/rfc7959>.

14.2.
              <https://www.rfc-editor.org/info/rfc7959>.

   [RFC8075]  Castellani, A., Loreto, S., Rahman, A., Fossati, T., and
              E. Dijk, "Guidelines for Mapping Implementations: HTTP to
              the Constrained Application Protocol (CoAP)", RFC 8075,
              DOI 10.17487/RFC8075, February 2017,
              <https://www.rfc-editor.org/info/rfc8075>.

   [RFC8132]  van der Stok, P., Bormann, C., and A. Sehgal, "PATCH and
              FETCH Methods for the Constrained Application Protocol
              (CoAP)", RFC 8132, DOI 10.17487/RFC8132, April 2017,
              <https://www.rfc-editor.org/info/rfc8132>.

   [RFC8152]  Schaad, J., "CBOR Object Signing and Encryption (COSE)",
              RFC 8152, DOI 10.17487/RFC8152, July 2017,
              <https://www.rfc-editor.org/info/rfc8152>.

15.2.  Informative References

   [I-D.bormann-6lo-coap-802-15-ie]
              Bormann, C., "Constrained Application Protocol (CoAP) over
              IEEE 802.15.4 Information Element for IETF", draft-
              bormann-6lo-coap-802-15-ie-00 (work in progress), April
              2016.

   [I-D.greevenbosch-appsawg-cbor-cddl]
              Birkholz, H., Vigano, C., and C. Bormann, "CBOR "Concise data
              definition language (CDDL): a notational convention to
              express CBOR data structures", draft-greevenbosch-appsawg-
              cbor-cddl-10
              cbor-cddl-11 (work in progress), March July 2017.

   [I-D.hartke-core-e2e-security-reqs]
              Selander, G., Palombini, F., and K. Hartke, "Requirements
              for CoAP End-To-End Security", draft-hartke-core-e2e-
              security-reqs-02
              security-reqs-03 (work in progress), January July 2017.

   [I-D.ietf-ace-oauth-authz]
              Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and
              H. Tschofenig, "Authentication and Authorization for
              Constrained Environments (ACE)", draft-ietf-ace-oauth-
              authz-06
              authz-07 (work in progress), March August 2017.

   [I-D.ietf-core-coap-tcp-tls]
              Bormann, C., Lemay, S., Tschofenig, H., Hartke, K.,
              Silverajan, B., and B. Raymor, "CoAP (Constrained
              Application Protocol) over TCP, TLS, and WebSockets",
              draft-ietf-core-coap-tcp-tls-09 (work in progress), May
              2017.

   [I-D.mattsson-core-coap-actuators]
              Mattsson, J., Fornehed, J., Selander, G., and F.
              Palombini, "Controlling Actuators with CoAP", draft-
              mattsson-core-coap-actuators-02 (work in progress),
              November 2016.

   [I-D.seitz-ace-oscoap-profile]
              Seitz, L., Gunnarsson, M., and F. Palombini, F., and M. Gunnarsson, "OSCOAP
              profile of ACE", draft-seitz-ace-oscoap-profile-03 (work
              in progress), June 2017.

   [I-D.selander-ace-cose-ecdhe]
              Selander, G., Mattsson, J., the Authentication and F. Palombini, "Ephemeral
              Diffie-Hellman Over COSE (EDHOC)", draft-selander-ace-
              cose-ecdhe-06 Authorization for
              Constrained Environments Framework", draft-seitz-ace-
              oscoap-profile-04 (work in progress), April July 2017.

   [I-D.tiloca-core-multicast-oscoap]
              Tiloca, M., Selander, G., and F. Palombini, "Secure group
              communication for CoAP", draft-tiloca-core-multicast-
              oscoap-01
              oscoap-03 (work in progress), March July 2017.

   [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
              Resource Identifier (URI): Generic Syntax", STD 66,
              RFC 3986, DOI 10.17487/RFC3986, January 2005,
              <https://www.rfc-editor.org/info/rfc3986>.

   [RFC5869]  Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand
              Key Derivation Function (HKDF)", RFC 5869,
              DOI 10.17487/RFC5869, May 2010,
              <http://www.rfc-editor.org/info/rfc5869>.
              <https://www.rfc-editor.org/info/rfc5869>.

   [RFC7228]  Bormann, C., Ersue, M., and A. Keranen, "Terminology for
              Constrained-Node Networks", RFC 7228,
              DOI 10.17487/RFC7228, May 2014,
              <http://www.rfc-editor.org/info/rfc7228>.
              <https://www.rfc-editor.org/info/rfc7228>.

   [RFC7515]  Jones, M., Bradley, J., and N. Sakimura, "JSON Web
              Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May
              2015, <https://www.rfc-editor.org/info/rfc7515>.

Appendix A.  Test Vectors

   TODO: This section needs to be updated.

Appendix B.  Examples

   This section gives examples of OSCOAP. OSCORE.  The message exchanges are
   made, based on the assumption that there is a security context
   established between client and server.  For simplicity, these
   examples only indicate the content of the messages without going into
   detail of the COSE message format.

B.1.  Secure Access to Sensor

   This example targets the scenario in Section 3.1 of
   [I-D.hartke-core-e2e-security-reqs] and illustrates a client
   requesting the alarm status from a server.

      Client  Proxy  Server
        |       |       |
         +----->|
        +------>|       |            Code: 0.01 (GET) 0.02 (POST)
        | GET POST  |       |           Token: 0x8c
        |       |       | Object-Security: [kid:5f, seq:42, [kid:5f]
        |       |       |                   {Uri-Path:"alarm_status"}]         Payload: [Partial IV:42,
        |       |       |         Payload: -                  {Code:0.01,
        |       |       |                   Uri-Path:"alarm_status"}]
        |       |      +----->|       |
        |       +------>|            Code: 0.01 (GET) 0.02 (POST)
        |       | GET POST  |           Token: 0x7b
        |       |       | Object-Security: [kid:5f, seq:42, [kid:5f]
        |       |       |         Payload: [Partial IV:42,
        |                   {Uri-Path:"alarm_status"}]       |       |                  {Code:0.01,
        |       |         Payload: -       |                   Uri-Path:"alarm_status"}]
        |       |       |      |<-----+
        |       |<------+            Code: 2.05 (Content) 2.04 (Changed)
        |       | 2.05  2.04 |           Token: 0x7b
        |       |       | Object-Security: -
        |       |       |         Payload: [{"OFF"}] [{Code:2.05, "OFF"}]
        |       |       |
         |<-----+
        |<------+       |            Code: 2.05 (Content) 2.04 (Changed)
        | 2.05  2.04 |       |           Token: 0x8c
        |       |       | Object-Security: -
        |       |       |         Payload: [{"OFF"}] [{Code:2.05, "OFF"}]
        |       |       |

   Figure 7: 9: Secure Access to Sensor.  Square brackets [ ... ] indicate
      a COSE object.  Curly brackets { ... } indicate encrypted data.

   Since the method (GET) doesn't allow payload, the Object-Security
   option carries the COSE object as its value.  Since the response code
   (Content) allows payload, the COSE object is carried as the CoAP
   payload.

   The COSE header of the request contains an identifier (5f),
   indicating which security context was used to protect the message and
   a sequence number (42).  The option Uri-Path ("alarm_status") and
   payload ("OFF") are encrypted.

   The server verifies that the sequence number has not been received
   before.  The client verifies that the response is bound to the
   request.

B.2.  Secure Subscribe to Sensor

   This example targets the scenario in Section 3.2 of
   [I-D.hartke-core-e2e-security-reqs] and illustrates a client
   requesting subscription to a blood sugar measurement resource (GET
   /glucose), first receiving the value 220 mg/dl and then a second
   value 180 mg/dl.

 Client  Proxy  Server
    |      |      |
    +----->|      |            Code: 0.01 (GET)
    | GET  |      |           Token: 0x83
    |      |      |         Observe: 0
    |      |      | Object-Security: [kid:ca, seq:15,
    |      |      |                   {Uri-Path:"glucose"}]
    |      |      |         Payload: -
    |      |      |
    |      +----->|            Code: 0.01 (GET)
    |      | GET  |           Token: 0xbe
    |      |      |         Observe: 0
    |      |      | Object-Security: [kid:ca, seq:15,
    |      |      |                   {Uri-Path:"glucose"}]
    |      |      |         Payload: -
    |      |      |
    |      |<-----+            Code: 2.05 (Content)
    |      | 2.05 |           Token: 0xbe
    |      |      |         Observe: 000032
    |      |      | Object-Security: -
    |      |      |         Payload: [seq:32, {Content-Format:0, "220"}]
    |      |      |
    |<-----+      |            Code: 2.05 (Content)
    | 2.05 |      |           Token: 0x83
    |      |      |         Observe: 000032
    |      |      | Object-Security: -
    |      |      |         Payload: [seq:32, {Content-Format:0, "220"}]
   ...    ...    ...
    |      |      |
    |      |<-----+            Code: 2.05 (Content)
    |      | 2.05 |           Token: 0xbe
    |      |      |         Observe: 000036
    |      |      | Object-Security: -
    |      |      |         Payload: [seq:36, {Content-Format:0, "180"}]
    |      |      |
    |<-----+      |            Code: 2.05 (Content)
    | 2.05 |      |           Token: 0x83
    |      |      |         Observe: 000036
    |      |      | Object-Security: -
    |      |      |         Payload: [seq:36, {Content-Format:0, "180"}]
    |      |      |

      Figure 8: Secure Subscribe to Sensor.  Square brackets [ ... ]
    indicate a COSE object.  Curly brackets { ... } indicate encrypted
                                   data.

   Since the method (GET) doesn't allow payload, the Object-Security
   option carries the COSE object as its value.  Since the response code
   (Content) allows payload, the COSE object is carried as the CoAP
   payload.

   The COSE header of the request contains an identifier (ca),
   indicating the security context used to protect the message and a
   Sequence Number (15).  The COSE header of the responses contains
   sequence numbers (32 and 36).  The options Content-Format (0) and the
   payload ("220" and "180"), are encrypted.  The Observe option is
   integrity protected.  The shown Observe values (000032 and 000036)
   are the ones that the client will see after OSCOAP processing.

   The server verifies that the sequence number has not been received
   before.  The client verifies that the sequence number has not been
   received before and that the responses are bound to the request.

Appendix C.  Object Security of Content (OSCON)

   TODO: This section needs to be updated.

   OSCOAP protects message exchanges end-to-end between a certain client
   and a certain server, targeting the security requirements for forward
   proxy of [I-D.hartke-core-e2e-security-reqs].  In contrast, many use
   cases require one and the same message to be protected for, and
   verified by, multiple endpoints, see caching proxy section of
   [I-D.hartke-core-e2e-security-reqs].  Those security requirements can
   be addressed by protecting essentially the payload/content of
   individual messages using the COSE format ([I-D.ietf-cose-msg]),
   rather than the entire request/response message exchange.  This is
   referred to as Object Security of Content (OSCON).

   OSCON transforms a CoAP message into an "OSCON message" in the
   following way: the payload of the original CoAP message is wrapped by
   a COSE object, which replaces the payload and this then becomes the
   OSCON message.

   The original payload shall be the plaintext/payload of the COSE
   object.  The 'protected' field of the COSE object 'Headers' shall
   include the context identifier, both for requests and responses.  If
   the original CoAP message includes a Content-Format option, then the
   COSE object shall include a protected 'content type' field, whose
   value is set to the original message Content-Format value.  The
   Content-Format option of the OSCOON message shall be replaced with
   "application/oscon" (Section 12)

   The COSE object shall be protected (encrypted) and verified
   (decrypted) as described in ([I-D.ietf-cose-msg]).

   Most AEAD algorithms require a unique nonce for each message.
   Sequence numbers for partial IV as specified for OSCOAP may be used
   for replay protection as described in Section 6.  The use of time
   stamps in the COSE header parameter 'operation time'
   [I-D.ietf-cose-msg] for freshness may be used.

   OSCON shall not be used in cases where CoAP header fields (such as
   Code or Version) or CoAP options need to be integrity protected or
   encrypted.  OSCON shall not be used in cases which require a secure
   binding between request and response.
      a COSE object.  Curly brackets { ... } indicate encrypted data.

   The scenarios request/response Codes are encrypted by OSCORE and only dummy
   Codes (POST/Changed) are visible in Sections 3.3 - 3.5 of
   [I-D.hartke-core-e2e-security-reqs] assume multiple recipients for a
   particular content.  In this case the use header of symmetric keys does not
   provide data origin authentication.  Therefore the COSE object should
   in general be protected with a digital signature.

C.1.  Overhead OSCON

   In general there are four different kinds of modes that need to be
   supported: message authentication code, digital signature,
   authenticated encryption, and symmetric encryption + digital
   signature. OSCORE message.
   The use of digital signature is necessary for
   applications with many legitimate recipients of a given message, option Uri-Path ("alarm_status") and
   where data origin authentication is required.

   To distinguish between these different cases, the tagged structures
   of COSE payload ("OFF") are used (see Section 2 of [I-D.ietf-cose-msg]).
   encrypted.

   The sizes of COSE messages for selected algorithms are detailed in
   this section.

   The size of the header is shown separately from the size of the MAC/
   signature.  A 4-byte Context Identifier and a 1-byte Sequence Number
   are request contains an identifier (5f),
   indicating which security context was used throughout all examples, with these values:

   o  Cid: 0xa1534e3c

   o  Seq: 0xa3

   For each scheme, we indicate to protect the fixed length of these two parameters
   ("Cid+Seq" column) message and of the Tag ("MAC"/"SIG"/"TAG").
   a Partial IV (42).

   The "Message
   OH" column shows the total expansions of the CoAP message size, while server verifies that the "COSE OH" column is calculated from Partial IV has not been received before.
   The client verifies that the previous columns.

   Overhead incurring from CBOR encoding response is also included in bound to the COSE
   overhead count.

   To make it easier request.

B.2.  Secure Subscribe to read, COSE objects are represented using CBOR's
   diagnostic notation rather than a binary dump.

C.2.  MAC Only Sensor

   This example is based on HMAC-SHA256, with truncation to 8 bytes
   (HMAC 256/64).

   Since the key is implicitly known by the recipient, targets the
   COSE_Mac0_Tagged structure is used (Section 6.2 of
   [I-D.ietf-cose-msg]).

   The object scenario in COSE encoding gives:

            996(                         # COSE_Mac0_Tagged
              [
                h'a20444a1534e3c0641a3', # protected:
                                           {04:h'a1534e3c',
                                            06:h'a3'}
                {},                      # unprotected
                h'',                     # payload
                MAC                      # truncated 8-byte MAC
              ]
            )

   This COSE object encodes Section 3.2 of
   [I-D.hartke-core-e2e-security-reqs] and illustrates a client
   requesting subscription to a total size of 26 bytes.

   Figure 9 summarizes these results.

          +------------------+-----+-----+---------+------------+ blood sugar measurement resource (GET
   /glucose), first receiving the value 220 mg/dl and then a second
   value 180 mg/dl.

      Client  Proxy  Server
        |     Structure       | Tid       | MAC
        +------>|       | COSE OH            Code: 0.05 (FETCH)
        | Message OH FETCH |
          +------------------+-----+-----+---------+------------+       | COSE_Mac0_Tagged           Token: 0x83
        | 5 B       | 8 B       |   13 B         Observe: 0
        |    26 B       |
          +------------------+-----+-----+---------+------------+

       Figure 9: Message overhead for a 5-byte Tid using HMAC 256/64

C.3.  Signature Only

   This example is based on ECDSA, with a signature of 64 bytes.

   Since only one signature is used, the COSE_Sign1_Tagged structure is
   used (Section 4.2 of [I-D.ietf-cose-msg]).

   The object in COSE encoding gives:

             997(                         # COSE_Sign1_Tagged
               [
                 h'a20444a1534e3c0641a3', # protected:
                                            {04:h'a1534e3c',
                                             06:h'a3'}
                 {},                      # unprotected
                 h'',                     # payload
                 SIG                      # 64-byte signature
               ]
             )

   This COSE object encodes to a total size of 83 bytes.

   Figure 10 summarizes these results.

         +-------------------+-----+------+---------+------------+       |     Structure Object-Security: [kid:ca]
        | Tid       |  SIG       | COSE OH         Payload: [Partial IV:15,
        | Message OH       |
         +-------------------+-----+------+---------+------------+       | COSE_Sign1_Tagged                  {Code:0.01,
        | 5 B       | 64 B       |   14 B                   Uri-Path:"glucose"}]
        |       |       |
        |       +------>|            Code: 0.05 (FETCH)
        |       | FETCH |           Token: 0xbe
        |       |       |         Observe: 0
        |       |       | Object-Security: [kid:ca]
        |       |       |         Payload: [Partial IV:15,
        |       |       |                  {Code:0.01,
        |       |       |                   Uri-Path:"glucose"}]
        |       |       |
        |       |<------+            Code: 2.05 (Content)
        |       |  2.05 |           Token: 0xbe
        |       |       |         Observe: 7
        |       |       | Object-Security: -
        |       |       |         Payload: [Partial IV:32,
        |       |       |                  {Code:2.05,
        |       |       |                   Content-Format:0, "220"}]
        |       |       |
        |<------+       |            Code: 2.05 (Content)
        |  2.05 |       |           Token: 0x83
        |       |       |         Observe: 7
        |       |       | Object-Security: -
        |       |       |         Payload: [Partial IV:32,
        |  83 bytes       |
         +-------------------+-----+------+---------+------------+

     Figure 10: Message overhead for a 5-byte Tid using 64 byte ECDSA
                                signature.

C.4.  Authenticated Encryption with Additional Data (AEAD)

   This example is based on AES-CCM with the Tag truncated to 8 bytes.

   Since the key is implicitly known by the recipient, the
   COSE_Encrypt0_Tagged structure is used (Section 5.2 of
   [I-D.ietf-cose-msg]).

   The object in COSE encoding gives:

993(                         # COSE_Encrypt0_Tagged
  [
    h'a20444a1534e3c0641a3', # protected:
                               {04:h'a1534e3c',
                                06:h'a3'}
    {},                      # unprotected
    ciphertext               # ciphertext including truncated 8-byte TAG
  ]
)

   This COSE object encodes to a total size of 25 bytes.

   Figure 11 summarizes these results.

        +----------------------+-----+-----+---------+------------+       |       Structure                  {Code:2.05,
        | Tid       | TAG       | COSE OH                   Content-Format:0, "220"}]
       ...     ...     ...
        | Message OH       |
        +----------------------+-----+-----+---------+------------+       | COSE_Encrypt0_Tagged
        | 5 B       |<------+            Code: 2.05 (Content)
        |       |  2.05 |           Token: 0xbe
        |       |       |         Observe: 8 B
        |   12 B       |  25 bytes       |
        +----------------------+-----+-----+---------+------------+

     Figure 11: Message overhead for a 5-byte Tid using AES_128_CCM_8.

C.5.  Symmetric Encryption with Asymmetric Signature (SEAS)

   This example is based on AES-CCM and ECDSA with 64 bytes signature.
   The same assumption on the security context as in Appendix C.4.  COSE
   defines the field 'counter signature w/o headers' that is used here
   to sign a COSE_Encrypt0_Tagged message (see Section 3 of
   [I-D.ietf-cose-msg]).

   The object in COSE encoding gives:

993(                         # COSE_Encrypt0_Tagged
  [
    h'a20444a1534e3c0641a3', # protected:
                               {04:h'a1534e3c',
                                06:h'a3'}
    {9:SIG},                 # unprotected:
                                09: 64 bytes signature
    ciphertext               # ciphertext including truncated 8-byte TAG
  ]
)

   This COSE object encodes to a total size of 92 bytes.

   Figure 12 summarizes these results.

    +----------------------+-----+-----+------+---------+------------+ Object-Security: -
        |       Structure       | Tid       | TAG         Payload: [Partial IV:36,
        | SIG       | COSE OH       | Message OH                  {Code:2.05,
        |
    +----------------------+-----+-----+------+---------+------------+       | COSE_Encrypt0_Tagged       | 5 B                   Content-Format:0, "180"}]
        |       |       |
        |<------+       |            Code: 2.05 (Content)
        |  2.05 |       |           Token: 0x83
        |       |       |         Observe: 8 B
        | 64 B       |   15 B       |    92 B Object-Security: -
        |       |       |         Payload: [Partial IV:36,
        |       |       |                  {Code:2.05,
        |       |       |                   Content-Format:0, "180"}]
        |       |       |
    +----------------------+-----+-----+------+---------+------------+

      Figure 12: Message overhead for 10: Secure Subscribe to Sensor.  Square brackets [ ... ]
    indicate a 5-byte Tid using AES-CCM
                         countersigned with ECDSA. COSE object.  Curly brackets { ... } indicate encrypted
                                   data.

   The request/response Codes are encrypted by OSCORE and only dummy
   Codes (FETCH/Content) are visible in the header of the OSCORE
   message.  The options Content-Format (0) and the payload ("220" and
   "180"), are encrypted.

   The COSE header of the request contains an identifier (ca),
   indicating the security context used to protect the message and a
   Partial IV (15).  The COSE headers of the responses contains Partial
   IVs (32 and 36).

   The server verifies that the Partial IV has not been received before.
   The client verifies that the responses are bound to the request and
   that the Partial IVs are greater than any Partial IV previously
   received in a response bound to the request.

Authors' Addresses

   Goeran Selander
   Ericsson AB

   Email: goran.selander@ericsson.com

   John Mattsson
   Ericsson AB

   Email: john.mattsson@ericsson.com

   Francesca Palombini
   Ericsson AB

   Email: francesca.palombini@ericsson.com
   Ludwig Seitz
   SICS Swedish ICT

   Email: ludwig@sics.se