Subject: [secdir] Secdir last call review of draft-ietf-core-object-security-14

From: Daniel Migault <[email-masked]>
Date: Mon, 30 Jul 2018 15:10:47 -0700

Reviewer: Daniel Migault
Review result: Has Issues

Hi,

Reviewer: Daniel Migault
Review result: Has Issues

I have reviewed this document as part of the security directorate's  ongoing
effort to review all IETF documents being processed by the IESG.  These
comments were written primarily for the benefit of the security area directors.
 Document editors and WG chairs should treat  these comments just like any
other last call comments.

The summary of the review is Has (small) Issues.

I am not an expert in CoAP. The document is well written, and I believe
securing objects is important. I had comments regarding the description of
security contexts. I hesitated between Nits and Issues. I do not believe these
are major design issues, and some clarifications may be sufficient. Other
comments are mostly editorial nits. Please find above my comments. I am happy
to follow up the updates.

     Object Security for Constrained RESTful Environments (OSCORE)
                   draft-ietf-core-object-security-14

1.  Introduction

   The Constrained Application Protocol (CoAP) [RFC7252] is a web
   transfer protocol, designed for constrained nodes and networks
   [RFC7228], and may be mapped from HTTP [RFC8075].  CoAP specifies the
   use of proxies for scalability and efficiency and references DTLS
   [RFC6347] for security.  CoAP-to-CoAP, HTTP-to-CoAP, and CoAP-to-HTTP
   proxies require DTLS or TLS [RFC5246] 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 message payload and
   metadata in transit between the endpoints.  The proxy can also
   inject, delete, or reorder packets since they are no longer protected
   by (D)TLS.
<mglt>
The proxy can almost do whatever it wants as mentioned in the second sentence.
Accessing the data enables it to passively monitor the communication.  I would
thus propose some text around these lines:

OLD:
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 message payload and
   metadata in transit between the endpoints.  The proxy can also
   inject, delete, or reorder packets since they are no longer protected
   by (D)TLS.

NEW:
The proxy therefore has access to the data required for
   performing the intended proxy functionality, and so can passively monitor
   the communications. In addition, the proxy can also inject, delete, or
   reorder packets since they are no longer protected by (D)TLS.
</mglt>

   This document defines the Object Security for Constrained RESTful
   Environments (OSCORE) security protocol, protecting CoAP and CoAP-
   mappable HTTP requests and responses end-to-end across intermediary
   nodes such as CoAP forward proxies and cross-protocol translators
   including HTTP-to-CoAP proxies [RFC8075].  In addition to the core
   CoAP features defined in [RFC7252], OSCORE supports Observe
   [RFC7641], Block-wise [RFC7959], No-Response [RFC7967], and PATCH and
   FETCH [RFC8132].
<mglt>
Maybe too many "and".
</mglt>

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].  OSCORE essentially protects the
   RESTful interactions; the request method, the requested resource, the
   message payload, etc. (see Section 4).  OSCORE protects neither the
   CoAP Messaging Layer nor the CoAP Token which may change between the
   endpoints, and those are therefore processed as defined in [RFC7252].
   Additionally, since the message formats for CoAP over unreliable
   transport [RFC7252] and for CoAP over reliable transport [RFC8323]
   differ only in terms of CoAP Messaging Layer, OSCORE can be applied
   to both unreliable and reliable transports (see Figure 1).

Selander, et al.        Expires January 27, 2019                [Page 4]

Internet-Draft                   OSCORE                        July 2018

               +-----------------------------------+
               |            Application            |
               +-----------------------------------+
               +-----------------------------------+  \
               |  Requests / Responses / Signaling |  |
               |-----------------------------------|  |
               |               OSCORE              |  | CoAP
               |-----------------------------------|  |
               | Messaging Layer / Message Framing |  |
               +-----------------------------------+  /
               +-----------------------------------+
               |          UDP / TCP / ...          |
               +-----------------------------------+

              Figure 1: Abstract Layering of CoAP with OSCORE

   OSCORE works in very constrained nodes and networks, thanks to its
   small message size and the restricted code and memory requirements in
   addition to what is required by CoAP.  Examples of the use of OSCORE
   are given in Appendix A.  OSCORE does not depend on underlying
   layers, and can be used with non-IP transports (e.g.,
   [I-D.bormann-6lo-coap-802-15-ie]).  OSCORE may also be used in
   different ways with HTTP.  OSCORE messages may be transported in
   HTTP, and OSCORE may also be used to protect CoAP-mappable HTTP
   messages, as described below.

<mglt>
I believe that "underlying layers" should be specified. My understanding is
that OSCORE requires CoAP or HTTP. If that is correct, I believe that should be
clarified in the paragraph above. </mglt>

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

   OSCORE uses pre-shared keys which may have been established out-of-
   band or with a key establishment protocol (see Section 3.2).  The
   technical solution builds on CBOR Object Signing and Encryption
   (COSE) [RFC8152], providing end-to-end encryption, integrity, replay
   protection, and binding of response to request.  A compressed version
   of COSE is used, as specified in Section 6.  The use of OSCORE is
   signaled in CoAP with a new option (Section 2), and in HTTP with a
   new header field (Section 11.1) and content type (Section 13.5).  The
   solution transforms a CoAP/HTTP message into an "OSCORE message"
   before sending, and vice versa after receiving.  The OSCORE message

Selander, et al.        Expires January 27, 2019                [Page 5]

Internet-Draft                   OSCORE                        July 2018

   is a CoAP/HTTP message related to the original message in the
   following way: the original CoAP/HTTP message is translated to CoAP
   (if not already in CoAP) and protected in a COSE object.  The
   encrypted message fields of this COSE object are transported in the
   CoAP payload/HTTP body of the OSCORE message, and the OSCORE option/
   header field is included in the message.  A sketch of an exchange of
   OSCORE messages, in the case of the original message being CoAP, is
   provided in Figure 2.

          Client                                          Server
             |      OSCORE request - POST example.com:      |
             |        Header, Token,                        |
             |        Options: {OSCORE, ...},               |
             |        Payload: COSE ciphertext              |
             +--------------------------------------------->|
             |                                              |
             |<---------------------------------------------+
             |      OSCORE response - 2.04 (Changed):       |
             |        Header, Token,                        |
             |        Options: {OSCORE, ...},               |
             |        Payload: COSE ciphertext              |
             |                                              |

                   Figure 2: Sketch of CoAP with OSCORE

<mglt>
Options are mentioned in {}. How these "{}" should be interpreted may be
specified in the figure.

