Tech-invite3GPPspaceIETF RFCsSIP
in Index   Prev   Next

RFC 8613

Object Security for Constrained RESTful Environments (OSCORE)

Pages: 94
Proposed Standard
Updates:  7252
Part 6 of 6 – Pages 86 to 94
First   Prev   None

Top   ToC   RFC8613 - Page 86   prevText

Appendix D. Overview of Security Properties

D.1. Threat Model

This section describes the threat model using the terms of [RFC3552]. It is assumed that the endpoints running OSCORE have not themselves been compromised. The attacker is assumed to have control of the CoAP channel over which the endpoints communicate, including intermediary nodes. The attacker is capable of launching any passive or active on-path or off-path attacks; including eavesdropping, traffic analysis, spoofing, insertion, modification, deletion, delay, replay, man-in-the-middle, and denial-of-service attacks. This means that the attacker can read any CoAP message on the network and undetectably remove, change, or inject forged messages onto the wire. OSCORE targets the protection of the CoAP request/response layer (Section 2 of [RFC7252]) between the endpoints, including the CoAP Payload, Code, Uri-Path/Uri-Query, and the other Class E option instances (Section 4.1). OSCORE does not protect the CoAP messaging layer (Section 2 of [RFC7252]) or other lower layers involved in routing and transporting the CoAP requests and responses. Additionally, OSCORE does not protect Class U option instances (Section 4.1), as these are used to support CoAP forward proxy operations (see Section 5.7.2 of [RFC7252]). The supported proxies (forwarding, cross-protocol, e.g., CoAP to CoAP-mappable protocols such as HTTP) must be able to change certain Class U options (by instruction from the Client), resulting in the CoAP request being redirected to the server. Changes caused by the proxy may result in the request not reaching the server or reaching the wrong server. For cross-protocol proxies, mappings are done on the Outer part of
Top   ToC   RFC8613 - Page 87
   the message so these protocols are essentially used as transport.
   Manipulation of these options may thus impact whether the protected
   message reaches or does not reach the destination endpoint.

   Attacks on unprotected CoAP message fields generally causes denial-
   of-service attacks which are out of scope of this document, more
   details are given in Appendix D.5.

   Attacks against the CoAP request-response layer are in scope.  OSCORE
   is intended to protect against eavesdropping, spoofing, insertion,
   modification, deletion, replay, and man-in-the middle attacks.

   OSCORE is susceptible to traffic analysis as discussed later in
   Appendix D.

D.2. 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 the 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 the 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 [CoAP-E2E-Sec], in particular, forwarding is detailed in Section 2.2.1. The client and server are assumed to be honest, while proxies and gateways are only trusted to perform their intended operations. 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.

D.3. Protected Message Fields

Protected message fields are included in the plaintext (Section 5.3) and the AAD (Section 5.4) of the COSE_Encrypt0 object and encrypted using an AEAD algorithm.
Top   ToC   RFC8613 - Page 88
   OSCORE depends on a preestablished random Master Secret
   (Section 12.3) used to derive encryption keys, and a construction for
   making (key, nonce) pairs unique (Appendix D.4).  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).

   o  Integrity: An attacker should not be able to craft a new OSCORE
      message with protected message fields different from an existing
      OSCORE message that 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 that it has previously received and

   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 determining the length of the padding.  However,
   information about padding may still be revealed by side-channel
   attacks observing differences in timing.

D.4. 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
Top   ToC   RFC8613 - Page 89
   they are derived with HKDF using unique Sender IDs, so messages
   encrypted by different endpoints use different keys.  It remains to
   be proven that the nonces used by the fixed endpoint are unique.

   Since the Common IV is fixed, the nonces are determined by PIV, where
   PIV takes the value of the Partial IV of the request or of the
   response, and by 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:

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

   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

   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.5. Unprotected Message Fields

This section analyzes attacks on message fields that are not protected by OSCORE according to the threat model Appendix D.1.

D.5.1. CoAP Header Fields

