CoRE Working Group G. Selander Internet-Draft J. Mattsson Intended status: Standards Track F. Palombini Expires: October 1, 2018 Ericsson AB L. Seitz RISE SICS March 30, 2018 Object Security for Constrained RESTful Environments (OSCORE) draft-ietf-core-object-security-12 Abstract This document defines Object Security for Constrained RESTful Environments (OSCORE), a method for application-layer protection of the Constrained Application Protocol (CoAP), using CBOR Object Signing and Encryption (COSE). OSCORE provides end-to-end protection between endpoints communicating using CoAP or CoAP-mappable HTTP. OSCORE is designed for constrained nodes and networks supporting a range of proxy operations, including translation between different transport protocols. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on October 1, 2018. Copyright Notice Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of Selander, et al. Expires October 1, 2018 [Page 1] Internet-Draft OSCORE March 2018 publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 2. The OSCORE Option . . . . . . . . . . . . . . . . . . . . . . 7 3. The Security Context . . . . . . . . . . . . . . . . . . . . 7 3.1. Security Context Definition . . . . . . . . . . . . . . . 7 3.2. Establishment of Security Context Parameters . . . . . . 10 3.3. Requirements on the Security Context Parameters . . . . . 12 4. Protected Message Fields . . . . . . . . . . . . . . . . . . 12 4.1. CoAP Options . . . . . . . . . . . . . . . . . . . . . . 13 4.2. CoAP Header Fields and Payload . . . . . . . . . . . . . 20 4.3. Signaling Messages . . . . . . . . . . . . . . . . . . . 21 5. The COSE Object . . . . . . . . . . . . . . . . . . . . . . . 22 5.1. Kid Context . . . . . . . . . . . . . . . . . . . . . . . 23 5.2. Nonce . . . . . . . . . . . . . . . . . . . . . . . . . . 24 5.3. Plaintext . . . . . . . . . . . . . . . . . . . . . . . . 25 5.4. Additional Authenticated Data . . . . . . . . . . . . . . 26 6. OSCORE Header Compression . . . . . . . . . . . . . . . . . . 26 6.1. Encoding of the OSCORE Option Value . . . . . . . . . . . 27 6.2. Encoding of the OSCORE Payload . . . . . . . . . . . . . 28 6.3. Examples of Compressed COSE Objects . . . . . . . . . . . 28 7. Message Binding, Sequence Numbers, Freshness and Replay Protection . . . . . . . . . . . . . . . . . . . . . . . . . 31 7.1. Message Binding . . . . . . . . . . . . . . . . . . . . . 31 7.2. Sequence Numbers . . . . . . . . . . . . . . . . . . . . 31 7.3. Freshness . . . . . . . . . . . . . . . . . . . . . . . . 31 7.4. Replay Protection . . . . . . . . . . . . . . . . . . . . 32 7.5. Losing Part of the Context State . . . . . . . . . . . . 32 8. Processing . . . . . . . . . . . . . . . . . . . . . . . . . 34 8.1. Protecting the Request . . . . . . . . . . . . . . . . . 34 8.2. Verifying the Request . . . . . . . . . . . . . . . . . . 34 8.3. Protecting the Response . . . . . . . . . . . . . . . . . 36 8.4. Verifying the Response . . . . . . . . . . . . . . . . . 36 9. Web Linking . . . . . . . . . . . . . . . . . . . . . . . . . 38 10. CoAP-to-CoAP Forwarding Proxy . . . . . . . . . . . . . . . . 38 11. HTTP Operations . . . . . . . . . . . . . . . . . . . . . . . 39 11.1. The HTTP OSCORE Header Field . . . . . . . . . . . . . . 39 11.2. CoAP-to-HTTP Mapping . . . . . . . . . . . . . . . . . . 40 11.3. HTTP-to-CoAP Mapping . . . . . . . . . . . . . . . . . . 40 11.4. HTTP Endpoints . . . . . . . . . . . . . . . . . . . . . 41 Selander, et al. Expires October 1, 2018 [Page 2] Internet-Draft OSCORE March 2018 11.5. Example: HTTP Client and CoAP Server . . . . . . . . . . 41 11.6. Example: CoAP Client and HTTP Server . . . . . . . . . . 43 12. Security Considerations . . . . . . . . . . . . . . . . . . . 44 12.1. End-to-end Protection . . . . . . . . . . . . . . . . . 44 12.2. Security Context Establishment . . . . . . . . . . . . . 45 12.3. Master Secret . . . . . . . . . . . . . . . . . . . . . 45 12.4. Replay Protection . . . . . . . . . . . . . . . . . . . 45 12.5. Client Aliveness . . . . . . . . . . . . . . . . . . . . 46 12.6. Cryptographic Considerations . . . . . . . . . . . . . . 46 12.7. Message Segmentation . . . . . . . . . . . . . . . . . . 46 12.8. Privacy Considerations . . . . . . . . . . . . . . . . . 47 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 47 13.1. COSE Header Parameters Registry . . . . . . . . . . . . 47 13.2. CoAP Option Numbers Registry . . . . . . . . . . . . . . 48 13.3. CoAP Signaling Option Numbers Registry . . . . . . . . . 48 13.4. Header Field Registrations . . . . . . . . . . . . . . . 48 13.5. Media Type Registrations . . . . . . . . . . . . . . . . 49 13.6. CoAP Content-Formats Registry . . . . . . . . . . . . . 51 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 51 14.1. Normative References . . . . . . . . . . . . . . . . . . 51 14.2. Informative References . . . . . . . . . . . . . . . . . 53 Appendix A. Scenario Examples . . . . . . . . . . . . . . . . . 55 A.1. Secure Access to Sensor . . . . . . . . . . . . . . . . . 55 A.2. Secure Subscribe to Sensor . . . . . . . . . . . . . . . 56 Appendix B. Deployment Examples . . . . . . . . . . . . . . . . 57 B.1. Master Secret Used Once . . . . . . . . . . . . . . . . . 57 B.2. Master Secret Used Multiple Times . . . . . . . . . . . . 58 Appendix C. Test Vectors . . . . . . . . . . . . . . . . . . . . 59 C.1. Test Vector 1: Key Derivation with Master Salt . . . . . 59 C.2. Test Vector 2: Key Derivation without Master Salt . . . . 60 C.3. Test Vector 3: OSCORE Request, Client . . . . . . . . . . 61 C.4. Test Vector 4: OSCORE Request, Client . . . . . . . . . . 63 C.5. Test Vector 5: OSCORE Response, Server . . . . . . . . . 64 C.6. Test Vector 6: OSCORE Response with Partial IV, Server . 65 Appendix D. Overview of Security Properties . . . . . . . . . . 66 D.1. Supporting Proxy Operations . . . . . . . . . . . . . . . 66 D.2. Protected Message Fields . . . . . . . . . . . . . . . . 66 D.3. Uniqueness of (key, nonce) . . . . . . . . . . . . . . . 67 D.4. Unprotected Message Fields . . . . . . . . . . . . . . . 68 Appendix E. CDDL Summary . . . . . . . . . . . . . . . . . . . . 71 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 72 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 Selander, et al. Expires October 1, 2018 [Page 3] Internet-Draft OSCORE March 2018 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. 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]. 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). +-----------------------------------+ | 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 Selander, et al. Expires October 1, 2018 [Page 4] Internet-Draft OSCORE March 2018 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. OSCORE is designed to protect as much information as possible while still allowing CoAP proxy operations (Section 10). It works with legacy CoAP-to-CoAP forward proxies [RFC7252], but an OSCORE-aware proxy will be more efficient. HTTP-to-CoAP proxies [RFC8075] and CoAP-to-HTTP proxies 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 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. Selander, et al. Expires October 1, 2018 [Page 5] Internet-Draft OSCORE March 2018 Client Server | OSCORE request - POST example.com: | | Header, Token, | | Options: {OSCORE, ...}, | | Payload: COSE ciphertext | +--------------------------------------------->| | | |<---------------------------------------------+ | OSCORE response - 2.04 (Changed): | | Header, Token, | | Options: {OSCORE, ...}, | | Payload: COSE ciphertext | | | Figure 2: Sketch of CoAP with OSCORE An implementation supporting this specification MAY implement only the client part, MAY implement only the server part, or MAY implement only one of the proxy parts. 1.1. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. Readers are expected to be familiar with the terms and concepts described in CoAP [RFC7252], Observe [RFC7641], Block-wise [RFC7959], COSE [RFC8152], CBOR [RFC7049], CDDL [I-D.ietf-cbor-cddl] as summarized in Appendix E, and constrained environments [RFC7228]. The term "hop" is used to denote a particular leg in the end-to-end path. The concept "hop-by-hop" (as in "hop-by-hop encryption" or "hop-by-hop fragmentation") opposed to "end-to-end", is used in this document to indicate that the messages are processed accordingly in the intermediaries, rather than just forwarded to the next node. The term "stop processing" is used throughout the document to denote that the message is not passed up to the CoAP Request/Response layer (see Figure 1). The terms Common/Sender/Recipient Context, Master Secret/Salt, Sender ID/Key, Recipient ID/Key, and Common IV are defined in Section 3.1. Selander, et al. Expires October 1, 2018 [Page 6] Internet-Draft OSCORE March 2018 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 Section 5 and Section 6). The OSCORE option is critical, safe to forward, part of the cache key, and not repeatable. +------+---+---+---+---+-----------------+--------+--------+---------+ | No. | C | U | N | R | Name | Format | Length | Default | +------+---+---+---+---+-----------------+--------+--------+---------+ | 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 and the Sender ID when present (Section 3). The detailed format and length is specified in Section 6. If the OSCORE flag bits are all zero (0x00) the Option value SHALL be empty (Option Length = 0). An endpoint receiving a CoAP message without payload, that also contains an OSCORE option SHALL treat it as malformed and reject it. A successful response to a request with the OSCORE option SHALL contain the OSCORE option. Whether error responses contain the OSCORE option depends on the error type (see Section 8). For CoAP proxy operations, see Section 10. 3. The Security Context OSCORE requires that client and server establish a shared security context used to process the COSE objects. OSCORE uses COSE with an Authenticated Encryption with 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 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". Selander, et al. Expires October 1, 2018 [Page 7] Internet-Draft OSCORE March 2018 The endpoints protect messages to send using the Sender Context and verify messages received using the Recipient Context, both contexts being derived from the Common Context and other data. Clients and servers need to be able to retrieve the correct security context to use. An endpoint uses its Sender ID (SID) to derive its Sender Context, and the other endpoint uses the same ID, now called Recipient ID (RID), to derive its Recipient Context. In communication between two endpoints, the Sender Context of one endpoint matches the Recipient Context of the other endpoint, and vice versa. Thus, the two security contexts identified by the same IDs in the two endpoints are not the same, but they are partly mirrored. Retrieval and use of the security context are shown in Figure 4. .-------------. .-------------. | Common, | | 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 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. o Master Secret. Variable length, random byte string (see Section 12.3) containing the keying material used to derive traffic keys and IVs. Selander, et al. Expires October 1, 2018 [Page 8] Internet-Draft OSCORE March 2018 o Master Salt. Variable length byte string containing the salt used to derive traffic keys and IVs. o Common IV. Byte string derived from Master Secret and Master Salt. Length is determined by the AEAD Algorithm. The Sender Context contains the following parameters: o Sender ID. Byte string used to identify the Sender Context and to assure unique AEAD 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 and to assure unique AEAD 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. 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 from the Master Key and Master Salt when needed. Alternatively, an endpoint may free up memory by not storing the Master Secret and Master Salt after the other parameters have been derived. 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 Selander, et al. Expires October 1, 2018 [Page 9] Internet-Draft OSCORE March 2018 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 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 string o Key Derivation Function (KDF) * Default is HKDF SHA-256 o Replay Window Type and Size * Default is DTLS-type replay protection with a window size of 32 [RFC6347] All input parameters need to be known to and agreed on by both endpoints, but the replay window may be different in the two endpoints. The 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 in COSE. HKDF SHA-256 is mandatory to implement. The security context parameters Sender Key, Recipient Key, and Common IV Selander, et al. Expires October 1, 2018 [Page 10] Internet-Draft OSCORE March 2018 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 a CBOR array consisting of: info = [ id : bstr, alg_aead : int / tstr, type : tstr, L : uint ] where: o id is the Sender ID or Recipient ID when deriving keys and the empty string when deriving the Common IV. The encoding is described in Section 5. o alg_aead is the AEAD Algorithm, encoded as defined in [RFC8152]. o type is "Key" or "IV". The label is an ASCII string, and does not include a trailing NUL byte. o L is the size of the key/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. 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]. Selander, et al. Expires October 1, 2018 [Page 11] Internet-Draft OSCORE March 2018 3.3. Requirements on the Security Context Parameters As collisions may lead to the loss of both confidentiality and integrity, Sender ID SHALL be unique in the set of all security contexts using the same Master Secret and Master Salt. To assign identifiers, a trusted third party (e.g., [I-D.ietf-ace-oauth-authz]) or a protocol that allows the parties to negotiate locally unique identifiers can be used. The Sender IDs can be very short. 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. 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 keying material, then the endpoint may need to try multiple times before finding the right security context associated to the Recipient ID. The Client MAY provide a 'kid context' parameter (Section 5.1) to help the Server find the right context. While the triple (Master Secret, Master Salt, Sender ID) MUST be unique, the same Master Salt MAY be used with several Master Secrets and the same Master Secret MAY be used with several Master Salts. 4. Protected Message Fields OSCORE transforms a CoAP message (which may have been generated from an HTTP message) into an OSCORE message, and vice versa. OSCORE protects as much of the original message as possible while still allowing certain proxy operations (see Section 10 and Section 11). This section defines how OSCORE protects the message fields and transfers them end-to-end between client and server (in any direction). The remainder of this section and later sections focus on the behavior in terms of CoAP messages. If HTTP is used for a particular hop in the end-to-end path, then this section applies to the conceptual CoAP message that is mappable to/from the original HTTP message as discussed in Section 11. That is, an HTTP message is conceptually transformed to a CoAP message and then to an OSCORE message, and similarly in the reverse direction. An actual implementation might translate directly from HTTP to OSCORE without the intervening CoAP representation. Protection of Signaling messages (Section 5 of [RFC8323]) is specified in Section 4.3. The other parts of this section target Request/Response messages. Selander, et al. Expires October 1, 2018 [Page 12] Internet-Draft OSCORE March 2018 Message fields of the CoAP message may be protected end-to-end between CoAP client and CoAP server in different ways: o Class E: encrypted and integrity protected, o Class I: integrity protected only, or o Class U: unprotected. The sending endpoint SHALL transfer Class E message fields in the ciphertext of the COSE object in the OSCORE message. The sending endpoint SHALL include Class I message fields in the Additional Authenticated Data (AAD) of the AEAD algorithm, allowing the receiving endpoint to detect if the value has changed in transfer. Class U message fields SHALL NOT be protected in transfer. Class I and Class U message field values are transferred in the header or options part of the OSCORE message, which is visible to proxies. Message fields not visible to proxies, i.e., transported in the ciphertext of the COSE object, are called "Inner" (Class E). Message fields transferred in the header or options part of the OSCORE message, which is visible to proxies, are called "Outer" (Class I or U). There are currently no Class I options defined. An OSCORE message may contain both an Inner and an Outer instance of a certain CoAP message field. Inner message fields are intended for the receiving endpoint, whereas Outer message fields are used to enable proxy operations. Inner and Outer message fields are processed independently. 4.1. CoAP Options A summary of how options are protected is shown in Figure 5. Note that some options may have both Inner and Outer message fields which are protected accordingly. Certain options require special processing as is described in Section 4.1.3. Selander, et al. Expires October 1, 2018 [Page 13] Internet-Draft OSCORE March 2018 +------+-----------------+---+---+ | No. | Name | E | U | +------+-----------------+---+---+ | 1 | If-Match | x | | | 3 | Uri-Host | | x | | 4 | ETag | x | | | 5 | If-None-Match | x | | | 6 | Observe | | x | | 7 | Uri-Port | | x | | 8 | Location-Path | x | | | TBD1 | OSCORE | | x | | 11 | Uri-Path | x | | | 12 | Content-Format | x | | | 14 | Max-Age | x | x | | 15 | Uri-Query | x | | | 17 | Accept | x | | | 20 | Location-Query | x | | | 23 | Block2 | x | x | | 27 | Block1 | x | x | | 28 | Size2 | x | x | | 35 | Proxy-Uri | | x | | 39 | Proxy-Scheme | | x | | 60 | Size1 | x | x | | 258 | No-Response | x | x | +------+-----------------+---+---+ E = Encrypt and Integrity Protect (Inner) U = Unprotected (Outer) Figure 5: Protection of CoAP Options Options that are unknown or for which OSCORE processing is not defined SHALL be processed as class E (and no special processing). Specifications of new CoAP options SHOULD define how they are processed with OSCORE. A new COAP option SHOULD be of class E unless it requires proxy processing. 4.1.1. Inner Options Inner option message fields (class E) are used to communicate directly with the other endpoint. The sending endpoint SHALL write the Inner option message fields present in the original CoAP message into the plaintext of the COSE object (Section 5.3), and then remove the Inner option message fields from the OSCORE message. Selander, et al. Expires October 1, 2018 [Page 14] Internet-Draft OSCORE March 2018 The processing of Inner option message fields by the receiving endpoint is specified in Section 8.2 and Section 8.4. 4.1.2. Outer Options Outer option message fields (Class U or I) are used to support proxy operations, see Appendix D.1. The sending endpoint SHALL include the Outer option message field present in the original message in the options part of the OSCORE message. All Outer option message fields, including the OSCORE option, SHALL be encoded as described in Section 3.1 of [RFC7252], where the delta is the difference to the previously included instance of Outer option message field. The processing of Outer options by the receiving endpoint is specified in Section 8.2 and Section 8.4. A procedure for integrity-protection-only of Class I option message fields is specified in Section 5.4. Proxies MUST NOT change the order of option's occurrences, for options repeatable and of class I. Note: There are currently no Class I option message fields defined. 4.1.3. Special Options Some options require special processing as specified in this section. 4.1.3.1. Max-Age An Inner Max-Age message field is used to indicate the maximum time a response may be cached by the client (as defined in [RFC7252]), end- to-end from the server to the client, taking into account that the option is not accessible to proxies. The Inner Max-Age SHALL be processed by OSCORE as a normal Inner option, specified in Section 4.1.1. An Outer Max-Age message field is used to avoid unnecessary caching of OSCORE error responses at OSCORE unaware intermediary nodes. A server MAY set a Class U Max-Age message field with value zero to OSCORE error responses, which are described in Section 7.4, Section 8.2 and Section 8.4. Such message field is then processed according to Section 4.1.2. Successful OSCORE responses do not need to include an Outer Max-Age option since the responses are non-cacheable by construction (see Section 4.2). Selander, et al. Expires October 1, 2018 [Page 15] Internet-Draft OSCORE March 2018 4.1.3.2. Proxy-Uri Proxy-Uri, when present, is split by OSCORE into class U options and class E options, which are processed accordingly. When Proxy-Uri is used in the original CoAP message, Uri-* are not present [RFC7252]. The sending endpoint SHALL first decompose the Proxy-Uri value of the original CoAP message into the Proxy-Scheme, Uri-Host, Uri-Port, Uri- Path, and Uri-Query options (if present) according to Section 6.4 of [RFC7252]. Uri-Path and Uri-Query are class E options and SHALL be protected and processed as Inner options (Section 4.1.1). Uri-Host being an Outer option SHOULD NOT contain privacy sensitive information. The Proxy-Uri option of the OSCORE message SHALL be set to the composition of Proxy-Scheme, Uri-Host, and Uri-Port options (if present) as specified in Section 6.5 of [RFC7252], and processed as an Outer option of Class U (Section 4.1.2). Note that replacing the Proxy-Uri value with the Proxy-Scheme and Uri-* options works by design for all CoAP URIs (see Section 6 of [RFC7252]). OSCORE-aware HTTP servers should not use the userinfo component of the HTTP URI (as defined in Section 3.2.1 of [RFC3986]), so that this type of replacement is possible in the presence of CoAP- to-HTTP proxies. In future documents specifying cross-protocol proxying behavior using different URI structures, it is expected that the authors will create Uri-* options that allow decomposing the Proxy-Uri, and specify in which OSCORE class they belong. An example of how Proxy-Uri is processed is given here. Assume that the original CoAP message contains: o Proxy-Uri = "coap://example.com/resource?q=1" During OSCORE processing, Proxy-Uri is split into: o Proxy-Scheme = "coap" o Uri-Host = "example.com" o Uri-Port = "5683" o Uri-Path = "resource" o Uri-Query = "q=1" Selander, et al. Expires October 1, 2018 [Page 16] Internet-Draft OSCORE March 2018 Uri-Path and Uri-Query follow the processing defined in Section 4.1.1, and are thus encrypted and transported in the COSE object. The remaining options are composed into the Proxy-Uri included in the options part of the OSCORE message, which has value: o Proxy-Uri = "coap://example.com" See Sections 6.1 and 12.6 of [RFC7252] for more information. 4.1.3.3. The Block Options Block-wise [RFC7959] is an optional feature. An implementation MAY support [RFC7252] and the OSCORE option without supporting block-wise transfers. The Block options (Block1, Block2, Size1, Size2), when Inner message fields, provide secure message segmentation such that each segment can be verified. The Block options, when Outer message fields, enables hop-by-hop fragmentation of the OSCORE message. Inner and Outer block processing may have different performance properties depending on the underlying transport. The end-to-end integrity of the message can be verified both in case of Inner and Outer Block-wise transfers provided all blocks are received. 4.1.3.3.1. Inner Block Options The sending CoAP endpoint MAY fragment a CoAP message as defined in [RFC7959] before the message is processed by OSCORE. In this case the Block options SHALL be processed by OSCORE as normal Inner options (Section 4.1.1). The receiving CoAP endpoint SHALL process the OSCORE message before processing Block-wise as defined in [RFC7959]. 4.1.3.3.2. Outer Block Options Proxies MAY fragment an OSCORE message using [RFC7959], by introducing Block option message fields that are Outer (Section 4.1.2). Note that the Outer Block options are neither encrypted nor integrity protected. As a consequence, a proxy can maliciously inject block fragments indefinitely, since the receiving endpoint needs to receive the last block (see [RFC7959]) to be able to compose the OSCORE message and verify its integrity. Therefore, applications supporting OSCORE and [RFC7959] MUST specify a security policy defining a maximum unfragmented message size (MAX_UNFRAGMENTED_SIZE) considering the maximum size of message which can be handled by the endpoints. Messages exceeding this size SHOULD be fragmented by the sending endpoint using Inner Block options (Section 4.1.3.3.1). Selander, et al. Expires October 1, 2018 [Page 17] Internet-Draft OSCORE March 2018 An endpoint receiving an OSCORE message with an Outer Block option SHALL first process this option according to [RFC7959], until all blocks of the OSCORE message have been received, or the cumulated message size of the blocks exceeds MAX_UNFRAGMENTED_SIZE. In the former case, the processing of the OSCORE message continues as defined in this document. In the latter case the message SHALL be discarded. Because of encryption of Uri-Path and Uri-Query, messages to the same server may, from the point of view of a proxy, look like they also target the same resource. A proxy SHOULD mitigate a potential mix-up of blocks from concurrent requests to the same server, for example using the Request-Tag processing specified in Section 3.3.2 of [I-D.ietf-core-echo-request-tag]. 4.1.3.4. Observe Observe [RFC7641] is an optional feature. An implementation MAY support [RFC7252] and the OSCORE option without supporting [RFC7641]. The Observe option as used here targets the requirements on forwarding of [I-D.hartke-core-e2e-security-reqs] (Section 2.2.1). An Observe intermediary MUST forward the OSCORE option unchanged. In order for an OSCORE-unaware proxy to support forwarding of Observe messages [RFC7641], there SHALL be an Outer Observe option, i.e., present in the options part of the OSCORE message. With OSCORE, Observe intermediaries are forwarding messages without being able to re-send cached notifications to other clients. In order to support multiple concurrent Observe registrations in the same endpoint, Observe intermediaries are allowed to deviate from [RFC7641] and register multiple times to the same (root) resource, since the actual target resource is encrypted and not visible in the OSCORE message. The processing of the CoAP Code for Observe messages is described in Section 4.2. The Observe option in the CoAP request may be legitimately removed by a proxy or ignored by the server. In these cases, the server processes the request as a non-Observe request and produce a non- Observe response. If the OSCORE client receives a response to an Observe request without an Outer Observe value, then it verifies the response as a non-Observe response, as specified in Section 8.4. If the OSCORE client receives a response to a non-Observe request with an Outer Observe value, it stops processing the message, as specified in Section 8.4. It the server accepts the Observe registration, a Partial IV must be included in all notifications (both successful and error). To secure Selander, et al. Expires October 1, 2018 [Page 18] Internet-Draft OSCORE March 2018 the order of notifications, 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 (see Section 7.4). The Notification Number is initialized to the Partial IV of the first successfully received notification response to the registration request. In contrast to [RFC7641], the received Partial IV MUST always be compared with the Notification Number, which thus MUST NOT be forgotten after 128 seconds. Further details of replay protection of notifications are specified in Section 7.4. The client MAY ignore the Observe option value. Clients can re-register observations to ensure that the observation is still active and establish freshness again ([RFC7641] Section 3.3.1). When an OSCORE observation is refreshed, not only the ETags, but also the partial IV (and thus the payload and OSCORE option) change. The server uses the new request's Partial IV as the 'request_piv' of new responses. 4.1.3.5. No-Response No-Response [RFC7967] is an optional feature. Clients using No- Response MUST set both an Inner (Class E) and an Outer (Class U) No- Response option, with the same value. The Inner No-Response option is used to communicate to the server the client's disinterest in certain classes of responses to a particular request. The Inner No-Response SHALL be processed by OSCORE as specified in Section 4.1.1. 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. The Outer No- Response option is processed according to Section 4.1.2. Note the effect in step 8 of Section 8.4 when applied to No-Response. Applications should consider that a proxy may remove the Outer No- Response option from the request. Applications using No-Response can specify policies to deal with cases where servers receive an Inner No-Response option only, which may be the result of the request having traversed a No-Response unaware proxy, and update the processing in Section 8.4 accordingly. This avoids unnecessary error responses to clients and bandwidth reductions to servers, due to No- Response unaware proxies. Selander, et al. Expires October 1, 2018 [Page 19] Internet-Draft OSCORE March 2018 4.1.3.6. OSCORE The OSCORE option is only defined to be present in OSCORE messages, as an indication that OSCORE processing have been performed. The content in the OSCORE option is neither encrypted nor integrity protected as a whole but some part of the content of this option is protected (see Section 5.4). Nested use of OSCORE is not supported: If OSCORE processing detects an OSCORE option in the original CoAP message, then processing SHALL be stopped. 4.2. CoAP Header Fields and Payload A summary of how the CoAP header fields and payload are protected is shown in Figure 6, including fields specific to CoAP over UDP and CoAP over TCP (marked accordingly in the table). +------------------+---+---+ | Field | E | U | +------------------+---+---+ | Version (UDP) | | x | | Type (UDP) | | x | | Length (TCP) | | x | | Token Length | | x | | Code | x | | | Message ID (UDP) | | x | | Token | | x | | Payload | x | | +------------------+---+---+ E = Encrypt and Integrity Protect (Inner) U = Unprotected (Outer) Figure 6: Protection of CoAP Header Fields and Payload Most CoAP Header fields (i.e. the message fields in the fixed 4-byte header) are required to be read and/or changed by CoAP proxies and thus cannot in general be protected end-to-end between the endpoints. As mentioned in Section 1, OSCORE protects the CoAP Request/Response layer only, and not the Messaging Layer (Section 2 of [RFC7252]), so fields such as Type and Message ID are not protected with OSCORE. The CoAP Header field Code is protected by OSCORE. Code SHALL be encrypted and integrity protected (Class E) to prevent an intermediary from eavesdropping on or manipulating the Code (e.g., changing from GET to DELETE). The sending endpoint SHALL write the Code of the original CoAP message into the plaintext of the COSE object (see Section 5.3). Selander, et al. Expires October 1, 2018 [Page 20] Internet-Draft OSCORE March 2018 After that, the sending endpoint writes an Outer Code to the OSCORE message. The Outer Code SHALL be set to 0.02 (POST) or 0.05 (FETCH) for requests. For non-Observe requests the client SHALL set the Outer Code to 0.02 (POST). For responses, the sending endpoint SHALL respond with Outer Code 2.04 (Changed) to 0.02 (POST) requests, and with Outer Code 2.05 (Content) to 0.05 (FETCH) requests. Using FETCH with Observe allows OSCORE to be compliant with the Observe processing in OSCORE-unaware intermediaries. The choice of POST and FETCH [RFC8132] allows all OSCORE messages to have payload. The receiving endpoint SHALL discard the Outer Code in the OSCORE message and write the Code of the COSE object plaintext (Section 5.3) into the decrypted CoAP message. The other currently defined CoAP Header fields are Unprotected (Class U). The sending endpoint SHALL write all other header fields of the original message into the header of the OSCORE message. The receiving endpoint SHALL write the header fields from the received OSCORE message into the header of the decrypted CoAP message. The CoAP Payload, if present in the original CoAP message, SHALL be encrypted and integrity protected and is thus an Inner message field. The sending endpoint writes the payload of the original CoAP message into the plaintext (Section 5.3) input to the COSE object. The receiving endpoint verifies and decrypts the COSE object, and recreates the payload of the original CoAP message. 4.3. Signaling Messages Signaling messages (CoAP Code 7.00-7.31) were introduced to exchange information related to an underlying transport connection in the specific case of CoAP over reliable transports [RFC8323]. OSCORE MAY be used to protect Signaling if the endpoints for OSCORE coincide with the endpoints for the signaling message. If OSCORE is used to protect Signaling then: o To comply with [RFC8323], an initial empty CSM message SHALL be sent. The subsequent signaling message SHALL be protected. o Signaling messages SHALL be protected as CoAP Request messages, except in the case the Signaling message is a response to a previous Signaling message, in which case it SHALL be protected as a CoAP Response message. For example, 7.02 (Ping) is protected as a CoAP Request and 7.03 (Pong) as a CoAP response. Selander, et al. Expires October 1, 2018 [Page 21] Internet-Draft OSCORE March 2018 o The Outer Code for Signaling messages SHALL be set to 0.02 (POST), unless it is a response to a previous Signaling message, in which case it SHALL be set to 2.04 (Changed). o All Signaling options, except the OSCORE option, SHALL be Inner (Class E). NOTE: Option numbers for Signaling messages are specific to the CoAP Code (see Section 5.2 of [RFC8323]). If OSCORE is not used to protect Signaling, Signaling messages SHALL be unaltered by OSCORE. 5. The COSE Object This section defines how to use COSE [RFC8152] to wrap and protect data in the original message. OSCORE uses the untagged COSE_Encrypt0 structure with an Authenticated Encryption with Additional Data (AEAD) algorithm. The key lengths, IV length, nonce length, and maximum Sender Sequence Number are algorithm dependent. The AEAD algorithm AES-CCM-16-64-128 defined in Section 10.2 of [RFC8152] is mandatory to implement. For AES-CCM-16-64-128 the length of Sender Key and Recipient Key is 128 bits, the length of nonce and Common IV is 13 bytes. The maximum Sender Sequence Number is specified in Section 12. As specified in [RFC5116], plaintext denotes the data that is to be encrypted and integrity protected, and Additional Authenticated Data (AAD) denotes the data that is to be integrity protected only. The COSE Object SHALL be a COSE_Encrypt0 object with fields defined as follows o The 'protected' field is empty. o The 'unprotected' field includes: * The 'Partial IV' parameter. The value is set to the Sender Sequence Number. All leading zeroes SHALL be removed when encoding the Partial IV, except in the case of value 0 which is encoded to the byte string 0x00. This parameter SHALL be present in requests. In case of Observe notifications (Section 4.1.3.4) the Partial IV SHALL be present in responses, and otherwise the Partial IV will not typically be present in responses. Selander, et al. Expires October 1, 2018 [Page 22] Internet-Draft OSCORE March 2018 * The 'kid' parameter. The value is set to the Sender ID. This parameter SHALL be present in requests and will not typically be present in responses. An example where the Sender ID is included in a response is the extension of OSCORE to group communication [I-D.ietf-core-oscore-groupcomm]. * Optionally, a 'kid context' parameter as defined in Section 5.1. This parameter MAY be present in requests and SHALL NOT be present in responses. o The 'ciphertext' field is computed from the secret key (Sender Key or Recipient Key), AEAD nonce (see Section 5.2), plaintext (see Section 5.3), and the Additional Authenticated Data (AAD) (see Section 5.4) following Section 5.2 of [RFC8152]. The encryption process is described in Section 5.3 of [RFC8152]. 5.1. Kid Context For certain use cases, e.g. deployments where the same kid is used with multiple contexts, it is necessary or favorable for the sender to provide an additional identifier of the security material to use, in order for the receiver to retrieve or establish the correct key. The kid context parameter is used to provide such additional input. The kid context and kid are used to determine the security context, or to establish the necessary input parameters to derive the security context (see Section 3.2). The application defines how this is done. The kid context is implicitly integrity protected, as a manipulation that leads to the wrong key (or no key) being retrieved results in an error, as described in Section 8.2. A summary of the COSE header parameter kid context defined above can be found in Figure 7. Some examples of relevant uses of kid context are the following: o If the client has an identifier in some other namespace which can be used by the server to retrieve or establish the security context, then that identifier can be used as kid context. The kid context may be used as Master Salt (Section 3.1) for additional entropy of the security contexts (see for example Appendix B.2 or [I-D.ietf-6tisch-minimal-security]). o In case of a group communication scenario [I-D.ietf-core-oscore-groupcomm], if the server belongs to multiple groups, then a group identifier can be used as kid context to enable the server to find the right security context. Selander, et al. Expires October 1, 2018 [Page 23] Internet-Draft OSCORE March 2018 +----------+--------+------------+----------------+-----------------+ | name | label | value type | value registry | description | +----------+--------+------------+----------------+-----------------+ | kid | TBD2 | bstr | | Identifies the | | context | | | | kid context | +----------+--------+------------+----------------+-----------------+ Figure 7: Additional common header parameter for the COSE object 5.2. Nonce The AEAD nonce is constructed in the following way (see Figure 8): 1. left-padding the Partial IV (PIV) in network byte order with zeroes to exactly 5 bytes, 2. left-padding the Sender ID of the endpoint that generated the Partial IV (ID_PIV) in network byte order with zeroes to exactly nonce length minus 6 bytes, 3. concatenating the size of the ID_PIV (a single byte S) with the padded ID_PIV and the padded PIV, 4. and then XORing with the Common IV. Note that in this specification only algorithms that use nonces equal or greater than 7 bytes are supported. The nonce construction with S, ID_PIV, and PIV together with endpoint unique IDs and encryption keys makes it easy to verify that the nonces used with a specific key will be unique, see Appendix D.3. If the Partial IV is not present in a response, the nonce from the request is used. For responses that are not notifications (i.e. when there is a single response to a request), the request and the response should typically use the same nonce to reduce message overhead. Both alternatives provide all the required security properties, see Appendix D.3 and Section 7.4. The only non-Observe scenario where a Partial IV must be included in a response is when the server is unable to perform replay protection, see Section 7.5.2. For processing instructions see Section 8. Selander, et al. Expires October 1, 2018 [Page 24] Internet-Draft OSCORE March 2018 <- nonce length minus 6 B -> <-- 5 bytes --> +---+-------------------+--------+---------+-----+ | S | padding | ID_PIV | padding | PIV |----+ +---+-------------------+--------+---------+-----+ | | <---------------- nonce length ----------------> | +------------------------------------------------+ | | Common IV |->(XOR) +------------------------------------------------+ | | <---------------- nonce length ----------------> | +------------------------------------------------+ | | Nonce |<---+ +------------------------------------------------+ Figure 8: AEAD Nonce Formation 5.3. Plaintext The plaintext is formatted as a CoAP message without Header (see Figure 9) consisting of: o the Code of the original CoAP message as defined in Section 3 of [RFC7252]; and o all Inner option message fields (see Section 4.1.1) present in the original CoAP message (see Section 4.1). The options are encoded as described in Section 3.1 of [RFC7252], where the delta is the difference to the previously included instance of Class E option; and o the Payload of original CoAP message, if present, and in that case prefixed by the one-byte Payload Marker (0xFF). 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code | Class E options (if any) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1 1 1 1 1 1 1 1| Payload (if any) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ (only if there is payload) Figure 9: Plaintext NOTE: The plaintext contains all CoAP data that needs to be encrypted end-to-end between the endpoints. Selander, et al. Expires October 1, 2018 [Page 25] Internet-Draft OSCORE March 2018 5.4. Additional Authenticated Data The external_aad SHALL be a CBOR array as defined below: external_aad = [ oscore_version : uint, algorithms : [ alg_aead : int / tstr ], request_kid : bstr, request_piv : bstr, options : bstr ] where: o oscore_version: contains the OSCORE version number. Implementations of this specification MUST set this field to 1. Other values are reserved for future versions. o algorithms: contains (for extensibility) an array of algorithms, according to this specification only containing alg_aead. o alg_aead: contains the AEAD Algorithm from the security context used for the exchange (see Section 3.1). o request_kid: contains the value of the 'kid' in the COSE object of the request (see Section 5). o request_piv: contains the value of the 'Partial IV' in the COSE object of the request (see Section 5). o options: contains the Class I options (see Section 4.1.2) present in the original CoAP message encoded as described in Section 3.1 of [RFC7252], where the delta is the difference to the previously included instance of class I option. The oscore_version and algorithms parameters are established out-of- band and are thus never transported in OSCORE, but the external_aad allows to verify that they are the same in both endpoints. NOTE: The format of the external_aad is for simplicity the same for requests and responses, although some parameters, e.g. request_kid, need not be integrity protected in the requests. 6. OSCORE Header Compression The Concise Binary Object Representation (CBOR) [RFC7049] combines very small message sizes with extensibility. The CBOR Object Signing and Encryption (COSE) [RFC8152] uses CBOR to create compact encoding Selander, et al. Expires October 1, 2018 [Page 26] Internet-Draft OSCORE March 2018 of signed and encrypted data. COSE is however constructed to support a large number of different stateless use cases, and is not fully optimized for use as a stateful security protocol, leading to a larger than necessary message expansion. In this section, we define a stateless header compression mechanism, simply removing redundant information from the COSE objects, which significantly reduces the per-packet overhead. The result of applying this mechanism to a COSE object is called the "compressed COSE object". The COSE_Encrypt0 object used in OSCORE is transported in the OSCORE option and in the Payload. The Payload contains the Ciphertext and the headers of the COSE object are compactly encoded as described in the next section. 6.1. Encoding of the OSCORE Option Value The value of the OSCORE option SHALL contain the OSCORE flag bits, the Partial IV parameter, the kid context parameter (length and value), and the kid parameter as follows: 0 1 2 3 4 5 6 7 <--------- n bytes -------------> +-+-+-+-+-+-+-+-+--------------------------------- |0 0 0|h|k| n | Partial IV (if any) ... +-+-+-+-+-+-+-+-+--------------------------------- <- 1 byte -> <------ s bytes -----> +------------+----------------------+------------------+ | s (if any) | kid context (if any) | kid (if any) ... | +------------+----------------------+------------------+ Figure 10: The OSCORE Option Value o The first byte of flag bits encodes the following set of flags and the length of the Partial IV parameter: * The three least significant bits encode the Partial IV length n. If n = 0 then the Partial IV is not present in the compressed COSE object. The values n = 6 and n = 7 are reserved. * The fourth least significant bit is the kid flag, k: it is set to 1 if the kid is present in the compressed COSE object. * The fifth least significant bit is the kid context flag, h: it is set to 1 if the compressed COSE object contains a kid context (see Section 5.1). Selander, et al. Expires October 1, 2018 [Page 27] Internet-Draft OSCORE March 2018 * The sixth to eighth least significant bits are reserved for future use. These bits SHALL be set to zero when not in use. According to this specification, if any of these bits are set to 1 the message is considered to be malformed and decompression fails as specified in item 3 of Section 8.2. o The following n bytes encode the value of the Partial IV, if the Partial IV is present (n > 0). o The following 1 byte encode the length of the kid context (Section 5.1) s, if the kid context flag is set (h = 1). o The following s bytes encode the kid context, if the kid context flag is set (h = 1). o The remaining bytes encode the value of the kid, if the kid is present (k = 1). Note that the kid MUST be the last field of the OSCORE option value, even in case reserved bits are used and additional fields are added to it. The length of the OSCORE option thus depends on the presence and length of Partial IV, kid context, kid, as specified in this section, and on the presence and length of the other parameters, as defined in the separate documents. 6.2. Encoding of the OSCORE Payload The payload of the OSCORE message SHALL encode the ciphertext of the COSE object. 6.3. Examples of Compressed COSE Objects This section covers a list of OSCORE Header Compression examples for requests and responses. The examples assume the COSE_Encrypt0 object is set (which means the CoAP message and cryptographic material is known). Note that the full CoAP unprotected message, as well as the full security context, is not reported in the examples, but only the input necessary to the compression mechanism, i.e. the COSE_Encrypt0 object. The output is the compressed COSE object as defined in Section 6, divided into two parts, since the object is transported in two CoAP fields: OSCORE option and payload. 1. Request with ciphertext = 0xaea0155667924dff8a24e4cb35b9, kid = 0x25, and Partial IV = 0x05 Selander, et al. Expires October 1, 2018 [Page 28] Internet-Draft OSCORE March 2018 Before compression (24 bytes): [ h'', { 4:h'25', 6:h'05' }, h'aea0155667924dff8a24e4cb35b9' ] After compression (17 bytes): Flag byte: 0b00001001 = 0x09 Option Value: 09 05 25 (3 bytes) Payload: ae a0 15 56 67 92 4d ff 8a 24 e4 cb 35 b9 (14 bytes) 2. Request with ciphertext = 0xaea0155667924dff8a24e4cb35b9, kid = empty string, and Partial IV = 0x00 Before compression (23 bytes): [ h'', { 4:h'', 6:h'00' }, h'aea0155667924dff8a24e4cb35b9' ] After compression (16 bytes): Flag byte: 0b00001001 = 0x09 Option Value: 09 00 (2 bytes) Payload: ae a0 15 56 67 92 4d ff 8a 24 e4 cb 35 b9 (14 bytes) 3. Request with ciphertext = 0xaea0155667924dff8a24e4cb35b9, kid = empty string, Partial IV = 0x05, and kid context = 0x44616c656b Before compression (30 bytes): [ h'', { 4:h'', 6:h'05', 8:h'44616c656b' }, h'aea0155667924dff8a24e4cb35b9' ] Selander, et al. Expires October 1, 2018 [Page 29] Internet-Draft OSCORE March 2018 After compression (22 bytes): Flag byte: 0b00011001 = 0x19 Option Value: 19 05 05 44 61 6c 65 6b (8 bytes) Payload: ae a0 15 56 67 92 4d ff 8a 24 e4 cb 35 b9 (14 bytes) 4. Response with ciphertext = 0xaea0155667924dff8a24e4cb35b9 and no Partial IV Before compression (18 bytes): [ h'', {}, h'aea0155667924dff8a24e4cb35b9' ] After compression (14 bytes): Flag byte: 0b00000000 = 0x00 Option Value: (0 bytes) Payload: ae a0 15 56 67 92 4d ff 8a 24 e4 cb 35 b9 (14 bytes) 5. Response with ciphertext = 0xaea0155667924dff8a24e4cb35b9 and Partial IV = 0x07 Before compression (21 bytes): [ h'', { 6:h'07' }, h'aea0155667924dff8a24e4cb35b9' ] After compression (16 bytes): Flag byte: 0b00000001 = 0x01 Option Value: 01 07 (2 bytes) Payload: ae a0 15 56 67 92 4d ff 8a 24 e4 cb 35 b9 (14 bytes) Selander, et al. Expires October 1, 2018 [Page 30] Internet-Draft OSCORE March 2018 7. Message Binding, Sequence Numbers, Freshness and Replay Protection 7.1. Message Binding In order to prevent response delay and mismatch attacks [I-D.mattsson-core-coap-actuators] from on-path attackers and compromised intermediaries, OSCORE binds responses to the requests by including the kid and Partial IV of the request in the AAD of the response. The server therefore needs to store the kid and Partial IV of the request until all responses have been sent. 7.2. Sequence Numbers An AEAD nonce MUST NOT be used more than once per AEAD key. The uniqueness of (key, nonce) pairs is shown in Appendix D.3, and in particular depends on a correct usage of Partial IVs. If messages are processed concurrently, the operation of reading and increasing the Sender Sequence Number MUST be atomic. The maximum Sender Sequence Number is algorithm dependent (see Section 12), and SHALL be less than 2^40. If the Sender Sequence Number exceeds the maximum, the endpoint MUST NOT process any more messages with the given Sender Context. If necessary, the endpoint SHOULD acquire a new security context before this happens. The latter is out of scope of this document. 7.3. Freshness For requests, OSCORE provides only the guarantee that the request is not older than the security context. For applications having stronger demands on request freshness (e.g., control of actuators), OSCORE needs to be augmented with mechanisms providing freshness, for example as specified in [I-D.ietf-core-echo-request-tag]. Assuming an honest server, the message binding guarantees that a response is not older than its request. For responses that are not notifications (i.e. when there is a single response to a request), this gives absolute freshness. For notifications, the absolute freshness gets weaker with time, and it is RECOMMENDED that the client regularly re-register the observation. Note that the message binding does not guarantee that misbehaving server created the response before receiving the request, i.e. it does not verify server aliveness. For requests and notifications, OSCORE also provides relative freshness in the sense that the received Partial IV allows a recipient to determine the relative order of requests or responses. Selander, et al. Expires October 1, 2018 [Page 31] Internet-Draft OSCORE March 2018 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. 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 may be too restrictive and the default replay window be more suitable (see Section 3.2.2). Responses that are not notifications (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. A client receiving a notification SHALL compare the Partial IV of a received notification with the Notification Number associated to that Observe registration. A client MUST consider the notification with the highest Partial IV as the freshest, regardless of the order of arrival. If the verification of the response succeeds, and the received Partial IV was greater than the Notification Number then the client SHALL overwrite the corresponding Notification Number with the received Partial IV (see step 7 of Section 8.4. The client MUST stop processing notifications with a Partial IV which has been previously received. The client MAY process only notifications which have greater Partial IV than the Notification Number. If messages are processed concurrently, the Partial IV needs to be validated a second time after decryption and before updating the replay protection data. The operation of validating the Partial IV and updating the replay protection data MUST be atomic. 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 Selander, et al. Expires October 1, 2018 [Page 32] Internet-Draft OSCORE March 2018 Notification Numbers. These are typically stored in RAM and therefore lost in the case of an unplanned reboot. After boot, an endpoint MAY reject to use pre-existing security contexts, and MAY 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. After boot, an endpoint MAY use a partly persistently stored security context, but then the endpoint MUST NOT reuse a previous Sender Sequence Number and MUST NOT accept previously accepted 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. 7.5.2. Replay Window To prevent accepting replay of previously received requests, the server MAY perform the following procedure after boot: o For each stored security context, the first time after boot the server receives an OSCORE request, the server responds with the Echo option [I-D.ietf-core-echo-request-tag] to get a request with verifiable freshness. The server MUST use its Partial IV when generating the AEAD nonce and MUST include the Partial IV in the response. If the server using the Echo option can verify a second request as fresh, then the Partial IV of the second request is set as the lower limit of the replay window. 7.5.3. Replay Protection of Observe Notifications To prevent accepting replay of previously received notification responses, the client MAY perform the following procedure after boot: Selander, et al. Expires October 1, 2018 [Page 33] Internet-Draft OSCORE March 2018 o The client rejects notifications bound to the earlier registration, removes all Notification Numbers and re-registers using Observe. 8. Processing This section describes the OSCORE message processing. 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 Section 5.4 and Section 5.3. 3. Encode the Partial IV (Sender Sequence Number in network byte order) and increment the Sender Sequence Number by one. 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). 6. Store the attribute-value pair (Token, {Security Context, PIV}) in order to be able to find the Recipient Context and the request_piv from the Token in the response. 8.2. Verifying the Request A server receiving a request containing the OSCORE option SHALL perform the following steps: 1. Process Outer Block options according to [RFC7959], until all blocks of the request have been received (see Section 4.1.3.3). 2. Discard the message Code and all non-special Inner option message fields (marked in Figure 5 with 'x' in column E only) present in the received message. For example, an If-Match Outer option is discarded, but an Uri-Host Outer option is not discarded. Selander, et al. Expires October 1, 2018 [Page 34] Internet-Draft OSCORE March 2018 3. Decompress the COSE Object (Section 6) and retrieve the Recipient Context associated with the Recipient ID in the 'kid' parameter. 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 message. The server MAY set an Outer Max-Age option with value zero. The diagnostic payload SHOULD contain the string "Failed to decode COSE". * the server fails to retrieve a Recipient Context with Recipient ID corresponding to the 'kid' parameter received, the server 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". 4. Verify the 'Partial IV' parameter using the Replay Window, as described in Section 7.4. 5. Compose the Additional Authenticated Data, as described in Section 5.4. 6. Compute the AEAD nonce from the Recipient ID, Common IV, and the 'Partial IV' parameter, received in the COSE Object. 7. 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. 8. For each decrypted option, check if the option is also present as an Outer option: if it is, discard the Outer. For example: the message contains a Max-Age Inner and a Max-Age Outer option. The Outer Max-Age is discarded. Selander, et al. Expires October 1, 2018 [Page 35] Internet-Draft OSCORE March 2018 9. Add decrypted code, options and payload to the decrypted request. The OSCORE option is removed. 10. The decrypted CoAP request is processed according to [RFC7252]. 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 (point 10. in Section 8.2) are protected, as well as successful CoAP responses, while the OSCORE errors (point 3, 4, and 7 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 used to verify the request. 2. Compose the Additional Authenticated Data and the plaintext, as described in Section 5.4 and Section 5.3. 3. Compute the AEAD nonce * For Observe notifications, encode the Partial IV (Sender Sequence Number in network byte order) and increment the Sender Sequence Number by one. Compute the AEAD nonce from the Sender ID, Common IV, and Partial IV as described in Section 5.2. * For responses that are not Observe notifications, either use the nonce from the request, or compute a new nonce from the Sender ID, Common IV, and a new Partial IV as described in Section 5.2, and increment the Sender Sequence Number by one. 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.4. Verifying the Response A client receiving a response containing the OSCORE option SHALL perform the following steps: Selander, et al. Expires October 1, 2018 [Page 36] Internet-Draft OSCORE March 2018 1. Process Outer Block options according to [RFC7959], until all blocks of the OSCORE message have been received (see Section 4.1.3.3). 2. Discard the message Code and all non-special Class E options from the message. For example, ETag Outer option is discarded, Max-Age Outer option is not discarded. 3. Retrieve the Recipient Context associated with the Token. Decompress the COSE Object (Section 6). If either the decompression or the COSE message fails to decode, then go to 11. 4. If the Observe option is present in the response, but the request was not an Observe registration, then go to 11. If a Partial IV is required (i.e. an Observe option is included or the Notification number for the observation has already been initiated), but not present in the response, then go to 11. For Observe notifications, verify the received 'Partial IV' parameter against the corresponding Notification Number as described in Section 7.4. 5. Compose the Additional Authenticated Data, as described in Section 5.4. 6. Compute the AEAD nonce * If the Partial IV are not present in the response, the nonce from the request is used. * If the Partial IV is present in the response, compute the nonce from the Recipient ID, Common IV, and the 'Partial IV' parameter, received in the COSE Object. 7. 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, then go to 11. 8. If the response is a notification, initiate or update the corresponding Notification Number, as described in Section 7. Otherwise, delete the attribute-value pair (Token, {Security Context, PIV}). 9. For each decrypted option, check if the option is also present as an Outer option: if it is, discard the Outer. For example: the message contains a Max-Age Inner and a Max-Age Outer option. The Outer Max-Age is discarded. Selander, et al. Expires October 1, 2018 [Page 37] Internet-Draft OSCORE March 2018 10. Add decrypted code, options and payload to the decrypted request. The OSCORE option is removed. 11. The decrypted CoAP response is processed according to [RFC7252]. 12. In case any of the previous erroneous conditions apply: the client SHALL stop processing the response. An error condition occurring while processing a response in an observation does not cancel the observation. A client MUST NOT react to failure in step 7 by re-registering the observation immediately. 9. Web Linking The use of OSCORE MAY be indicated by a target attribute "osc" in a web link [RFC8288] to a resource, e.g. using a link-format document [RFC6690] if the resource is accessible over CoAP. The "osc" attribute is a hint indicating that the destination of that link is only accessible using OSCORE, and unprotected access to it is not supported. Note that this is simply a hint, it does not include any security context material or any other information required to run OSCORE. A value MUST NOT be given for the "osc" attribute; any present value MUST be ignored by parsers. The "osc" attribute MUST NOT appear more than once in a given link-value; occurrences after the first MUST be ignored by parsers. The example in Figure 11 shows a use of the "osc" attribute: the client does resource discovery on a server, and gets back a list of resources, one of which includes the "osc" attribute indicating that the resource is protected with OSCORE. The link-format notation (see Section 5. of [RFC6690]) is used. REQ: GET /.well-known/core RES: 2.05 Content ;osc, ;if="sensor" Figure 11: The web link 10. CoAP-to-CoAP Forwarding Proxy CoAP is designed for proxy operations (see Section 5.7 of [RFC7252]). Security requirements for forwarding are presented in Section 2.2.1 of [I-D.hartke-core-e2e-security-reqs]. Selander, et al. Expires October 1, 2018 [Page 38] Internet-Draft OSCORE March 2018 OSCORE is designed to work with legacy CoAP proxies. Since a CoAP response is only applicable to the original CoAP request, caching is in general not useful. In support of legacy proxies, OSCORE defines special Max-Age processing, see Section 4.1.3.1. An OSCORE-aware proxy SHOULD NOT cache a response to a request with an OSCORE option Proxy processing of the (Outer) Proxy-Uri option is as defined in [RFC7252]. Proxy processing of the (Outer) Block options is as defined in [RFC7959]. Proxy processing of the (Outer) Observe option is as defined in [RFC7641]. OSCORE-aware proxies may look at the Partial IV value instead of the Outer Observe option. 11. HTTP Operations The CoAP request/response model may be mapped to HTTP and vice versa as described in Section 10 of [RFC7252]. The HTTP-CoAP mapping is further detailed in [RFC8075]. This section defines the components needed to map and transport OSCORE messages over HTTP hops. By mapping between HTTP and CoAP and by using cross-protocol proxies OSCORE may be used end-to-end between e.g. an HTTP client and a CoAP server. Examples are provided at the end of the section. 11.1. The HTTP OSCORE Header Field The HTTP OSCORE Header Field (see Section 13.4) is used for carrying the content of the CoAP OSCORE option when transporting OSCORE messages over HTTP hops. The HTTP OSCORE header field is only used in POST requests and 200 (OK) responses. When used, the HTTP header field Content-Type is set to 'application/oscore' (see Section 13.5) indicating that the HTTP body of this message contains the OSCORE payload (see Section 6.2}. No additional semantics is provided by other message fields. Using the Augmented Backus-Naur Form (ABNF) notation of [RFC5234], including the following core ABNF syntax rules defined by that specification: ALPHA (letters) and DIGIT (decimal digits), the HTTP OSCORE header field value is as follows. base64url-char = ALPHA / DIGIT / "-" / "_" OSCORE = 2*base64url-char Selander, et al. Expires October 1, 2018 [Page 39] Internet-Draft OSCORE March 2018 The HTTP OSCORE header field is not appropriate to list in the Connection header field (see Section 6.1 of [RFC7230]) since it is not hop-by-hop. The HTTP OSCORE header field is not appropriate to list in a Vary response header field (see Section 7.1.4 of [RFC7231]) since a cached response would in general not be useful for other clients. The HTTP OSCORE header field is not useful in trailers (see Section 4.1 of [RFC7230]). Intermediaries are in general not allowed to insert, delete, or modify the OSCORE header. Changes to the HTTP OSCORE header field will in general violate the integrity of the OSCORE message resulting in an error. For the same reason the HTTP OSCORE header field is in general not preserved across redirects. A CoAP-to-HTTP proxy receiving a request for redirect may copy the HTTP OSCORE header field to the new request, although the condition for this being successful is that the server to which the OSCORE message is redirected needs to be a clone of the server for which the OSCORE message was intended (same target resource, same OSCORE security context etc.). If an HTTP/OSCORE client receives a redirect it should instead generate a new OSCORE request for the server it was redirected to. 11.2. CoAP-to-HTTP Mapping Section 10.1 of [RFC7252] describes the fundamentals of the CoAP-to- HTTP cross-protocol mapping process. The additional rules for OSCORE messages are: o The HTTP OSCORE header field value is set to * AA if the CoAP OSCORE option is empty, otherwise * the value of the CoAP OSCORE option (Section 6.1) in base64url (Section 5 of [RFC4648]) encoding without padding. Implementation notes for this encoding are given in Appendix C of [RFC7515]. o The HTTP Content-Type is set to 'application/oscore' (see Section 13.5), independent of CoAP Content-Format. 11.3. HTTP-to-CoAP Mapping Section 10.2 of [RFC7252] and [RFC8075] specify the behavior of an HTTP-to-CoAP proxy. The additional rules for HTTP messages with the OSCORE header field are: o The CoAP OSCORE option is set as follows: Selander, et al. Expires October 1, 2018 [Page 40] Internet-Draft OSCORE March 2018 * empty if the value of the HTTP OSCORE header field is a single zero byte (0x00) represented by AA, otherwise * the value of the HTTP OSCORE header field decoded from base64url (Section 5 of [RFC4648]) without padding. Implementation notes for this encoding are given in Appendix C of [RFC7515]. o The CoAP Content-Format option is omitted, the content format for OSCORE (Section 13.6) MUST NOT be used. 11.4. HTTP Endpoints Restricted to subsets of HTTP and CoAP supporting a bijective mapping, OSCORE can be originated or terminated in HTTP endpoints. The sending HTTP endpoint uses [RFC8075] to translate the HTTP message into a CoAP message. The CoAP message is then processed with OSCORE as defined in this document. The OSCORE message is then mapped to HTTP as described in Section 11.2 and sent in compliance with the rules in Section 11.1. The receiving HTTP endpoint maps the HTTP message to a CoAP message using [RFC8075] and Section 11.3. The resulting OSCORE message is processed as defined in this document. If successful, the plaintext CoAP message is translated to HTTP for normal processing in the endpoint. 11.5. Example: HTTP Client and CoAP Server This section is giving an example of how a request and a response between an HTTP client and a CoAP server could look like. The example is not a test vector but intended as an illustration of how the message fields are translated in the different steps. Mapping and notation here is based on "Simple Form" (Section 5.4.1 of [RFC8075]). [HTTP request -- Before client object security processing] GET http://proxy.url/hc/?target_uri=coap://server.url/orders HTTP/1.1 Selander, et al. Expires October 1, 2018 [Page 41] Internet-Draft OSCORE March 2018 [HTTP request -- HTTP Client to Proxy] POST http://proxy.url/hc/?target_uri=coap://server.url/ HTTP/1.1 Content-Type: application/oscore OSCORE: CSU Body: 09 07 01 13 61 f7 0f d2 97 b1 [binary] [CoAP request -- Proxy to CoAP Server] POST coap://server.url/ OSCORE: 09 25 Payload: 09 07 01 13 61 f7 0f d2 97 b1 [binary] [CoAP request -- After server object security processing] GET coap://server.url/orders [CoAP response -- Before server object security processing] 2.05 Content Content-Format: 0 Payload: Exterminate! Exterminate! [CoAP response -- CoAP Server to Proxy] 2.04 Changed OSCORE: [empty] Payload: 00 31 d1 fc f6 70 fb 0c 1d d5 ... [binary] [HTTP response -- Proxy to HTTP Client] HTTP/1.1 200 OK Content-Type: application/oscore OSCORE: AA Body: 00 31 d1 fc f6 70 fb 0c 1d d5 ... [binary] [HTTP response -- After client object security processing] HTTP/1.1 200 OK Content-Type: text/plain Body: Exterminate! Exterminate! Note that the HTTP Status Code 200 in the next-to-last message is the mapping of CoAP Code 2.04 (Changed), whereas the HTTP Status Code 200 in the last message is the mapping of the CoAP Code 2.05 (Content), which was encrypted within the compressed COSE object carried in the Body of the HTTP response. Selander, et al. Expires October 1, 2018 [Page 42] Internet-Draft OSCORE March 2018 11.6. Example: CoAP Client and HTTP Server This section is giving an example of how a request and a response between a CoAP client and an HTTP server could look like. The example is not a test vector but intended as an illustration of how the message fields are translated in the different steps [CoAP request -- Before client object security processing] GET coap://proxy.url/ Proxy-Uri=http://server.url/orders [CoAP request -- CoAP Client to Proxy] POST coap://proxy.url/ Proxy-Uri=http://server.url/ OSCORE: 09 25 Payload: 09 07 01 13 61 f7 0f d2 97 b1 [binary] [HTTP request -- Proxy to HTTP Server] POST http://server.url/ HTTP/1.1 Content-Type: application/oscore OSCORE: CSU Body: 09 07 01 13 61 f7 0f d2 97 b1 [binary] [HTTP request -- After server object security processing] GET http://server.url/orders HTTP/1.1 [HTTP response -- Before server object security processing] HTTP/1.1 200 OK Content-Type: text/plain Body: Exterminate! Exterminate! [HTTP response -- HTTP Server to Proxy] HTTP/1.1 200 OK Content-Type: application/oscore OSCORE: AA Body: 00 31 d1 fc f6 70 fb 0c 1d d5 ... [binary] [CoAP response -- Proxy to CoAP Client] 2.04 Changed OSCORE: [empty] Payload: 00 31 d1 fc f6 70 fb 0c 1d d5 ... [binary] Selander, et al. Expires October 1, 2018 [Page 43] Internet-Draft OSCORE March 2018 [CoAP response -- After client object security processing] 2.05 Content Content-Format: 0 Payload: Exterminate! Exterminate! Note that the HTTP Code 2.04 (Changed) in the next-to-last message is the mapping of HTTP Status Code 200, whereas the CoAP Code 2.05 (Content) in the last message is the value that was encrypted within the compressed COSE object carried in the Body of the HTTP response. 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 HTTP, the additional TLS protection of HTTP hops is recommended, e.g. between an HTTP endpoint and a proxy translating between HTTP and CoAP. The consequences of unprotected message fields are analyzed in Appendix D.4. 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. It may still be favorable to send an unprotected error message, e.g. to prevent extensive retransmissions, so unprotected error messages are allowed as specified. Similar to error messages, signaling messages are not always possible to protect as they may be intended for an Selander, et al. Expires October 1, 2018 [Page 44] Internet-Draft OSCORE March 2018 intermediary. Applications using unprotected error and signaling messages need to consider the threat that these messages may be spoofed. 12.2. Security Context Establishment 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]. This procedure must ensure that the requirements of the security context parameters are complied with Section 3.3 for the intended use and also in error situations. It is recommended to use a key establishment protocol which provides forward secrecy whenever possible. Considerations for the 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]. 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. 12.4. Replay Protection 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 Selander, et al. Expires October 1, 2018 [Page 45] Internet-Draft OSCORE March 2018 synchronization is avoided. With reliable transport, it may be defined that only messages with sequence number which are equal to previous sequence number + 1 are accepted. The alternatives to sequence numbers have their issues: very constrained devices may not be able to support accurate time, or to generate and store large numbers of random nonces. The requirement to change key at counter wrap is a complication, but it also forces the user of this specification to think about implementing key renewal. 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)). 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 Selander, et al. Expires October 1, 2018 [Page 46] Internet-Draft OSCORE March 2018 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. 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. 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 Note to RFC Editor: Please replace all occurrences of "[[this document]]" with the RFC number of this specification. Note to IANA: Please note all occurrences of "TBDx" in this specification should be assigned the same number. 13.1. COSE Header Parameters Registry The 'kid context' parameter is added to the "COSE Header Parameters Registry": Selander, et al. Expires October 1, 2018 [Page 47] Internet-Draft OSCORE March 2018 o Name: kid context o Label: TBD2 o Value Type: bstr o Value Registry: o Description: Identifies the kid context o Reference: Section 5.1 of this document Note to IANA: Label assignment in (Integer value between 1 and 255) is requested. (RFC Editor: Delete this note after IANA assignment) 13.2. CoAP Option Numbers Registry The OSCORE option is added to the CoAP Option Numbers registry: +--------+-----------------+-------------------+ | Number | Name | Reference | +--------+-----------------+-------------------+ | TBD1 | OSCORE | [[this document]] | +--------+-----------------+-------------------+ 13.3. CoAP Signaling Option Numbers Registry The OSCORE option is added to the CoAP Signaling Option Numbers registry: +------------+--------+---------------------+-------------------+ | Applies to | Number | Name | Reference | +------------+--------+---------------------+-------------------+ | 7.xx (any) | TBD1 | OSCORE | [[this document]] | +------------+--------+---------------------+-------------------+ 13.4. Header Field Registrations The HTTP OSCORE header field is added to the Message Headers registry: +----------------------+----------+----------+-------------------+ | Header Field Name | Protocol | Status | Reference | +----------------------+----------+----------+-------------------+ | OSCORE | http | standard | [[this document]] | +----------------------+----------+----------+-------------------+ Selander, et al. Expires October 1, 2018 [Page 48] Internet-Draft OSCORE March 2018 13.5. Media Type Registrations This section registers the 'application/oscore' media type in the "Media Types" registry. These media types are used to indicate that the content is an OSCORE message. The OSCORE body cannot be understood without the OSCORE header field value and the security context. Selander, et al. Expires October 1, 2018 [Page 49] Internet-Draft OSCORE March 2018 Type name: application Subtype name: oscore Required parameters: N/A Optional parameters: N/A Encoding considerations: binary Security considerations: See the Security Considerations section of [[This document]]. Interoperability considerations: N/A Published specification: [[This document]] Applications that use this media type: IoT applications sending security content over HTTP(S) transports. Fragment identifier considerations: N/A Additional information: * Deprecated alias names for this type: N/A * Magic number(s): N/A * File extension(s): N/A * Macintosh file type code(s): N/A Person & email address to contact for further information: iesg@ietf.org Intended usage: COMMON Restrictions on usage: N/A Author: Goeran Selander, goran.selander@ericsson.com Change Controller: IESG Provisional registration? No Selander, et al. Expires October 1, 2018 [Page 50] Internet-Draft OSCORE March 2018 13.6. CoAP Content-Formats Registry Note to IANA: ID assignment in the 10000-64999 range is requested. (RFC Editor: Delete this note after IANA assignment) This section registers the media type 'application/oscore' media type in the "CoAP Content-Format" registry. This Content-Format for the OSCORE payload is defined for potential future use cases and SHALL NOT be used in the OSCORE message. The OSCORE payload cannot be understood without the OSCORE option value and the security context. +----------------------+----------+----------+-------------------+ | Media Type | Encoding | ID | Reference | +----------------------+----------+----------+-------------------+ | application/oscore | | TBD3 | [[this document]] | +----------------------+----------+----------+-------------------+ 14. References 14.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, . [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, . [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, . [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, January 2012, . [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, October 2013, . Selander, et al. Expires October 1, 2018 [Page 51] Internet-Draft OSCORE March 2018 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", RFC 7230, DOI 10.17487/RFC7230, June 2014, . [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content", RFC 7231, DOI 10.17487/RFC7231, June 2014, . [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained Application Protocol (CoAP)", RFC 7252, DOI 10.17487/RFC7252, June 2014, . [RFC7641] Hartke, K., "Observing Resources in the Constrained Application Protocol (CoAP)", RFC 7641, DOI 10.17487/RFC7641, September 2015, . [RFC7959] Bormann, C. and Z. Shelby, Ed., "Block-Wise Transfers in the Constrained Application Protocol (CoAP)", RFC 7959, DOI 10.17487/RFC7959, August 2016, . [RFC8075] Castellani, A., Loreto, S., Rahman, A., Fossati, T., and E. Dijk, "Guidelines for Mapping Implementations: HTTP to the Constrained Application Protocol (CoAP)", RFC 8075, DOI 10.17487/RFC8075, February 2017, . [RFC8132] van der Stok, P., Bormann, C., and A. Sehgal, "PATCH and FETCH Methods for the Constrained Application Protocol (CoAP)", RFC 8132, DOI 10.17487/RFC8132, April 2017, . [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", RFC 8152, DOI 10.17487/RFC8152, July 2017, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8288] Nottingham, M., "Web Linking", RFC 8288, DOI 10.17487/RFC8288, October 2017, . Selander, et al. Expires October 1, 2018 [Page 52] Internet-Draft OSCORE March 2018 [RFC8323] Bormann, C., Lemay, S., Tschofenig, H., Hartke, K., Silverajan, B., and B. Raymor, Ed., "CoAP (Constrained Application Protocol) over TCP, TLS, and WebSockets", RFC 8323, DOI 10.17487/RFC8323, February 2018, . 14.2. Informative References [I-D.bormann-6lo-coap-802-15-ie] Bormann, C., "Constrained Application Protocol (CoAP) over IEEE 802.15.4 Information Element for IETF", draft- bormann-6lo-coap-802-15-ie-00 (work in progress), April 2016. [I-D.hartke-core-e2e-security-reqs] Selander, G., Palombini, F., and K. Hartke, "Requirements for CoAP End-To-End Security", draft-hartke-core-e2e- security-reqs-03 (work in progress), July 2017. [I-D.ietf-6tisch-minimal-security] Vucinic, M., Simon, J., Pister, K., and M. Richardson, "Minimal Security Framework for 6TiSCH", draft-ietf- 6tisch-minimal-security-05 (work in progress), March 2018. [I-D.ietf-ace-oauth-authz] Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and H. Tschofenig, "Authentication and Authorization for Constrained Environments (ACE) using the OAuth 2.0 Framework (ACE-OAuth)", draft-ietf-ace-oauth-authz-11 (work in progress), March 2018. [I-D.ietf-ace-oscore-profile] Seitz, L., Palombini, F., Gunnarsson, M., and G. Selander, "OSCORE profile of the Authentication and Authorization for Constrained Environments Framework", draft-ietf-ace- oscore-profile-01 (work in progress), March 2018. [I-D.ietf-cbor-cddl] Birkholz, H., Vigano, C., and C. Bormann, "Concise data definition language (CDDL): a notational convention to express CBOR data structures", draft-ietf-cbor-cddl-02 (work in progress), February 2018. [I-D.ietf-core-echo-request-tag] Amsuess, C., Mattsson, J., and G. Selander, "Echo and Request-Tag", draft-ietf-core-echo-request-tag-01 (work in progress), March 2018. Selander, et al. Expires October 1, 2018 [Page 53] Internet-Draft OSCORE March 2018 [I-D.ietf-core-oscore-groupcomm] Tiloca, M., Selander, G., Palombini, F., and J. Park, "Secure group communication for CoAP", draft-ietf-core- oscore-groupcomm-01 (work in progress), March 2018. [I-D.mattsson-core-coap-actuators] Mattsson, J., Fornehed, J., Selander, G., Palombini, F., and C. Amsuess, "Controlling Actuators with CoAP", draft- mattsson-core-coap-actuators-05 (work in progress), March 2018. [MF00] McGrew, D. and S. Fluhrer, "Attacks on Encryption of Redundant Plaintext and Implications on Internet Security", the Proceedings of the Seventh Annual Workshop on Selected Areas in Cryptography (SAC 2000), Springer- Verlag. , 2000. [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, . [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008, . [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand Key Derivation Function (HKDF)", RFC 5869, DOI 10.17487/RFC5869, May 2010, . [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link Format", RFC 6690, DOI 10.17487/RFC6690, August 2012, . [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for Constrained-Node Networks", RFC 7228, DOI 10.17487/RFC7228, May 2014, . [RFC7390] Rahman, A., Ed. and E. Dijk, Ed., "Group Communication for the Constrained Application Protocol (CoAP)", RFC 7390, DOI 10.17487/RFC7390, October 2014, . [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 2015, . Selander, et al. Expires October 1, 2018 [Page 54] Internet-Draft OSCORE March 2018 [RFC7967] Bhattacharyya, A., Bandyopadhyay, S., Pal, A., and T. Bose, "Constrained Application Protocol (CoAP) Option for No Server Response", RFC 7967, DOI 10.17487/RFC7967, August 2016, . Appendix A. Scenario Examples This section gives examples of OSCORE, targeting scenarios in Section 2.2.1.1 of [I-D.hartke-core-e2e-security-reqs]. The message exchanges are made, based on the assumption that there is a security context established between client and server. For simplicity, these examples only indicate the content of the messages without going into detail of the (compressed) COSE message format. A.1. Secure Access to Sensor This example illustrates a client requesting the alarm status from a server. Client Proxy Server | | | +------>| | Code: 0.02 (POST) | POST | | Token: 0x8c | | | OSCORE: [kid:5f,Partial IV:42] | | | Payload: {Code:0.01, | | | Uri-Path:"alarm_status"} | | | | +------>| Code: 0.02 (POST) | | POST | Token: 0x7b | | | OSCORE: [kid:5f,Partial IV:42] | | | Payload: {Code:0.01, | | | Uri-Path:"alarm_status"} | | | | |<------+ Code: 2.04 (Changed) | | 2.04 | Token: 0x7b | | | OSCORE: - | | | Payload: {Code:2.05, "OFF"} | | | |<------+ | Code: 2.04 (Changed) | 2.04 | | Token: 0x8c | | | OSCORE: - | | | Payload: {Code:2.05, "OFF"} | | | Figure 12: Secure Access to Sensor. Square brackets [ ... ] indicate content of compressed COSE object. Curly brackets { ... } indicate encrypted data. Selander, et al. Expires October 1, 2018 [Page 55] Internet-Draft OSCORE March 2018 The request/response Codes are encrypted by OSCORE and only dummy Codes (POST/Changed) are visible in the header of the OSCORE message. The option Uri-Path ("alarm_status") and payload ("OFF") are encrypted. The COSE header of the request contains an identifier (5f), indicating which security context was used to protect the message and a Partial IV (42). The server verifies the request as specified in Section 8.2. The client verifies the response as specified in Section 8.4. A.2. Secure Subscribe to Sensor This example illustrates a client requesting subscription to a blood sugar measurement resource (GET /glucose), first receiving the value 220 mg/dl and then a second value 180 mg/dl. Client Proxy Server | | | +------>| | Code: 0.05 (FETCH) | FETCH | | Token: 0x83 | | | Observe: 0 | | | OSCORE: [kid:ca,Partial IV:15] | | | Payload: {Code:0.01, | | | Uri-Path:"glucose"} | | | | +------>| Code: 0.05 (FETCH) | | FETCH | Token: 0xbe | | | Observe: 0 | | | OSCORE: [kid:ca,Partial IV:15] | | | Payload: {Code:0.01, | | | Uri-Path:"glucose"} | | | | |<------+ Code: 2.05 (Content) | | 2.05 | Token: 0xbe | | | Observe: 7 | | | OSCORE: [Partial IV:32] | | | Payload: {Code:2.05, | | | Content-Format:0, "220"} | | | |<------+ | Code: 2.05 (Content) | 2.05 | | Token: 0x83 | | | Observe: 7 | | | OSCORE: [Partial IV:32] | | | Payload: {Code:2.05, | | | Content-Format:0, "220"} ... ... ... Selander, et al. Expires October 1, 2018 [Page 56] Internet-Draft OSCORE March 2018 | | | | |<------+ Code: 2.05 (Content) | | 2.05 | Token: 0xbe | | | Observe: 8 | | | OSCORE: [Partial IV:36] | | | Payload: {Code:2.05, | | | Content-Format:0, "180"} | | | |<------+ | Code: 2.05 (Content) | 2.05 | | Token: 0x83 | | | Observe: 8 | | | OSCORE: [Partial IV:36] | | | Payload: {Code:2.05, | | | Content-Format:0, "180"} | | | Figure 13: Secure Subscribe to Sensor. Square brackets [ ... ] indicate content of compressed COSE object header. Curly brackets { ... } indicate encrypted data. The dummy Codes (FETCH/Content) are visible in the header of the OSCORE message to allow intermediary processing of Observe. The options Content-Format (0) and the payload ("220" and "180"), are encrypted. The COSE header of the request contains an identifier (ca), indicating the security context used to protect the message and a Partial IV (15). The COSE headers of the responses contains Partial IVs (32 and 36). The server verifies that the Partial IV has not been received before. The client verifies that the responses are bound to the request and that the Partial IVs are greater than any Partial IV previously received in a response bound to the request. Appendix B. Deployment Examples Two examples complying with the requirements on the security context parameters (Section 3.3) are given in this section. B.1. Master Secret Used Once For settings where the Master Secret is only used during deployment, the uniqueness of the AEAD nonce may be assured by persistent storage of the security context as described in this specification (see Section 7.5). For many IoT deployments, a 128 bit uniformly random Master Key is sufficient for encrypting all data exchanged with the IoT device throughout its lifetime. Selander, et al. Expires October 1, 2018 [Page 57] Internet-Draft OSCORE March 2018 B.2. Master Secret Used Multiple Times One Master Secret can be used to derive multiple security contexts if unique Master Salts can be guaranteed. This may be useful e.g. in case of recommissioning with reused Master Secret. In order to prevent reuse of AEAD nonce and key, which would compromise the security, the Master Salt must never be used twice, even if the device is reset, recommissioned or in error cases. Examples of failures include derivation of pseudorandom master salt from a static seed, or a deterministic seeding procedure with inputs that are repeated or can be replayed. Techniques for persistent storage of security state may be used also in this case, to ensure uniqueness of Master Salt. Assuming the Master Salts are indeed unique (or stochastically unique) we give an example of a procedure which may be implemented in client and server to establish the OSCORE security context based on pre-established input parameters (see Section 3.2) except for the Master Salt, which is transported in kid context parameter (see Section 5.1) of the request. 1. In order to establish a security context with a server for the first time, or a new security context replacing an old security context, the client generates a (pseudo-)random uniformly distributed 64-bit Master Salt and derives the security context as specified in Section 3.2. The client protects a request with the new Sender Context and sends the message with kid context set to the Master Salt. 2. The server, receiving an OSCORE request with a non-empty kid context derives the new security context using the received kid context as Master Salt. The server processes the request as specified in this document using the new Recipient Context. If the processing of the request completes without error, the server responds with an Echo option as specified in [I-D.ietf-core-echo-request-tag]. The response is protected with the new Sender Context. 3. The client, receiving a response with an Echo option to a request which used a new security context, verifies the response using the new Recipient Context, and if valid repeats the request with the Echo option (see [I-D.ietf-core-echo-request-tag]) using the new Sender Context. Subsequent message exchanges (unless superseded) are processed using the new security context without including the Master Salt in the kid context. 4. The server, receiving a request with a kid context and a valid Echo option (see [I-D.ietf-core-echo-request-tag]), repeats the Selander, et al. Expires October 1, 2018 [Page 58] Internet-Draft OSCORE March 2018 processing described in step 2. If it completes without error, then the new security context is established, and the request is valid. If the server already had an old security context with this client that is now replaced by the new security context. If the server receives a request without kid context from a client with which no security context is established, then the server responds with a 4.01 Unauthorized error message with diagnostic payload containing the string "Security context not found". This could be the result of the server having lost its security context or that a new security context has not been successfully established, which may be a trigger for the client to run this procedure. Appendix C. Test Vectors This appendix includes the test vectors for different examples of CoAP messages using OSCORE. C.1. Test Vector 1: Key Derivation with Master Salt Given a set of inputs, OSCORE defines how to set up the Security Context in both the client and the server. The default values are used for AEAD Algorithm and KDF. C.1.1. Client Inputs: o Master Secret: 0x0102030405060708090a0b0c0d0e0f10 (16 bytes) o Master Salt: 0x9e7ca92223786340 (8 bytes) o Sender ID: 0x (0 byte) o Recipient ID: 0x01 (1 byte) From the previous parameters, o info (for Sender Key): 0x84400A634b657910 (8 bytes) o info (for Recipient Key): 0x8441010A634b657910 (9 bytes) o info (for Common IV): 0x84400a6249560d (7 bytes) Outputs: o Sender Key: 0x7230aab3b549d94c9224aacc744e93ab (16 bytes) Selander, et al. Expires October 1, 2018 [Page 59] Internet-Draft OSCORE March 2018 o Recipient Key: 0xe534a26a64aa3982e988e31f1e401e65 (16 bytes) o Common IV: 0x01727733ab49ead385b18f7d91 (13 bytes) C.1.2. Server Inputs: o Master Secret: 0x0102030405060708090a0b0c0d0e0f10 (16 bytes) o Master Salt: 0x9e7ca92223786340 (64 bytes) o Sender ID: 0x01 (1 byte) o Recipient ID: 0x (0 byte) From the previous parameters, o info (for Sender Key): 0x8441010A634b657910 (9 bytes) o info (for Recipient Key): 0x84400A634b657910 (8 bytes) o info (for Common IV): 0x84400a6249560d (7 bytes) Outputs: o Sender Key: 0xe534a26a64aa3982e988e31f1e401e65 (16 bytes) o Recipient Key: 0x7230aab3b549d94c9224aacc744e93ab (16 bytes) o Common IV: 0x01727733ab49ead385b18f7d91 (13 bytes) C.2. Test Vector 2: Key Derivation without Master Salt Given a set of inputs, OSCORE defines how to set up the Security Context in both the client and the server. The default values are used for AEAD Algorithm, KDF, and Master Salt. C.2.1. Client Inputs: o Master Secret: 0x0102030405060708090a0b0c0d0e0f10 (16 bytes) o Sender ID: 0x00 (1 byte) o Recipient ID: 0x01 (1 byte) Selander, et al. Expires October 1, 2018 [Page 60] Internet-Draft OSCORE March 2018 From the previous parameters, o info (for Sender Key): 0x8441000A634b657910 (9 bytes) o info (for Recipient Key): 0x8441010A634b657910 (9 bytes) o info (for Common IV): 0x84400a6249560d (7 bytes) Outputs: o Sender Key: 0xf8f3b887436285ed5a66f6026ac2cdc1 (16 bytes) o Recipient Key: 0xd904cb101f7341c3f4c56c300fa69941 (16 bytes) o Common IV: 0xd1a1949aa253278f34c528d2cc (13 bytes) C.2.2. Server Inputs: o Master Secret: 0x0102030405060708090a0b0c0d0e0f10 (16 bytes) o Sender ID: 0x01 (1 byte) o Recipient ID: 0x00 (1 byte) From the previous parameters, o info (for Sender Key): 0x8441010A634b657910 (9 bytes) o info (for Recipient Key): 0x8441000A634b657910 (9 bytes) o info (for Common IV): 0x84400a6249560d (7 bytes) Outputs: o Sender Key: 0xd904cb101f7341c3f4c56c300fa69941 (16 bytes) o Recipient Key: 0xf8f3b887436285ed5a66f6026ac2cdc1 (16 bytes) o Common IV: 0xd1a1949aa253278f34c528d2cc (13 bytes) C.3. Test Vector 3: OSCORE Request, Client This section contains a test vector for an OSCORE protected CoAP GET request using the security context derived in Appendix C.1. The unprotected request only contains the Uri-Path option. Selander, et al. Expires October 1, 2018 [Page 61] Internet-Draft OSCORE March 2018 Unprotected CoAP request: 0x440149c60000f2a7396c6f63616c686f737483747631 (22 bytes) Common Context: o AEAD Algorithm: 10 (AES-CCM-16-64-128) o Key Derivation Function: HKDF SHA-256 o Common IV: 0xd1a1949aa253278f34c528d2cc (13 bytes) Sender Context: o Sender ID: 0x00 (1 byte) o Sender Key: 0xf8f3b887436285ed5a66f6026ac2cdc1 (16 bytes) o Sender Sequence Number: 20 The following COSE and cryptographic parameters are derived: o Partial IV: 0x14 (1 byte) o kid: 0x00 (1 byte) o external_aad: 0x8501810a4100411440 (9 bytes) o AAD: 0x8368456e63727970743040498501810a4100411440 (21 bytes) o plaintext: 0x01b3747631 (5 bytes) o encryption key: 0xf8f3b887436285ed5a66f6026ac2cdc1 (16 bytes) o nonce: 0xd0a1949aa253278f34c528d2d8 (13 bytes) From the previous parameter, the following is derived: o OSCORE option value: 0x091400 (3 bytes) o ciphertext: 0x55b3710d47c611cd3924838a44 (13 bytes) From there: o Protected CoAP request (OSCORE message): 0x44026dd30000acc5396c6f6 3616c686f7374d305091400ff55b3710d47c611cd3924838a44 (37 bytes) Selander, et al. Expires October 1, 2018 [Page 62] Internet-Draft OSCORE March 2018 C.4. Test Vector 4: OSCORE Request, Client This section contains a test vector for an OSCORE protected CoAP GET request using the security context derived in Appendix C.2. The unprotected request only contains the Uri-Path option. Unprotected CoAP request: 0x440149c60000f2a7396c6f63616c686f737483747631 (22 bytes) Common Context: o AEAD Algorithm: 10 (AES-CCM-16-64-128) o Key Derivation Function: HKDF SHA-256 o Common IV: 0x01727733ab49ead385b18f7d91 (13 bytes) Sender Context: o Sender ID: 0x (0 bytes) o Sender Key: 0x7230aab3b549d94c9224aacc744e93ab (16 bytes) o Sender Sequence Number: 20 The following COSE and cryptographic parameters are derived: o Partial IV: 0x14 (1 byte) o kid: 0x (0 byte) o external_aad: 0x8501810a40411440 (8 bytes) o AAD: 0x8368456e63727970743040488501810a40411440 (20 bytes) o plaintext: 0x01b3747631 (5 bytes) o encryption key: 0x7230aab3b549d94c9224aacc744e93ab (16 bytes) o nonce: 0x01727733ab49ead385b18f7d85 (13 bytes) From the previous parameter, the following is derived: o OSCORE option value: 0x0914 (2 bytes) o ciphertext: 0x6be9214aad448260ff1be1f594 (13 bytes) From there: Selander, et al. Expires October 1, 2018 [Page 63] Internet-Draft OSCORE March 2018 o Protected CoAP request (OSCORE message): 0x44023bfc000066ef396c6f6 3616c686f7374d2050914ff6be9214aad448260ff1be1f594 (36 bytes) C.5. Test Vector 5: OSCORE Response, Server This section contains a test vector for an OSCORE protected 2.05 Content response to the request in Appendix C.3. The unprotected response has payload "Hello World!" and no options. The protected response does not contain a kid nor a Partial IV. Note that some parameters are derived from the request. Unprotected CoAP response: 0x644549c60000f2a7ff48656c6c6f20576f726c6421 (21 bytes) Common Context: o AEAD Algorithm: 10 (AES-CCM-16-64-128) o Key Derivation Function: HKDF SHA-256 o Common IV: 0xd1a1949aa253278f34c528d2cc (13 bytes) Sender Context: o Sender ID: 0x01 (1 byte) o Sender Key: 0xd904cb101f7341c3f4c56c300fa69941 (16 bytes) o Sender Sequence Number: 0 The following COSE and cryptographic parameters are derived: o external_aad: 0x8501810a4100411440 (9 bytes) o AAD: 0x8368456e63727970743040498501810a4100411440 (21 bytes) o plaintext: 0x45ff48656c6c6f20576f726c6421 (14 bytes) o encryption key: 0xd904cb101f7341c3f4c56c300fa69941 (16 bytes) o nonce: 0xd0a1949aa253278f34c528d2d8 (13 bytes) From the previous parameter, the following is derived: o OSCORE option value: 0x (0 bytes) o ciphertext: 0xe4e8c28c41c8f31ca56eec24f6c71d94eacbcdffdc6d (22 bytes) Selander, et al. Expires October 1, 2018 [Page 64] Internet-Draft OSCORE March 2018 From there: o Protected CoAP response (OSCORE message): 0x64446dd30000acc5d008ff e4e8c28c41c8f31ca56eec24f6c71d94eacbcdffdc6d (33 bytes) C.6. Test Vector 6: OSCORE Response with Partial IV, Server This section contains a test vector for an OSCORE protected 2.05 Content response to the request in Appendix C.3. The unprotected response has payload "Hello World!" and no options. The protected response does not contain a kid, but contains a Partial IV. Note that some parameters are derived from the request. Unprotected CoAP response: 0x644549c60000f2a7ff48656c6c6f20576f726c6421 (21 bytes) Common Context: o AEAD Algorithm: 10 (AES-CCM-16-64-128) o Key Derivation Function: HKDF SHA-256 o Common IV: 0xd1a1949aa253278f34c528d2cc (13 bytes) Sender Context: o Sender ID: 0x01 (1 byte) o Sender Key: 0xd904cb101f7341c3f4c56c300fa69941 (16 bytes) o Sender Sequence Number: 0 The following COSE and cryptographic parameters are derived: o Partial IV: 0x00 (1 byte) o external_aad: 0x8501810a4100411440 (9 bytes) o AAD: 0x8368456e63727970743040498501810a4100411440 (21 bytes) o plaintext: 0x45ff48656c6c6f20576f726c6421 (14 bytes) o encryption key: 0xd904cb101f7341c3f4c56c300fa69941 (16 bytes) o nonce: 0xd0a1949aa253278e34c528d2cc (13 bytes) From the previous parameter, the following is derived: Selander, et al. Expires October 1, 2018 [Page 65] Internet-Draft OSCORE March 2018 o OSCORE option value: 0x0100 (2 bytes) o ciphertext: 0xa7e3ca27f221f453c0ba68c350bf652ea096b328a1bf (22 bytes) From there: o Protected CoAP response (OSCORE message): 0x64442b130000b29ed20801 00ffa7e3ca27f221f453c0ba68c350bf652ea096b328a1bf (35 bytes) 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 and performing 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. 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. 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 using an AEAD algorithm. Selander, et al. Expires October 1, 2018 [Page 66] Internet-Draft OSCORE March 2018 OSCORE depends on a pre-established random Master Secret (Section 12.3) which can be used to derive 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, 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 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 already 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 Section 3.3 and Section 7.2 are followed. Fix a security context and an endpoint, called the encrypting endpoint. Endpoints may alternate between client and server roles, but each endpoint encrypts with the Sender Key of its Sender Context. Sender Keys are (stochastically) unique since they are derived with HKDF from unique Sender IDs, so messages encrypted by different Selander, et al. Expires October 1, 2018 [Page 67] Internet-Draft OSCORE March 2018 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. 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 are all unique as long as the number of encrypted messages is kept within the required range (Section 7.2). For responses without Partial IV (i.e. 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 nonce is different compared to nonces 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. The argumentation also holds for group communication as specified in [RFC7390] (see [I-D.ietf-core-oscore-groupcomm]). D.4. Unprotected Message Fields This section lists and discusses issues with unprotected message fields. D.4.1. CoAP Code The CoAP Code of an OSCORE message is POST or FETCH for requests and with corresponding response codes. Since the use of Observe is indicated with the Outer Observe option, no additional information is revealed by having a special codes for Observe messages. A change of code does not affect the method of the end-to-end message but may be Selander, et al. Expires October 1, 2018 [Page 68] Internet-Draft OSCORE March 2018 a denial service attack caused by error in the OSCORE processing. Other aspects of Observe are discussed in Appendix D.4.3. D.4.2. 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. 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 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 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, and does not impact the request/response message. A change of these fields in a UDP hop is a denial of service attack similar to changing UDP header fields. 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.3. 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/Uri-Host/Uri-Port. With OSCORE, the Proxy- Uri option does not contain the Uri-Path/Uri-Query parts of the URI. Proxy-Uri/Proxy-Scheme/Uri-Host/Uri-Port cannot be integrity protected since they are allowed to be changed by a forward proxy. Selander, et al. Expires October 1, 2018 [Page 69] Internet-Draft OSCORE March 2018 Depending on content, the Uri-Host may either reveal information equivalent to that of the IP address or more privacy-sensitive information, which is discouraged in Section 4.1.3.2. o Observe. The Outer Observe option is intended for an OSCORE- unaware proxy to support forwarding of Observe messages. Removing this option in the request turns the notification request into a normal request, which is allowed for a proxy and server and understood by the client but changes the performed operation from a request for notifications to a plain request, but the client cannot tell what party removed the option. Removing this option in the response may lead to notifications not being forwarded or cause a denial of service. The Outer option value indicates a relative order of notifications as read and written by the proxy and a change of that may affect proxy operations and potentially lead to denial of service. Since OSCORE provides absolute ordering of notifications it is not possible for an intermediary to spoof reordering (see Section 4.1.3.4). The size and distributions of notifications over time may reveal information about the content or nature of the notifications. 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 MAX_UNFRAGMENTED_SIZE (Section 4.1.3.3.2), at which the 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. o OSCORE. The OSCORE option contains information about the compressed COSE header. A change of this field may result in not being able to verify the OSCORE message. Selander, et al. Expires October 1, 2018 [Page 70] Internet-Draft OSCORE March 2018 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 Data structure definitions in the present specification employ the CDDL language for conciseness and precision. CDDL is defined in [I-D.ietf-cbor-cddl], which at the time of writing this appendix is in the process of completion. As the document is not yet available for a normative reference, the present appendix defines the small subset of CDDL that is being 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: "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. Selander, et al. Expires October 1, 2018 [Page 71] Internet-Draft OSCORE March 2018 Acknowledgments The following individuals provided input to this document: Christian Amsuess, Tobias Andersson, Carsten Bormann, Joakim Brorsson, Esko Dijk, Thomas Fossati, Martin Gunnarsson, Klaus Hartke, Jim Schaad, Peter van der Stok, Dave Thaler, 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. 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 SICS Email: ludwig.seitz@ri.se Selander, et al. Expires October 1, 2018 [Page 72]