The paragraph above mentions that OSCORE can be used both with CoAP or HTTP. It
might be helpful to split Figure 2 in to two sub figures Figure 2a) that
illustrates the use of OCSORE with CoAP and figure 2b) that illustrates the use
of OSCORE with HTTP.

My understanding is that CoAP and HTTP can easily be translated. As such it
might also be able to consider OSCORE only with CoAP and having a specific
section that deals with HTTP. Such split may avoid to deal in parallel with
HTTP and CoAP. </mglt>

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

1.1.  Terminology

2.  The OSCORE Option

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

<mglt>
I believe it would be clearer to specify that this section defines the OSCORE
option which is a new CoAP option.  Similarly Table 4 may also be designated by
CoAP Options or something similar. </mglt>

   +------+---+---+---+---+----------------+--------+--------+---------+
   | No.  | C | U | N | R | Name           | Format | Length | Default |
   +------+---+---+---+---+----------------+--------+--------+---------+
   | TBD1 | x |   |   |   | OSCORE         |  (*)   | 0-255  | (none)  |
   +------+---+---+---+---+----------------+--------+--------+---------+
       C = Critical,   U = Unsafe,   N = NoCacheKey,   R = Repeatable
       (*) See below.

                        Figure 3: The OSCORE Option

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

<mglt>
I believe the logic for the OSCORE option is the other way around, that is: an
CoAP message with an OSCORE option with an empty CoAP payload MUST be rejected
as malformed and reject it. </mglt>

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

   For CoAP proxy operations, see Section 10.

3.  The Security Context

   OSCORE requires that client and server establish a shared security
   context used to process the COSE objects.  OSCORE uses COSE with an
   Authenticated Encryption with Additional Data (AEAD, [RFC5116])
   algorithm for protecting message data between a client and a server.
   In this section, we define the security context and how it is derived

Selander, et al.        Expires January 27, 2019                [Page 7]

Internet-Draft                   OSCORE                        July 2018

   in client and server based on a shared 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 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.

<mglt>
I believe it might be clarifying to specify that CoAP endpoints have always
bidirectional communications. If that is correct, then for each communication
each end point is both a "Sender" and a "Recipient" for its respective outbound
and inbound traffic. The 4 context are derived from a Common Context.

As security context are established to secure unidirectional communications,
maybe that would be easier to base the description on the unidirectional
communications rather than the end points. </mglt>

   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, the two
   security contexts identified by the same IDs in the two endpoints are
   not the same, but they are partly mirrored.  Retrieval and use of the
   security context are shown in Figure 4.

<mglt>
"An endpoint uses its Sender ID (SID) to derive its Sender Context,"

I see the ID as mostly useful to the recipient in order to retrieve the
appropriated security context and decrypt the message. In other words, the
sender should know who it sends the message to and does not really need the SID
to match the security context.

I believe this should be clarified as the current text prevents Sender ID
collision, while collision should only be avoided on the receiver's side.
</mglt>

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

            Figure 4: Retrieval and Use of the Security Context

<mglt>
I might be helpful to clarify that Sender Context on both sides are not the
same context.

Security Context seems to be missing in the box.

It would also help to have in the figure, the relation between the Common
Security Context, the Sender Context and Recipient Context on both sides.
</mglt>

Selander, et al.        Expires January 27, 2019                [Page 8]

Internet-Draft                   OSCORE                        July 2018

   The Common Context contains the following parameters:

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

   o  Key Derivation Function.  The HMAC based HKDF [RFC5869] used to
      derive Sender Key, Recipient Key, and Common IV.
<mglt>
This is confusing to have a generic term such as KDF defined by a sup set of it
(HKDF). I believe that either the KDF is defined generic enough and later the
default value is set to HKDF with a specific hash function. Another alternative
could be to limited the scope of this parameter to HKDF Hash Function. </mglt>

   o  Master Secret.  Variable length, random byte string (see
      Section 12.3) used to derive traffic keys and IVs.
<mglt>
I believe that IVs is the Common IV.
</mglt>
   o  Master Salt.  Optional variable length byte string containing the
      salt used to derive traffic keys and IVs.
<mglt>
I believe that IVs is the Common IV.
</mglt>

   o  ID Context.  Optional variable length byte string providing
      additional information to identify the Common Context and to
      derive traffic keys and IVs.

   o  Common IV.  Byte string derived from Master Secret, Master Salt,
      and ID Context.  Length is determined by the AEAD Algorithm.
<mglt>
RFC8152 uses context IV. It is not clear to me how these two differ. I believe
some text should be added to explain how Common IV differs from the context IV.

It is unclear to me whether the Common Context is used for the two
bidirectional communications. If that is the case, I am reading that Common IV
and Sequence Number in the two directions will end up in IV collision. So Keys
needs to be unidirectional and different. </mglt>

   The Sender Context contains the following parameters:

   o  Sender ID.  Byte string used to identify the Sender Context, to
      derive traffic keys and IVs, and to assure unique nonces.  Maximum
      length is determined by the AEAD Algorithm.

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

   o  Sender Sequence Number.  Non-negative integer used by the sender
      to protect requests and certain responses, e.g.  Observe
      notifications.  Used as '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.  Byte string used to identify the Recipient Context,
      to derive traffic keys and IVs, and to assure unique nonces.
      Maximum length is determined by the AEAD Algorithm.

   o  Recipient Key. Byte string containing the symmetric key to verify
      messages received.  Derived from Common Context and Recipient ID.
      Length is determined by the AEAD Algorithm.

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

<mglt>
Looking at the different contexts, maybe some text should be added to specify
that Sender ID and Recipient ID are equal for a given unidirectional
communication. The same occurs for Sender Key and Recipient Key.

I believe that Sender Sequence Number also needs to be present in the Recipient
Context in order to implement anti replay mechanism.

Sequence Number May be interpreted differently. I believe that interpretation
should also be part of the Common Security Context.

As mentioned above the contexts may probably be refactored with one Context per
unidirectional communication. </mglt>

Selander, et al.        Expires January 27, 2019                [Page 9]

Internet-Draft                   OSCORE                        July 2018

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

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

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

<mglt>
I believe that Sender ID and Recipient ID could be the same value for a given
unidirectional communication. I believe that what is required her is the two
IDs used by the sessions. </mglt>

   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

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

   o  Master Salt

      *  Default is the empty byte string
<mglt>
I believe explicitly providing the string could help. There is always the
confusion with "\0" versus "". </mglt>

   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]
<mglt>
This section specifies Type and windows for the anti replay mechanism. This was
described as Replay Windows in the context description. </mglt>

Selander, et al.        Expires January 27, 2019               [Page 10]

Internet-Draft                   OSCORE                        July 2018

   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 way the input parameters are pre-established, is
   application specific.  Considerations of security context
   establishment are given in Section 12.2 and examples of deploying
   OSCORE in Appendix B.

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

   The KDF MUST be one of the HMAC based HKDF [RFC5869] algorithms
   defined for COSE [RFC8152].
<mglt>
It might be better to consider HKDF instead of KDF and then just specify the
Hash function </mglt>

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

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

   where:

   o  salt is the Master Salt as defined above

   o  IKM is the Master Secret as defined above

   o  info is the serialization of a CBOR array consisting of:

      info = [
          id : bstr,
          id_context : bstr / nil,
          alg_aead : int / tstr,
          type : tstr,
          L : uint
      ]
<mglt>
bstr, nil, tstr are used for the first time here. Maybe a reference to 8152 may
be clarifying. </mglt>

   where:

   o  id is the Sender ID or Recipient ID when deriving keys and the
      empty byte string when deriving the Common IV.  The encoding is
      described in Section 5.

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

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

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

Selander, et al.        Expires January 27, 2019               [Page 11]

Internet-Draft                   OSCORE                        July 2018

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

   For example, if the algorithm AES-CCM-16-64-128 (see Section 10.2 in
   [RFC8152]) is used, the integer value for alg_aead is 10, the value
   for L is 16 for keys and 13 for the Common IV.

   Note that [RFC5869] specifies that if the salt is not provided, it is
   set to a string of zeros.  For implementation purposes, not providing
   the salt is the same as setting the salt to the empty byte string.
   OSCORE sets the salt default value to empty byte string, which in
   [RFC5869] is converted to a string of zeroes (see Section 2.2 of
   [RFC5869]).

<mglt>
I believe that how Sender Key, Recipient Key, and Common IV are derived from
the output_parameters should be described as well.

Note that in this case I believe that Sender Key and Recipient Key are used for
the two unidirectional communications. In other words, the same key should be
used by the sender and the recipient of the same communication. The same Common
IV is used in both communications. </mglt> 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 how OSCORE is transported, see Section 7.4.  The
   default is DTLS-type replay protection with a window size of 32
   initiated as described in Section 4.1.2.6 of [RFC6347].

<mglt>
This should be specified the same in the Context.
</mglt>

3.3.  Requirements on the Security Context Parameters

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

<mglt>
I understand the use of SHALL and MUST as similar. If that is correct, It may
be better to use the same term throughout the document.

I believe that we would like to avoid that the same IV is being reused with the
same key. Any change in the inputs of the HMAC based KDF will result in a
different output. As such any change in the output will result in that
property. I suspect we would like to some parameters to remain wit the same
value, while some could be changed, and for that reason, we chose the Sender
ID. I believe the text could be clarified either on the reasoning behind or how
this should be operated. </mglt>

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

<mglt>
I suspect those restriction coming from the COSE specification. If that is
correct, I believe it would be helpful to have a reference to that document.
</mglt>

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

<mglt>
Such collision could represent an attack where the attacker could in case a
collision is observed craft a packet that costs two time more computation than
a regular packet.

I might be wrong, but it seems that the ID is more important for the recipient.
Typically the sender can easily address Sender ID collision.   On the other
hand the cryptographic properties are based on the uniqueness of the Sender ID.
Maybe these could be considered with the Recipient ID in mind. </mglt>

Selander, et al.        Expires January 27, 2019               [Page 12]

Internet-Draft                   OSCORE                        July 2018

   The ID Context is used to distinguish between security contexts.  The
   methods used for assigning Sender ID can also be used for assigning
   the ID Context.  Additionally, the ID Context can be generated by the
   client (see Appendix B.2).  ID Context can be arbitrarily long.

4.  Protected Message Fields

4.1.  CoAP Options

4.1.1.  Inner Options
4.1.2.  Outer Options
4.1.3.  Special Options
4.1.3.1.  Max-Age
4.1.3.2.  Uri-Host and Uri-Port
4.1.3.3.  Proxy-Uri
4.1.3.4.  The Block Options
4.1.3.4.1.  Inner Block Options
4.1.3.4.2.  Outer Block Options
4.1.3.5.  Observe
4.1.3.5.1.  Registrations and Cancellations
4.1.3.5.2.  Notifications

   If the server accepts an Observe registration, a Partial IV MUST be
   included in all notifications (both successful and error), except for
   the first one where Partial IV MAY be omitted.  To protect against
   replay, the client SHALL maintain a Notification Number for each
   Observation it registers.  The Notification Number is a non-negative
   integer containing the largest Partial IV of the received
   notifications for the associated Observe registration.  Further
   details of replay protection of notifications are specified in
   Section 7.4.1.

   For notifications, the Inner Observe value MUST be empty (see
   Section 3.2 of [RFC7252]).  The Outer Observe in a notification is

Selander, et al.        Expires January 27, 2019               [Page 20]

Internet-Draft                   OSCORE                        July 2018

   needed for intermediary nodes to allow multiple responses to one
   request, and may be set to the value of Observe in the original CoAP
   message.  The client performs ordering of notifications and replay
   protection by comparing their Partial IVs and SHALL ignore the outer
   Observe value.

   If the client receives a response to an Observe request without an
   Inner Observe option, then it verifies the response as a non-Observe
   response, as specified in Section 8.4.  If the client receives a
   response to a non-Observe request with an Inner Observe option, then
   it stops processing the message, as specified in Section 8.4.

   A client MUST consider the notification with the highest Partial IV
   as the freshest, regardless of the order of arrival.  In order to
   support existing Observe implementations the OSCORE client
   implementation MAY set the Observe value to the three least
   significant bytes of the Partial IV; such an implementation needs to
   make sure that the Observe value for an observe notification without
   Partial IV is smaller than a notification with Partial IV.

<mglt>
This section discuss the behavior regarding the sequence number. While the
sequence number and the partial IV have the same value, I am wondering if it
would not be more appropriated to mention the sequence number value is provided
by the partial IV, and then use the sequence number variable to describe anti
replay. </mglt>