o Version. The CoAP version [RFC7252] is not expected to be sensitive to disclosure. Currently, there is only one CoAP version defined. A change of this parameter is potentially a
Top   ToC   RFC8613 - Page 90
      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].  CoAP
      proxies are allowed to read and change Token and Token Length
      between hops.  An eavesdropper reading the Token can match
      requests to responses that can be used in traffic analysis.  In
      particular, this is true for notifications, where multiple
      responses are matched to one request.  Modifications of Token and
      Token Length by an on-path attacker may become a denial-of-service
      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.

   o  Code.  The Outer CoAP Code of an OSCORE message is POST or FETCH
      for requests with corresponding response codes.  An endpoint
      receiving the message discards the Outer CoAP Code and uses the
      Inner CoAP Code instead (see Section 4.2).  Hence, modifications
      from attackers to the Outer Code do not impact the receiving
      endpoint.  However, changing the Outer Code from FETCH to a Code
      value for a method that does not work with Observe (such as POST)
      may, depending on proxy implementation since Observe is undefined
      for several Codes, cause the proxy to not forward notifications,
      which is a denial-of-service attack.  The use of FETCH rather than
      POST reveals no more than what is revealed by the presence of the
      Outer Observe option.

   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 do 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 it does not need to retransmit the previous
      message.  By sending a RST, an attacker may be able to cancel an
      observation.  By changing a NON to a CON, the attacker can cause
      the receiving endpoint to ACK messages for which no ACK was

   o  Length.  This field contains the length of the message [RFC8323],
      which may be used for traffic analysis.  This message field is 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.
Top   ToC   RFC8613 - Page 91

D.5.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 CoAP 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 because forward proxies need to change them in order to perform their functions. 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. 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 The Uri-Host may either be omitted, reveal information equivalent to that of the IP address, or reveal 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 it is ignored by the endpoints since the Inner Observe option 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 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 are not bound to the corresponding registrations in the same way responses are bound to requests in OSCORE (see Appendix D.3). However, that does not make attacks based on mismatched cancellations possible, since for cancellations to be accepted, all options in the decrypted message except for ETag options MUST be the same (see Section o Block1/Block2/Size1/Size2. The Outer Block options enable 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
Top   ToC   RFC8613 - Page 92
      maximum size of message, MAX_UNFRAGMENTED_SIZE
      (Section, 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 upon
      between the endpoints.  The presence of this option is not
      expected to reveal any sensitive information about the message

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

D.5.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. This document specifies OPTIONAL error codes and specific diagnostic payloads for OSCORE processing error messages. Such messages might reveal information about how many and which security contexts exist on the server. Servers MAY want to omit the diagnostic payload of error messages, use the same error code for all errors, or avoid responding altogether in case of OSCORE processing errors, if that is a security concern for the application. Moreover, clients MUST NOT rely on the error code or the diagnostic payload to trigger specific actions, as these errors are unprotected and can be spoofed or manipulated. 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.
Top   ToC   RFC8613 - Page 93

D.5.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 [RFC8446] for HTTP hops, which enables encryption and integrity protection of headers, but still leaves some information for traffic analysis.

Appendix E. CDDL Summary

Data structure definitions in the present specification employ the CDDL language for conciseness and precision [RFC8610]. This appendix summarizes the small subset of CDDL that is used in the present specification. Within the subset being used here, a CDDL rule is of the form "name = type", where "name" is the name given to the "type". A "type" can be one of: o a reference to another named type, by giving its name. The predefined named types used in the present specification are as follows: "uint", an unsigned integer (as represented in CBOR by major type 0); "int", an unsigned or negative integer (as represented in CBOR by major type 0 or 1); "bstr", a byte string (as represented in CBOR by major type 2); "tstr", a text string (as represented in CBOR by major type 3); o a choice between two types, by giving both types separated by a "/"; o an array type (as represented in CBOR by major type 4), where the sequence of elements of the array is described by giving a sequence of entries separated by commas ",", and this sequence is enclosed by square brackets "[" and "]". Arrays described by an array description contain elements that correspond one-to-one to the sequence of entries given. Each entry of an array description is of the form "name : type", where "name" is the name given to the entry and "type" is the type of the array element corresponding to this entry.
Top   ToC   RFC8613 - Page 94


The following individuals provided input to this document: Christian Amsuess, Tobias Andersson, Carsten Bormann, Joakim Brorsson, Ben Campbell, Esko Dijk, Jaro Fietz, Thomas Fossati, Martin Gunnarsson, Klaus Hartke, Rikard Hoeglund, Mirja Kuehlewind, Kathleen Moriarty, Eric Rescorla, Michael Richardson, Adam Roach, Jim Schaad, Peter van der Stok, Dave Thaler, Martin Thomson, Marco Tiloca, William Vignat, and Malisa Vucinic. Ludwig Seitz and Goeran Selander worked on this document as part of the CelticPlus project CyberWI, with funding from Vinnova. Ludwig Seitz had additional funding from the SSF project SEC4Factory under the grant RIT17-0032.

Authors' Addresses

Goeran Selander Ericsson AB Email: John Mattsson Ericsson AB Email: Francesca Palombini Ericsson AB Email: Ludwig Seitz RISE Email: