RFC 8613
Object Security for Constrained RESTful Environments (OSCORE)
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
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.
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 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 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
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 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.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
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
requested.
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.
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 4.1.3.2). 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 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.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 4.1.3.5). 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
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 upon
between the endpoints. The presence of this option is not
expected to reveal any sensitive information about the message
exchange.
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.
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.
Acknowledgments
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: goran.selander@ericsson.com John Mattsson Ericsson AB Email: john.mattsson@ericsson.com Francesca Palombini Ericsson AB Email: francesca.palombini@ericsson.com Ludwig Seitz RISE Email: ludwig.seitz@ri.se