4.1.3.6.  No-Response
4.1.3.7.  OSCORE
4.2.  CoAP Header Fields and Payload
4.3.  Signaling Messages
5.  The COSE Object
5.1.  Kid Context
5.2.  Nonce
5.3.  Plaintext
5.4.  Additional Authenticated Data
6.  OSCORE Header Compression
6.1.  Encoding of the OSCORE Option Value
6.2.  Encoding of the OSCORE Payload
6.3.  Examples of Compressed COSE Objects
7.2.  Sequence Numbers
7.2.1.  Maximum Sequence Number
7.3.  Freshness
7.4.  Replay Protection

   In order to protect from replay of requests, the server's Recipient
   Context includes a Replay Window.  A server SHALL verify that a
   Partial IV received in the COSE object has not been received before.
   If this verification fails the server SHALL stop processing the
   message, and MAY optionally respond with a 4.01 Unauthorized error
   message.  Also, the server MAY set an Outer Max-Age option with value
   zero, to inform any intermediary that the response is not to be
   cached.  The diagnostic payload MAY contain the "Replay detected"
   string.  The size and type of the Replay Window depends on the use
   case and the protocol with which the OSCORE message is transported.
   In case of reliable and ordered transport from endpoint to endpoint,
   e.g.  TCP, the server MAY just store the last received Partial IV and
   require that newly received Partial IVs equals the last received
   Partial IV + 1.  However, in case of mixed reliable and unreliable
   transports and where messages may be lost, such a replay mechanism

Selander, et al.        Expires January 27, 2019               [Page 33]

Internet-Draft                   OSCORE                        July 2018

   may be too restrictive and the default replay window be more suitable
   (see Section 3.2.2).
<mglt>
I am reading the anti replay mechanism used as very specific. Incrementing
Partial IV is one way to perform anti-replay protection. It could be the way
OSCORE performs anti replay protection but this is not the only way to do. In
addition, incrementing the Partial IV result in the IV being predictible. This
condition may not be sufficient as some algorithm may require the IV being
unpredictable. I believe Anti-Replay Type shoudl be configurable, and some note
shoudl be added to comply with the encryption being used. </mglt>

   Responses (with or without Partial IV) are protected against replay
   as they are bound to the request and the fact that only a single
   response is accepted.  Note that the Partial IV is not used for
   replay protection in this case.

   The operation of validating the Partial IV and updating the replay
   protection MUST be atomic.

7.4.1.  Replay Protection of Notifications
7.5.  Losing Part of the Context State

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

   After boot, an endpoint can either use a persistently stored complete
   or partial security context, or establish a new security context with
   each endpoint it communicates with.  However, establishing a fresh
   security context may have a non-negligible cost in terms of, e.g.,
   power consumption.

   If the endpoint uses a persistently stored partial security context,
   it MUST NOT reuse a previous Sender Sequence Number and MUST NOT

Selander, et al.        Expires January 27, 2019               [Page 34]

Internet-Draft                   OSCORE                        July 2018

   accept previously received messages.  Some ways to achieve this are
   described in the following sections.

7.5.1.  Sequence Number

   To prevent reuse of Sender Sequence Numbers, an endpoint may perform
   the following procedure during normal operations:

   o  Before using a Sender Sequence Number that is evenly divisible by
      K, where K is a positive integer, store the Sender Sequence Number
      in persistent memory.  After boot, the endpoint initiates the
      Sender Sequence Number to the value stored in persistent memory +
      K.  Storing to persistent memory can be costly.  The value K gives
      a trade-off between the number of storage operations and efficient
      use of Sender Sequence Numbers.

<mglt>
I have hard time reading the section above. I guess K is a parameter known by
OSCORE. My understanding is that SSN=0 ... K-1 are stored in persistent memory.
After boot SSN = SSN + K.

I might be wrong but as storage in persistent memory is costly. Given K a
parameter defined by the implementation. I would rather store F = floor(SSN / K
). SSN = F.K + ssn with ssn = 0... K-1, so a storage operation happens every K.
In case of reboot, SSN = (F + 1).K + ssn.

This ends in a jump of maximum K and anti replay must be able to handle this.
</mglt>

7.5.2.  Replay Window
7.5.3.  Replay of Notifications
8.  Processing

   This section describes the OSCORE message processing.  Additional
   processing for Observe or Block-wise are described in subsections.

   Note that, analogously to [RFC7252] where the Token and source/
   destination pair are used to match a response with a request, both
   endpoints MUST keep the association (Token, {Security Context,

Selander, et al.        Expires January 27, 2019               [Page 35]

Internet-Draft                   OSCORE                        July 2018

   Partial IV of the request}), in order to be able to find the Security
   Context and compute the AAD to protect or verify the response.  The
   association MAY be forgotten after it has been used to successfully
   protect or verify the response, with the exception of Observe
   processing, where the association MUST be kept as long as the
   Observation is active.

8.1.  Protecting the Request

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

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

   2.  Compose the Additional Authenticated Data and the plaintext, as
       described in Sections 5.3 and 5.4.

   3.  Encode the Partial IV (Sender Sequence Number in network byte
       order) and increment the Sender Sequence Number by one.
<mglt>
I believe this depends on the Anti-replay type.
</mglt>
  Compute
       the AEAD nonce from the Sender ID, Common IV, and Partial IV as
       described in Section 5.2.

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

   5.  Format the OSCORE message according to Section 4.  The OSCORE
       option is added (see Section 4.1.2).

8.2.  Verifying the Request

   A server receiving a request containing the OSCORE option SHALL
   perform the following steps:

   1.  Discard Code and all class E options (marked in Figure 5 with 'x'
       in column E) present in the received message.  For example, an
       If-Match Outer option is discarded, but an Uri-Host Outer option
       is not discarded.

   2.  Decompress the COSE Object (Section 6) and retrieve the Recipient
       Context associated with the Recipient ID in the 'kid' parameter,
       additionally using the 'kid context', if present.  If 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 either the decompression or the COSE message fails to
          decode, the server MAY respond with a 4.02 Bad Option error

Selander, et al.        Expires January 27, 2019               [Page 36]

Internet-Draft                   OSCORE                        July 2018

          message.  The server MAY set an Outer Max-Age option with
          value zero.  The diagnostic payload SHOULD contain the string
          "Failed to decode COSE".

       *  If the server fails to retrieve a Recipient Context with
          Recipient ID corresponding to the 'kid' parameter received,
          the server MAY respond with a 4.01 Unauthorized error message.
          The server MAY set an Outer Max-Age option with value zero.
          The diagnostic payload SHOULD contain the string "Security
          context not found".

   3.  Verify the 'Partial IV' parameter using the Replay Window, as
       described in Section 7.4.
<mglt>
My understanding is that the Partial IV value has not been authenticated. Thus
I believe this step mostly consists in discarding packets with irrelevant
Partial IV values. Here irrelevant are limited to repeated sequence numbers
that is too say known replayed packets. <mglt>

   4.  Compose the Additional Authenticated Data, as described in
       Section 5.4.

   5.  Compute the AEAD nonce from the Recipient ID, Common IV, and the
       'Partial IV' parameter, received in the COSE Object.

   6.  Decrypt the COSE object using the Recipient Key, as per [RFC8152]
       Section 5.3.  (The decrypt operation includes the verification of
       the integrity.)

       *  If decryption fails, the server MUST stop processing the
          request and MAY respond with a 4.00 Bad Request error message.
          The server MAY set an Outer Max-Age option with value zero.
          The diagnostic payload MAY contain the "Decryption failed"
          string.

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

   7.  Add decrypted Code, options, and payload to the decrypted
       request.  The OSCORE option is removed.

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

8.2.1.  Supporting Block-wise
8.3.  Protecting the Response

   If a CoAP response is generated in response to an OSCORE request, the
   server SHALL perform the following steps to create an OSCORE
   response.  Note that CoAP error responses derived from CoAP
   processing (step 8 in Section 8.2) are protected, as well as
   successful CoAP responses, while the OSCORE errors (steps 2, 3, and 6
   in Section 8.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 associated
       with the Token.

   2.  Compose the Additional Authenticated Data and the plaintext, as
       described in Sections 5.3 and 5.4.

   3.  Compute the AEAD nonce as described in Section 5.2:

       *  Either use the nonce from the request, or

       *  Encode the Partial IV (Sender Sequence Number in network byte
          order) and increment the Sender Sequence Number by one.
<mglt>
Again this is very specific.

I am reading that SSN is incremented after the Partial IV is generated. It
seems to me that the Partial IV should reflect the SSN, and as such being
encoded after the incrementation of the SSN. </mglt>
          Compute the AEAD nonce from the Sender ID, Common IV, and
          Partial IV.

   4.  Encrypt the COSE object using the Sender Key. Compress the COSE
       Object as specified in Section 6.  If the AEAD nonce was
       constructed from a new Partial IV, this Partial IV MUST be
       included in the message.  If the AEAD nonce from the request was
       used, the Partial IV MUST NOT be included in the message.

   5.  Format the OSCORE message according to Section 4.  The OSCORE
       option is added (see Section 4.1.2).

8.3.1.  Supporting Observe
8.4.  Verifying the Response
9.  Web Linking
10.  CoAP-to-CoAP Forwarding Proxy
11.  HTTP Operations
11.2.  CoAP-to-HTTP Mapping
11.3.  HTTP-to-CoAP Mapping
11.4.  HTTP Endpoints
11.5.  Example: HTTP Client and CoAP Server
11.6.  Example: CoAP Client and HTTP Server
12.  Security Considerations

   An overview of the security properties is given in Appendix D.

12.1.  End-to-end Protection

   In scenarios with intermediary nodes such as proxies or gateways,
   transport layer security such as (D)TLS only protects data hop-by-
   hop.  As a consequence, the intermediary nodes can read and modify
   any information.  The trust model where all intermediary nodes are
   considered trustworthy is problematic, not only from a privacy
   perspective, but 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 the rare cases where all the owners of the
   intermediary nodes are fully trusted, attacks and data breaches make
   such an architecture brittle.

   (D)TLS protects hop-by-hop the entire message.  OSCORE protects end-
   to-end all information that is not required for proxy operations (see
   Section 4).  (D)TLS and OSCORE can be combined, thereby enabling end-
   to-end security of the message payload, in combination with hop-by-
   hop protection of the entire message, during transport between end-
   point and intermediary node.  In particular when OSCORE is used with

Selander, et al.        Expires January 27, 2019               [Page 47]

Internet-Draft                   OSCORE                        July 2018

   HTTP, the additional TLS protection of HTTP hops is recommended, e.g.
   between an HTTP endpoint and a proxy translating between HTTP and
   CoAP.

<mglt>
I see that (D)TLS provides privacy to OSCORE communication, while OSCORE
protects the data. </mglt>

   Applications need to consider that certain message fields and
   messages types are not protected end-to-end and may be spoofed or
   manipulated.  The consequences of unprotected message fields are
   analyzed in Appendix D.4.

12.2.  Security Context Establishment

<mglt>
Wouldn't agreement preferred to established ?
</mglt>

   The use of COSE_Encrypt0 and AEAD to protect messages as specified in
   this document requires an established security context.  The method
   to establish the security context described in Section 3.2 is based
   on a common Master Secret and unique Sender IDs.  The necessary input
   parameters may be pre-established or obtained using a key
   establishment protocol augmented with establishment of Sender/
   Recipient ID such as the OSCORE profile of the ACE framework
   [I-D.ietf-ace-oscore-profile].  Such a procedure must ensure that the
   requirements of the security context parameters for the intended use
   are complied with (see Section 3.3) and also in error situations.  It
   is recommended to use a key establishment protocol which provides
   forward secrecy whenever possible.  Considerations for deploying
   OSCORE with a fixed Master Secret are given in Appendix B.

12.3.  Master Secret

   OSCORE uses HKDF [RFC5869] and the established input parameters to
   derive the security context.  The required properties of the security
   context parameters are discussed in Section 3.3, in this section we
   focus on the Master Secret.  HKDF denotes in this specification the
   composition of the expand and extract functions as defined in
   [RFC5869] and the Master Secret is used as Input Key Material (IKM).

   Informally, HKDF takes as source an IKM containing some good amount
   of randomness but not necessarily distributed uniformly (or for which
   an attacker has some partial knowledge) and derive from it one or
   more cryptographically strong secret keys [RFC5869].
<mglt>
rfc4086 may be a usefull reference.
</mglt>

   Therefore, the main requirement for the OSCORE Master Secret, in
   addition to being secret, is that it is has a good amount of
   randomness.  The selected key establishment schemes must ensure that
   the necessary properties for the Master Secret are fulfilled.  For
   pre-shared key deployments and key transport solutions such as
   [I-D.ietf-ace-oscore-profile], the Master Secret can be generated
   offline using a good random number generator.

Selander, et al.        Expires January 27, 2019               [Page 48]

Internet-Draft                   OSCORE                        July 2018

12.4.  Replay Protection

   Replay attacks need to be considered in different parts of the
   implementation.  Most AEAD algorithms require a unique nonce for each
   message, for which the sender sequence numbers in the COSE message
   field 'Partial IV' is used.  If the recipient accepts any sequence
   number larger than the one previously received, then the problem of
   sequence number synchronization is avoided.
<mglt>
Do we have cases where the Partial IV represents the LSB of the SSN ? If that
is the case, if more then len(Partial IV) packet have been dropped. The two
peers may have hard time to resynchronize their SSN. This may happen in a
communication with a lot of notifications. In a query-response paradigm, the
sender may have some hints when the packet has been receieved or not. </mglt>

With reliable transport,
   it may be defined that only messages with sequence number which are
   equal to previous sequence number + 1 are accepted.  An adversary may
   try to induce a device reboot for the purpose of replaying a message
   (see Section 7.5).

   Note that sharing a security context between servers may open up for
   replay attacks, for example if the replay windows are not
   synchronized.

12.5.  Client Aliveness

   A verified OSCORE request enables the server to verify the identity
   of the entity who generated the message.  However, it does not verify
   that the client is currently involved in the communication, since the
   message may be a delayed delivery of a previously generated request
   which now reaches the server.  To verify the aliveness of the client
   the server may use the Echo option in the response to a request from
   the client (see [I-D.ietf-core-echo-request-tag]).

12.6.  Cryptographic Considerations

   The maximum sender sequence number is dependent on the AEAD
   algorithm.  The maximum sender sequence number is 2^40 - 1, or any
   algorithm specific lower limit, after which a new security context
   must be generated.  The mechanism to build the nonce (Section 5.2)
   assumes that the nonce is at least 56 bits, and the Partial IV is at
   most 40 bits.  The mandatory-to-implement AEAD algorithm AES-CCM-
   16-64-128 is selected for compatibility with CCM*.

   In order to prevent cryptanalysis when the same plaintext is
   repeatedly encrypted by many different users with distinct keys, the
   nonce is formed by mixing the sequence number with a secret per-
   context initialization vector (Common IV) derived along with the keys
   (see Section 3.1 of [RFC8152]), and by using a Master Salt in the key
   derivation (see [MF00] for an overview).  The Master Secret, Sender
   Key, Recipient Key, and Common IV must be secret, the rest of the
   parameters may be public.  The Master Secret must have a good amount
   of randomness (see Section 12.3).

Selander, et al.        Expires January 27, 2019               [Page 49]

Internet-Draft                   OSCORE                        July 2018

12.7.  Message Segmentation

   The Inner Block options enable the sender to split large messages
   into OSCORE-protected blocks such that the receiving endpoint 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 Inner Block 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.8.  Privacy Considerations

   Privacy threats executed through intermediary 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 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 5) may reveal privacy sensitive
   information, see Appendix D.4.  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.
   OSCORE does not provide protection for HTTP header fields which are
   not both CoAP-mappable and class E.  The HTTP message fields which
   are visible to on-path entity are only used for the purpose of
   transporting the OSCORE message, whereas the application layer
   message is encoded in CoAP and encrypted.

   COSE message fields, i.e. the OSCORE option, may reveal information
   about the communicating endpoints.  E.g. 'kid' and 'kid context',
   which are intended to help the server find the right context, may
   reveal information about the client.  Tracking 'kid' and 'kid
   context' to one server may be used for correlating requests from one
   client.

   Unprotected error messages reveal information about the security
   state in the communication between the endpoints.  Unprotected
   signaling messages reveal information about the reliable transport
   used on a leg of the path.  Using the mechanisms described in
   Section 7.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 replay window on a clean shutdown.

Selander, et al.        Expires January 27, 2019               [Page 50]

Internet-Draft                   OSCORE                        July 2018

   The length of message fields can reveal information about the
   message.  Applications may use a padding scheme to protect against
   traffic analysis.

13.  IANA Considerations
14.  References
Appendix A.  Scenario Examples
Appendix B.  Deployment Examples
B.1.  Master Secret Used Once

   An application may derive a security context once and use it for the
   lifetime of a device.  For many IoT deployments, a 128 bit uniformly
   random Master Key is sufficient for encrypting all data exchanged
   with the IoT device.  This specification describes techniques for
   persistent storage of the security context and synchronization of
   sequence numbers (see Section 7.5) to ensure that security is
   maintained with the existing security context.

B.2.  Master Secret Used Multiple Times

   Section 12.2 recommends the use of a key establishment protocol
   providing forward secrecy of the Master Secret.
<mglt>
I believe that forward secrecy is a property associated to the kex. I am
reading it as associated to the Master Secret. That said, English is not my
native language. </mglt>
   An application which does not require forward secrecy may allow
   multiple security contexts to be derived from one Master Secret.  The
   requirements on the security context parameters must be fulfilled
   (Section 3.3) even if the client or server is rebooted,
   recommissioned or in error cases.

   This section gives an example of an application allowing new security
   contexts to be derived from input parameters pre-established between
   client and server for this purpose: in particular Master Secret,
   Master Salt and Sender/Recipient ID (see Section 3.2):

   o  The client generates an ID Context which has previously not been
      used with the pre-established input parameters and derives a new
      security context.  ID context may be pseudo-random and large for

Selander, et al.        Expires January 27, 2019               [Page 62]

Internet-Draft                   OSCORE                        July 2018

      stochastic uniqueness, but care must be taken e.g. to avoid re-use
      of the same seed for random number generation.  Using this new
      security context, the client generates an OSCORE request with (kid
      context, kid) = (ID Context, Sender ID) in the OSCORE option.

   o  The server receiving such an OSCORE request with kid matching the
      Recipient ID of pre-established input parameters, but with a new
      kid context, derives the security context using ID Context = kid
      context.  If the message verifies then a new security context with
      this ID Context is stored in the server, and used in the response.
      Further requests with the same (kid context, kid) are verified
      with this security context.

   As an alternative procedure to reduce the subsequent overhead in
   requests due to kid context, the verification of a message with a new
   ID Context may trigger the server to generate a new kid to replace
   the Client Sender ID in future requests.  A client may e.g. indicate
   support for such a procedure by requesting a special well-known URI
   and receive the new kid in the response, which together with the
   input parameters and the ID context is used to derive the new
   security context which may be identified only by its kid.  The
   details are out of scope for this specification.

   The procedures may be complemented with the use of the Echo option
   for verifying the aliveness of the client requesting a new security
   context.

Appendix C.  Test Vectors
Appendix D.  Overview of Security Properties

D.1.  Supporting Proxy Operations

   CoAP is designed to work with intermediaries reading and/or changing
   CoAP message fields to perform supporting operations in constrained
   environments, e.g. forwarding and cross-protocol translations.

   Securing CoAP on transport layer protects the entire message between
   the endpoints in which case CoAP proxy operations are not possible.
   In order to enable proxy operations, security on transport layer
   needs to be terminated at the proxy in which case the CoAP message in
   its entirety is unprotected in the proxy.

   Requirements for CoAP end-to-end security are specified in
   [I-D.hartke-core-e2e-security-reqs].  The client and server are
   assumed to be honest, but proxies and gateways are only trusted to
   perform their intended operations.
<mglt>
I expected after 'but' something saying the proxies are not trusted, but t
seems that everyone is honest here. maybe we should replace: OLD but proxies
and gateways are only trusted to
   perform their intended operations.
NEW:
and proxies and gateways are trusted to
   perform their intended operations.

That the server is honest does not means that the node terminating the session
is the server.... </mglt>
  Forwarding is specified in
   Section 2.2.1 of [I-D.hartke-core-e2e-security-reqs].  HTTP-CoAP
   translation is specified in [RFC8075].  Intermediaries translating
   between different transport layers are intended to perform just that.

   By working at the CoAP layer, OSCORE enables different CoAP message
   fields to be protected differently, which allows message fields
   required for proxy operations to be available to the proxy while
   message fields intended for the other endpoint remain protected.  In
   the remainder of this section we analyze how OSCORE protects the
   protected message fields and the consequences of message fields
   intended for proxy operation being unprotected.
<mglt>
This text seems clear to me. Maybe the last paragraph could be sufficient.
</mglt>
D.2.  Protected Message Fields

   Protected message fields are included in the Plaintext (Section 5.3)
   and the Additional Authenticated Data (Section 5.4) of the
   COSE_Encrypt0 object and encrypted using an AEAD algorithm.

   OSCORE depends on a pre-established random Master Secret
   (Section 12.3) used to derive encryption keys, and a construction for
   making (key, nonce) pairs unique (Appendix D.3).  Assuming this is
   true, and the keys are used for no more data than indicated in
   Section 7.2.1, OSCORE should provide the following guarantees:

   o  Confidentiality: An attacker should not be able to determine the
      plaintext contents of a given OSCORE message or determine that
      different plaintexts are related (Section 5.3).

Selander, et al.        Expires January 27, 2019               [Page 74]

Internet-Draft                   OSCORE                        July 2018

   o  Integrity: An attacker should not be able to craft a new OSCORE
      message with protected message fields different from an existing
      OSCORE message which will be accepted by the receiver.

   o  Request-response binding: An attacker should not be able to make a
      client match a response to the wrong request.

   o  Non-replayability: An attacker should not be able to cause the
      receiver to accept a message which it has previously received and
      accepted.

   In the above, the attacker is anyone except the endpoints, e.g. a
   compromised intermediary.  Informally, OSCORE provides these
   properties by AEAD-protecting the plaintext with a strong key and
   uniqueness of (key, nonce) pairs.  AEAD encryption [RFC5116] provides
   confidentiality and integrity for the data.  Response-request binding
   is provided by including the kid and Partial IV of the request in the
   AAD of the response.  Non-replayability of requests and notifications
   is provided by using unique (key, nonce) pairs and a replay
   protection mechanism (application dependent, see Section 7.4).

   OSCORE is susceptible to a variety of traffic analysis attacks based
   on observing the length and timing of encrypted packets.  OSCORE does
   not provide any specific defenses against this form of attack but the
   application may use a padding mechanism to prevent an attacker from
   directly determine the length of the padding.  However, information
   about padding may still be revealed by side-channel attacks observing
   differences in timing.

D.3.  Uniqueness of (key, nonce)

   In this section we show that (key, nonce) pairs are unique as long as
   the requirements in Sections 3.3 and 7.2.1 are followed.

   Fix a Common Context (Section 3.1) and an endpoint, called the
   encrypting endpoint.  An endpoint may alternate between client and
   server roles, but each endpoint always encrypts with the Sender Key
   of its Sender Context.  Sender Keys are (stochastically) unique since
   they are derived with HKDF using unique Sender IDs, so messages
   encrypted by different endpoints use different keys.  It remains to
   prove that the nonces used by the fixed endpoint are unique.

   Since the Common IV is fixed, the nonces are determined by a Partial
   IV (PIV) and the Sender ID of the endpoint generating that Partial IV
   (ID_PIV).  The nonce construction (Section 5.2) with the size of the
   ID_PIV (S) creates unique nonces for different (ID_PIV, PIV) pairs.
   There are two cases:

Selander, et al.        Expires January 27, 2019               [Page 75]

Internet-Draft                   OSCORE                        July 2018

   A.  For requests, and responses with Partial IV (e.g.  Observe
   notifications):

   o  ID_PIV = Sender ID of the encrypting endpoint

   o  PIV = current Partial IV of the encrypting endpoint

   Since the encrypting endpoint steps the Partial IV for each use, the
   nonces used in case A are all unique as long as the number of
   encrypted messages is kept within the required range (Section 7.2.1).

   B.  For responses without Partial IV (e.g. single response to a
   request):

   o  ID_PIV = Sender ID of the endpoint generating the request

   o  PIV = Partial IV of the request

   Since the Sender IDs are unique, ID_PIV is different from the Sender
   ID of the encrypting endpoint.  Therefore, the nonces in case B are
   different compared to nonces in case A, where the encrypting endpoint
   generated the Partial IV.  Since the Partial IV of the request is
   verified for replay (Section 7.4) associated to this Recipient
   Context, PIV is unique for this ID_PIV, which makes all nonces in
   case B distinct.

D.4.  Unprotected Message Fields

   This section lists and discusses issues with unprotected message
   fields.

D.4.1.  CoAP Header Fields

   o  Version.  The CoAP version [RFC7252] is not expected to be
      sensitive to disclose.  Currently there is only one CoAP version
      defined.  A change of this parameter is potentially a denial-of-
      service attack.  Future versions of CoAP need to analyze attacks
      to OSCORE protected messages due to an adversary changing the CoAP
      version.

   o  Token/Token Length.  The Token field is a client-local identifier
      for differentiating between concurrent requests [RFC7252].  An
      eavesdropper reading the token can match requests to responses
      which can be used in traffic analysis.  In particular this is true
      for notifications, where multiple responses are matched with one
      request.  CoAP proxies are allowed to change Token and Token
      Length between UDP hops.  However, modifications of Token and
      Token Length during a UDP hop may become a denial-of-service

Selander, et al.        Expires January 27, 2019               [Page 76]

Internet-Draft                   OSCORE                        July 2018

      attack, since it may prevent the client to identify to which
      request the response belongs or to find the correct information to
      verify integrity of the response.
<mglt>
I am reading the text as. When the attacker is on-path, a long Token does not
prevents the attack based on a spoofed response. However, for an attacker that
is not on path, the attacker needs to guess the Token, and this can be
mitigated (partially) by increasing the Token size.  Note that in the latest
case, a long Token should not be seen as a replacement for cryptographic
protection of the message. </mglt>

   o  Code.  The Outer CoAP Code of an OSCORE message is POST or FETCH
      for requests with corresponding response codes.  The use of FETCH
      reveals no more than what is revealed by the Outer Observe option.
      Changing the Outer Code may be a denial-of-service attack by
      causing errors in the proxy processing.

   o  Type/Message ID.  The Type/Message ID fields [RFC7252] reveal
      information about the UDP transport binding, e.g. an eavesdropper
      reading the Type or Message ID gain information about how UDP
      messages are related to each other.  CoAP proxies are allowed to
      change Type and Message ID.  These message fields are not present
      in CoAP over TCP [RFC8323], and does not impact the request/
      response message.  A change of these fields in a UDP hop is a
      denial-of-service attack.  By sending an ACK, an attacker can make
      the endpoint believe that the other endpoint received the previous
      message.  By sending a RST, an attacker may be able to cancel an
      observation, make one endpoint believe the other endpoint is
      alive, or make one endpoint endpoint believe that the other
      endpoint is missing some context.  By changing a NON to a CON, the
      attacker can cause the receiving endpoint to respond to messages
      for which no response was requested.

   o  Length.  This field contain the length of the message [RFC8323]
      which may be used for traffic analysis.  These message fields are
      not present in CoAP over UDP, and does not impact the request/
      response message.  A change of Length is a denial-of-service
      attack similar to changing TCP header fields.

D.4.2.  CoAP Options

   o  Max-Age. The Outer Max-Age is set to zero to avoid unnecessary
      caching of OSCORE error responses.  Changing this value thus may
      cause unnecessary caching.  No additional information is carried
      with this option.

   o  Proxy-Uri/Proxy-Scheme.  These options are used in forward proxy
      deployments.  With OSCORE, the Proxy-Uri option does not contain
      the Uri-Path/Uri-Query parts of the URI.  The other parts of
      Proxy-Uri cannot be protected since they are allowed to be changed
      by a forward proxy.  The server can verify what scheme is used in
      the last hop, but not what was requested by the client or what was
      used in previous hops.

Selander, et al.        Expires January 27, 2019               [Page 77]

Internet-Draft                   OSCORE                        July 2018

   o  Uri-Host/Uri-Port.  In forward proxy deployments, the Uri-Host/
      Uri-Port may be changed by an adversary, and the application needs
      to handle the consequences of that (see Section 4.1.3.2).  The
      Uri-Host may either be omitted, reveal information equivalent to
      that of the IP address or more privacy-sensitive information,
      which is discouraged.

   o  Observe.  The Outer Observe option is intended for a proxy to
      support forwarding of Observe messages, but is ignored by the
      endpoints since the Inner Observe determines the processing in the
      endpoints.  Since the Partial IV provides absolute ordering of
      notifications it is not possible for an intermediary to spoof
      reordering (see Section 4.1.3.5).  The absence of Partial IV,
      since only allowed for the first notification, does not prevent
      correct ordering of notifications.  The size and distributions of
      notifications over time may reveal information about the content
      or nature of the notifications.  Cancellations (Section 4.1.3.5.1)
      are not bound to the corresponding registrations in the same way
      responses are bound to requests in OSCORE (see Appendix D.2), but
      that does not open up for attacks based on mismatched
      cancellations, since [RFC7641] specifies that for cancellations to
      be accepted, all options except for ETags MUST be the same (see
      Section 3.6 of [RFC7641]).  For different target resources, the
      OSCORE option is different, and even if the Token is modified to
      match a different observation, such a cancellation would not be
      accepted.

   o  Block1/Block2/Size1/Size2.  The Outer Block options enables
      fragmentation of OSCORE messages in addition to segmentation
      performed by the Inner Block options.  The presence of these
      options indicates a large message being sent and the message size
      can be estimated and used for traffic analysis.  Manipulating
      these options is a potential denial-of-service attack, e.g.
      injection of alleged Block fragments.  The specification of a
      maximum size of message, MAX_UNFRAGMENTED_SIZE
      (Section 4.1.3.4.2), above which messages will be dropped, is
      intended as one measure to mitigate this kind of attack.

   o  No-Response.  The Outer No-Response option is used to support
      proxy functionality, specifically to avoid error transmissions
      from proxies to clients, and to avoid bandwidth reduction to
      servers by proxies applying congestion control when not receiving
      responses.  Modifying or introducing this option is a potential
      denial-of-service attack against the proxy operations, but since
      the option has an Inner value its use can be securely agreed
      between the endpoints.  The presence of this option is not
      expected to reveal any sensitive information about the message
      exchange.

Selander, et al.        Expires January 27, 2019               [Page 78]

Internet-Draft                   OSCORE                        July 2018

   o  OSCORE.  The OSCORE option contains information about the
      compressed COSE header.  Changing this field may cause OSCORE
      verification to fail.

D.4.3.  Error and Signaling Messages

   Error messages occurring during CoAP processing are protected end-to-
   end.  Error messages occurring during OSCORE processing are not
   always possible to protect, e.g. if the receiving endpoint cannot
   locate the right security context.  For this setting, unprotected
   error messages are allowed as specified to prevent extensive
   retransmissions.  Those error messages can be spoofed or manipulated,
   which is a potential denial-of-service attack.

   Signaling messages used in CoAP over TCP [RFC8323] are intended to be
   hop-by-hop; spoofing signaling messages can be used as a denial-of-
   service attack of a TCP connection.

D.4.4.  HTTP Message Fields

   In contrast to CoAP, where OSCORE does not protect header fields to
   enable CoAP-CoAP proxy operations, the use of OSCORE with HTTP is
   restricted to transporting a protected CoAP message over an HTTP hop.
   Any unprotected HTTP message fields may reveal information about the
   transport of the OSCORE message and enable various denial-of-service
   attacks.  It is recommended to additionally use TLS [RFC5246] for
   HTTP hops, which enables encryption and integrity protection of
   headers, but still leaves some information for traffic analysis.

Appendix E.  CDDL Summary