ACE Working Group G. Selander Internet-Draft J. Mattsson Intended Status: Standards Track Ericsson Expires: April 30, 2015 L. Seitz SICS Swedish ICT October 27, 2014 Object Security for CoAP draft-selander-ace-object-security-00 Abstract We present a format for data object security in Constrained Application Protocol CoAP, i.e. protection of individual request and response messages between client and server. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. 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". The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Copyright and License Notice Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents Selander, et al. Expires April 30, 2015 [Page 1] INTERNET DRAFT Object Security for ACE October 27, 2014 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. The JWS Option . . . . . . . . . . . . . . . . . . . . . . . . 6 3.1 Option Structure . . . . . . . . . . . . . . . . . . . . . . 6 3.2 Integrity Protection and Verification . . . . . . . . . . . 7 3.3 JOSE Header . . . . . . . . . . . . . . . . . . . . . . . . 7 3.3.1 "seq" (Sequence Number) Header Parameter . . . . . . . . 8 3.3.2 Message Sequence Numbers . . . . . . . . . . . . . . . . 8 3.4 JWS Payload . . . . . . . . . . . . . . . . . . . . . . . . 9 4. Proxy Behavior . . . . . . . . . . . . . . . . . . . . . . . . 10 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 5.1 GET . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 5.2 POST . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 13 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 14 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 9.1 Normative References . . . . . . . . . . . . . . . . . . . 14 9.2 Informative References . . . . . . . . . . . . . . . . . . 15 Appendix A. Design Considerations . . . . . . . . . . . . . . . . 16 A.1 Reducing Message Size . . . . . . . . . . . . . . . . . . . 16 A.2 REST Considerations . . . . . . . . . . . . . . . . . . . . 17 A.3 Protection of CoAP Message Fields . . . . . . . . . . . . . 17 A.3.1 CoAP Header . . . . . . . . . . . . . . . . . . . . . . 18 A.3.2 CoAP Options . . . . . . . . . . . . . . . . . . . . . . 18 Appendix B. Replay Protection - Special Cases . . . . . . . . . . 20 B.1 "isi" (Integrity Scope Indication) Header Parameter . . . . 21 B.1.1 "isi":"01" . . . . . . . . . . . . . . . . . . . . . . . 21 B.1.2 "isi":"10" . . . . . . . . . . . . . . . . . . . . . . . 21 B.1.3 "isi":"11" . . . . . . . . . . . . . . . . . . . . . . . 21 B.1.4 "isi":"00" . . . . . . . . . . . . . . . . . . . . . . . 22 B.2 Advance Caching . . . . . . . . . . . . . . . . . . . . . . 22 B.2.1 Acquiring server sequence numbers . . . . . . . . . . . 22 B.2.2 Proxy caching . . . . . . . . . . . . . . . . . . . . . 23 B.3 Observe . . . . . . . . . . . . . . . . . . . . . . . . . . 24 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 Selander, et al. Expires April 30, 2015 [Page 2] INTERNET DRAFT Object Security for ACE October 27, 2014 Selander, et al. Expires April 30, 2015 [Page 3] INTERNET DRAFT Object Security for ACE October 27, 2014 1. Introduction The Constrained Application Protocol CoAP [RFC7252] was designed with a constrained RESTful environment in mind. CoAP references DTLS [RFC6347] for securing the message exchange. However, transport layer security is problematic in use cases built on store-and-forward or publish-subscribe, which require end-to-end security. DTLS offers only hop-by-hop security and requires trusted intermediaries. Moreover DTLS incurs a noticeable overhead in constrained devices due to the handshake procedure. This memo presents an object security approach for secure messaging in constrained environments based on the protection of individual request and response messages. In this version of the draft we focus on end-to-end integrity protection, which addresses some of the use cases e.g. where it is necessary for endpoints or proxies to verify that the message is authentic. We plan to add encryption in a later version since this is essential for other use cases. 1.1 Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. These words may also appear in this document in lowercase, absent their normative meanings. Certain security-related terms are to be understood in the sense defined in RFC 4949 [RFC4949]. These terms include, but are not limited to, "authentication", "authorization", "confidentiality", "(data) integrity", "message authentication code", "signature", and "verify". RESTful terms including "resource", "representation", etc. are to be understood as used in HTTP [RFC7231] and CoAP [RFC7252]. Terminology for constrained environments including "constrained device", "constrained-node network", "class 1", etc. are defined in [RFC7228]. Client, Resource Server, and Authorization Server are defined in [I- D.seitz-ace-problem-description]. When we just use the term server, we refer to the Resource Server. JSON Web Signature (JWS), JOSE Header, JWS Payload, and JWS Signature are defined in [I-D.ietf-jose-json-web-signature]. Selander, et al. Expires April 30, 2015 [Page 4] INTERNET DRAFT Object Security for ACE October 27, 2014 NOTE: A CoAP message has header, options and payload. A JWS object has header, payload, and signature. Hence the unqualified terms "header" and "payload" have two meanings. The JWS option is a CoAP option defined in this memo. 2. Background The background for this work is provided by the use cases and problem description in [I-D.seitz-ace-usecases] and [I-D.seitz-ace-problem- description]. The specific part of the problem statement we address in this memo relates to sections 4.6 - 4.7 of [I-D.seitz-ace-problem- description]. The overall objective in securing access requests is that only authorized requests are granted and that the message content is protected (according to requirements of the particular use case) between client and server. As explained in the introduction, we are focusing on an efficient solution to protect requests and response end-to-end in constrained environments supporting e.g. store-and- forward use cases. To give a few examples, end-to-end integrity protection can be used to: o prevent manipulation and allow multiple clients to verify sensor readings stored in un-trusted intermediary nodes; o protect configuration data or firmware updates stored in an intermediate node, e.g. because the device was not connected at the time of the update request; o protect transport of authorization information ("access tokens") to sleepy devices. The IETF has defined standardized content formats for cryptographically protected data (e.g. CMS [RFC5652], JWS [I-D.ietf- jose-json-web-signature]). Other more compact representations are in discussion in the IETF, see section 5 of [JoseWgIetf90]. One potential approach for defining data object security for constrained environments is to wrap application layer data using such a format and sending it as payload in a CoAP message. An alternative approach is to instead build data object security into the CoAP message format. The second approach is the one we propose in this memo. As is explained in Appendix A and B this approach enables some attractive features compared to transport of protected data on top of CoAP, including: Selander, et al. Expires April 30, 2015 [Page 5] INTERNET DRAFT Object Security for ACE October 27, 2014 o Protection of certain CoAP header and option fields o Compliance with REST o Reduction of message size, by avoiding unnecessary duplication of data in payload and header/options o Reuse of CoAP specific mechanisms for caching and forwarding Independently of approach, the format needs to be complemented with a description how the client and the server establish the keys, and how the keys are used for wrapping and unwrapping the secured data object. One way to address key establishment is to assume that there is a trusted third party which can support client and server, such as the Authorization Server in [I-D.draft-seitz-ace-problem- description]. The Authorization Server may, for example, authenticate the client on behalf of the server, or provide cryptographic keys or credentials to the client and/or server to secure the request/response procedure. We emphasize that the solution sketched in this memo can be combined with DTLS [RFC6347], thus enabling end-to-end integrity protection of CoAP payload, certain CoAP headers and options, in combination with hop-by-hop protection of the entire CoAP messages during transport between end-points and intermediary devices. 3. The JWS Option In order to integrity protect individual request and responses, as well as request-response message exchanges, we introduce a new CoAP option, the JWS option, essentially containing a digital signature or Message Authentication Code (MAC) of the CoAP message. Endpoints supporting this scheme MUST check for the presence of this option, and that the signature/MAC is valid before accepting a message as valid. The design considerations leading up to this solution are presented in Appendix A. 3.1 Option Structure The JWS option indicates that certain CoAP header fields, options, and payload (if present) are integrity protected using JWS [I-D.ietf- jose-json-web-signature]. The JWS option SHALL contain a detached signature (JOSE Header and JWS Signature) as described in [I-D.ietf- jose-json-web-signature] Appendix F, using JWS Compact Serialization (see section 3.1 of [I-D.ietf-jose-json-web-signature]). This option is critical, safe to forward, it is not part of a cache Selander, et al. Expires April 30, 2015 [Page 6] INTERNET DRAFT Object Security for ACE October 27, 2014 key, and it is not repeatable. Table 1 illustrates the structure of this option. +-----+---+---+---+---+---------+--------+-----------+ | No. | C | U | N | R | Name | Format | Length | +-----+---+---+---+---+---------+--------+-----------+ | TBD | x | | x | | JWS | opaque | 125-256 B | +-----+---+---+---+---+---------+--------+-----------+ C=Critical, U=Unsafe, N=NoCacheKey, R=Repeatable Table 1: The JWS Option 3.2 Integrity Protection and Verification A CoAP endpoint composing a message using the JWS option SHALL process the JWS Payload and JOSE Header, defined in the following sections, according to the specification for producing the signature/MAC of a JWS object as described in Section 5.1 of the JWS specification [I-D.ietf-jose-json-web-signature]. A CoAP endpoint receiving a message containing the JWS option SHALL first recreate the JWS Payload as described in Section 3.4, and then verify the signature/MAC as defined in Section 5.2 of the JWS specification [I-D.ietf-jose-json-web-signature]. 3.3 JOSE Header Even if a signature/MAC of a received message can be verified, the message may still be old, e.g. a replay of a previous message. As is noted in section 10.10 of [I-D.ietf-jose-json-web-signature]), one way to thwart replay attacks is to include a unique message identifier and having the recipient verify that the message has not been previously received or acted upon. As unique JWS message identifier we propose to use the combination of a unique key identifier and a sequence number. The JOSE Header of a JWS option SHALL contain either one of the "kid", "x5t", or "x5t#S256" header parameters to uniquely identify the key. In this section we define a new JOSE Header parameter "seq" (Sequence Number) enumerating the JWS objects/CoAP messages generated using the key referenced in the JOSE Header. In addition to replay protection, we want to be able to verify that a CoAP response is associated to a previously made CoAP request in order to ensure the freshness of a received response. For this purpose we require the responder to Selander, et al. Expires April 30, 2015 [Page 7] INTERNET DRAFT Object Security for ACE October 27, 2014 include the sender's sequence number and key identifier in the JWS Payload. The header field and procedures described in this section could have been replaced by similar procedures based on time-stamps, if the devices in question had reliable and synchronized clocks. 3.3.1 "seq" (Sequence Number) Header Parameter The "seq" header parameter contains the sequence number associated to the key used to integrity protect the JWS object. The sequence number SHALL be a 32-bit number in hexadecimal representation including leading zeroes. The start sequence number SHALL be 0. For a given key, any sequence number MUST NOT be used in "seq" more than once. The "seq" header parameter SHALL be marked as critical using the "crit" header parameter of JWS (see section 4.1.11 of [I-D.ietf- jose-json-web-signature]), meaning that if a receiver does not understand this parameter it must reject the JWS. 3.3.2 Message Sequence Numbers In order to protect from replay and verify freshness of responses, a CoAP endpoint maintains sequence numbers. A CoAP client supporting the JWS option SHALL store one sequence number per key it uses to protect the integrity of a message. A CoAP server supporting the JWS option SHALL store on sequence number per key it uses to verify the integrity of a message. Depending on use case, the endpoints MAY maintain a sliding receive window for sequence numbers associated to key identifiers in received messages, equivalent to the functionality described in section 4.1.2.6 of [RFC6347]. Before composing a new message with a JWS option, a CoAP client SHALL step the associated sequence number and SHALL include it in the "seq" header parameter as defined in 3.3.1. However, if the sequence number counter wraps, the client must first acquire a new key. (The latter is out of scope of this memo.) A CoAP server supporting the JWS option SHALL verify the sequence number received in "seq" by comparing with the stored associated sequence number (or sliding window). If a CoAP server receives a valid request with a JWS option, then the response SHALL include the sequence number and key identifier of the request in the JWS Payload as defined in section 3.4. Selander, et al. Expires April 30, 2015 [Page 8] INTERNET DRAFT Object Security for ACE October 27, 2014 If the CoAP client receives a response message with a JWS option, then the client SHALL generate the JWS Payload using the key identifier and the sequence number of its own associated request as defined in section 3.4 In Appendix B, we show how this can be extended to account for proxy caching functionality as well as the CoAP Observe option. 3.4 JWS Payload The JWS Payload is type-value-length encoded and consists of: o the CoAP header field Code; o all CoAP options present which are marked as signed in Table 2 (see Appendix A); and o the CoAP payload (if any). o if the message is a response, the sequence number "seq" from the request (see section 3.3.1); o if the message is a response, the key identifier from the request ("kid", "x5t" or "x5t#256", see section 3.3.2) To integrity protect the CoAP options requires the generation of a standalone representation of each option (without the option delta, see section 3.1 of [RFC7252]). The following procedure SHALL be applied to generate an option representation: Calculate the option number and represent it as a 8-bit unsigned integer. Then concatenate the 8-bit option value with a 16-bit unsigned integer in network byte order indicating the length of the Option Value, in bytes. Finally concatenate the option value (if any is present) with that bit-string. For a request, the JWS Payload SHALL be the concatenation of the 8- bit CoAP header field Code, the CoAP option representations (as described in the previous paragraph) which are marked signed in Table 2 (see Appendix A) in the same order as given in the request, and finally a 16-bit unsigned integer in network byte order indicating the length of the CoAP payload, in bytes, and the CoAP payload of the message (if any present) as represented in the request. For a reply, the JWS Payload SHALL be generated as above, but additionally the server SHALL append the concatenation of the 32-bit sequence number from the request, an 8-bit unsigned integer in network byte order indicating the length of the key identifier, in Selander, et al. Expires April 30, 2015 [Page 9] INTERNET DRAFT Object Security for ACE October 27, 2014 bytes, and the key identifier from the request. 4. Proxy Behavior As we target end-to-end security, we must ensure that the solution is compliant with message handling in intermediary nodes. CoAP distinguishes between two types of proxies; forward-proxies, which are explicitly selected by clients, and reverse-proxies, which handle requests transparently to the client. Since the client is not aware of any nodes behind a reverse-proxy, it perceives the reverse- proxy as an origin server which terminates the end-to-end security. Forward-proxies are in scope and we cover two cases here: the CoAP- CoAP forward proxy and the HTTP-CoAP cross-proxy. For CoAP-CoAP forward proxies, the JWS option SHALL be forwarded. Using an HTTP-CoAP proxy requires that the client understands how to formulate a CoAP request. In the "Default Mapping", the Target CoAP URI is appended as-is to a base URI [I-D.ietf-core-http-mapping]. Analogously to a CoAP-CoAP forward proxy, the relevant options are copied from the HTTP URI. The JWS option SHALL be transported in the HTTP URI as a Query: ?JWS=... where the dots "..." should be replaced by the JWS option. Proxies not supporting the JWS option handle messages containing a JWS option according to the CoAP option processing rules, i.e. they will not process such messages themselves (since the option is marked "critical") but they will forward such messages (since the option is marked as "safe-to-forward"). 5. Examples In this section we give examples in order to illustrate and clarify the intended use of the JWS option. 5.1 GET This example outlines a GET message exchange forwarded by a proxy. Integrity protection applies to Code, Uri-Path, Payload and other message fields. Selander, et al. Expires April 30, 2015 [Page 10] INTERNET DRAFT Object Security for ACE October 27, 2014 Client Proxy Server | | | | | | +----->| | Header: GET (Code=0.01) Token: 0x8c | GET | | Uri-Path: "temperature" | | | JWS: (JOSE Header: { "seq":"00000142" } ...) | | | | | | | +----->| Header: GET (Code=0.01) Token: 0x7b | | GET | Uri-Path: "temperature" | | | JWS: (JOSE Header: { "seq":"00000142" } ...) | | | | | | | |<-----+ Header: 2.05 Content (Code=2.05) Token: 0x7b | | 2.05 | JWS: (...) | | | Payload: "23.1 C" | | | | | | |<-----+ | Header: 2.05 Content (Code=2.05) Token: 0x8c | 2.05 | | JWS: (...) | | | Payload: "23.1 C" | | | where the signature and other details are omitted. The complete JOSE header for the request is: {"alg":"HS256", "kid":"a1534e3c5fdc09bd", "crit":["seq"], "seq":"00000142" } and the JWS Payload consists of: * 000 00001 (the header field code GET) * 0x0B (option number 11, Uri-Path) * 0x000B (length of the option value: 11) * "temperature" (the option value) * (Other options are omitted for brevity.) and for the response is: {"alg":"HS256", Selander, et al. Expires April 30, 2015 [Page 11] INTERNET DRAFT Object Security for ACE October 27, 2014 "kid":"c1a6fa909502dd82" } The "kid" is a hint to the receiver indicating which key was used to secure the JWS, and may be used as an identifier for a secret key or a public key. It may e.g. be the hash of a public key. Even if "kid" are different in request and response, it may reference the same symmetric key. The JWS Payload for the response consists of: * 010 00101 (the header field code 2.05 Content) * 0x0006 (length of the payload: 6) * "23.1 C" (the payload value) * "a1534e3c5fdc09bd" (the key identifier from the request) * 0x00000142 (the sequence number from the request 5.2 POST This example outlines a POST message exchange forwarded by a proxy. Integrity protection applies to Code, Uri-Path, Payload and other message fields. Client Proxy Server | | | | | | | | | +----->| | Header: POST (T=CON, Code=0.02, MID=0xf124) | POST | | Token: 0x8c | | | Uri-Path: "lock" | | | JWS: (JOSE Header: { "x5t":"a9095...a32a7b", | | | "seq":"0000036f", ...} ...) | | | Payload: "open" | | | | +----->| Header: POST (T=CON, Code=0.02, MID=0xf124) | | POST | Token: 0x8c | | | Uri-Path: "lock" | | | JWS: (JOSE Header: { "x5t":"a9095...a32a7b", | | | "seq":"0000036f", ...} ...) | | | Payload: "open" | | | | |<-----+ Header: 2.04 Changed (T=ACK, Code=2.04, | | 2.04 | MID=0xf124) Token: 0x8c | | | JWS: (JOSE Header: { "x5t":"9f2a...8520", Selander, et al. Expires April 30, 2015 [Page 12] INTERNET DRAFT Object Security for ACE October 27, 2014 | | | ...} ...) | | | |<-----+ | Header: 2.04 Changed (T=ACK, Code=2.04, | 2.04 | | MID=0xf124) Token: 0x8c | | | JWS: (JOSE Header: { "x5t":"9f2a...8520", | | | ...} ...) | | | Note that in this case the client and the server are using X.509 certificates, which need to be available to both participants, so that they can look up the right public key using the thumbprint. If the proxy also has the public keys available, it can perform signature verification and discard invalid messages, in order to offload work from the client and server. 6. Security Considerations In scenarios with proxies, gateways, or caching, DTLS only protects data hop-by-hop meaning that all intermediary nodes can modify information. The trust model where all participating 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 makes such an architecture weak. DTLS protects the entire CoAP message including header, options and payload, whereas this proposal only protects selected message fields. DTLS, however, also incurs a large overhead cost, due to the handshake procedure. While that cost can be amortized in scenarios with long lived connections, in cases where a device will have connections with varying clients, using secured objects instead of session security can provide a significant performance gain. Using blockwise transfer [I-D.ietf-core-coap-block], the integrity protection as provided by the method described here only covers the individual blocks, not the entire request or response. One way to handle this would to allow the JWS option to be repeatable, and in one or several of the block transfer carry a MAC or signature that covers the entire request or response. Since the Version header field is not integrity protected, in case of future versions of CoAP it may in theory be possible to launch a cross-version attack, e.g. something analogously to a bidding down attack. Future updates of CoAP should take this into account. Selander, et al. Expires April 30, 2015 [Page 13] INTERNET DRAFT Object Security for ACE October 27, 2014 7. Privacy Considerations End-to-end integrity protection provides certain privacy properties, e.g. protects communication with sensor and actuator from manipulation which may affect the personal sphere. As a next step we plan to extend this scheme by add encryption for addressing other privacy concerns, such as confidentiality of personal data and prevention of pervasive monitoring. 8. IANA Considerations The following entry is added to the CoAP Option Numbers registry: +--------+---------+-------------------+ | Number | Name | Reference | +--------+---------+-------------------+ | TBD | JWS | [[this document]] | +--------+---------+-------------------+ The following entries are added to the JSON Web Signature and Encryption Header Parameters registry for Header Parameter names: o Header Parameter Name: "seq" o Header Parameter Description: Message sequence number o Header Parameter Usage Location(s): JWS o Change Controller: IESG o Specification Document(s): Section 3.3.1 of [[ this document ]]] 9. References 9.1 Normative References [I-D.ietf-jose-json-web-signature] Jones, M., Bradley, J., and Sakimura N., "JSON Web Signature (JWS)", draft-ietf-jose-json-web-signature-36 (work in progress), October 2014. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, January 2012. [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained Selander, et al. Expires April 30, 2015 [Page 14] INTERNET DRAFT Object Security for ACE October 27, 2014 Application Protocol (CoAP)", RFC 7252, June 2014. 9.2 Informative References [I-D.seitz-ace-problem-description] Seitz, L., and G. Selander, "Problem Description for Authorization in Constrained Environments", draft-seitz- ace-problem-description-01 (work in progress), July 2014. [I-D.seitz-ace-usecases] Seitz, L., Gerdes, S., Selander, G., Mani, M., and S. Kumar, "ACE use cases", draft-seitz-ace-usecases-01 (work in progress), July 2014. [JoseWgIetf90] Minutes of the JOSE WG meeting at IETF 90, http://www.ietf.org/proceedings/90/minutes/minutes-90-jose [I-D.ietf-core-http-mapping] Castellani, A., Loreto, S., Rahman, A., Fossati, T., and E. Dijk, "Guidelines for HTTP-CoAP Mapping Implementations", draft-ietf-core-http-mapping-05 (work in progress), October 2014. [I-D.ietf-core-coap-block] Bormann, C., and Z. Shelby, "Blockwise transfers in CoAP", draft-ietf-core-block-15 (work in progress), July 2014. [I-D.ietf-jose-cookbook] M. Miller, "Examples of Protecting Content using JavaScript Object Signing and Encryption (JOSE)", draft- ietf-jose-cookbook-05 (work in progress), October 2014. [I-D.ietf-core-observe] K. Hartke, "Observing Resources in CoAP", draft-ietf- core-observe-14 (work in progress), June 2014. [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", FYI 36, RFC 4949, August 2007. [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, RFC 5652, September 2009. [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for Constrained-Node Networks", RFC 7228, May 2014. [RFC7231] Fielding, R., Ed., and J. Reschke, Ed., "Hypertext Selander, et al. Expires April 30, 2015 [Page 15] INTERNET DRAFT Object Security for ACE October 27, 2014 Transfer Protocol (HTTP/1.1): Semantics and Content", RFC 7231, June 2014. Appendix A. Design Considerations In this section we provide some motivation for the chosen solution. The pedagogical attempt of this section is by means of iterative modifications of the trivial solution consisting of a secure object carried in the payload. A.1 Reducing Message Size We noted in Section 2 that end-to-end security may be provided on application layer on top of CoAP by including, say, a JWS object [I- D.ietf-jose-json-web-signature] in the CoAP payload. The JWS represents content secured with digital signatures or Message Authentication Codes (MACs) using JavaScript Object Notation (JSON) based data structures. However, if the content of the JWS object is independent from the CoAP message, it does not integrity protect CoAP header fields or options. To address this, one solution is to repeat certain information, contained within CoAP header fields and options, in the JWS object. However, this would not be optimal since some data would be duplicated in header/options and payload. For example, a resource identifier would be transported both as a CoAP URI-Path/URI-Query option (to comply with the CoAP message format), and in the payload (to integrity protect the intended resource which the request is targeting). Fortunately, there is a solution to this problem known as "detached content" (Appendix F, [I-D.ietf-jose-json-web-signature]) a.k.a. "detached signature" ([I-D.ietf-jose-cookbook]). As is described in these references, the detached signature is constructed from "a JWS object in the normal fashion using a representation of the content as the payload, but then delete the payload representation from the JWS". With the outcome that "the resulting JWS object do not include the integrity protected content. Instead, the application is expected to locate it elsewhere." Using JWS detached signature together with a specification for what message fields should be included in the digital signature or MAC, we can get integrity protection of relevant CoAP message fields without unnecessary duplication of message fields. Selander, et al. Expires April 30, 2015 [Page 16] INTERNET DRAFT Object Security for ACE October 27, 2014 A.2 REST Considerations As we saw in the previous section, a JWS detached signature in the CoAP payload would provide integrity protection and optimized message format. However, not all CoAP request and response messages support payload. E.g. GET and DELETE requests may not have defined body semantics and that could to some extent violate RESTful design. Furthermore, some CoAP response messages are not allowed to have payload or are only intended to carry resource representations. We therefore propose to pass a JWS detached signature as a new CoAP option, as described in section 3. NOTE: The choice of JWS is based on its relative compactness. Even compacter formats, as recently has been discussed [JoseWgIetf90], would be favorable. A.3 Protection of CoAP Message Fields Having motivated how a signature or MAC should be carried, we now turn to the question what information should be integrity protected. Integrity protection should cover relevant message fields that are not supposed to change between client and server. This must also take into account that there may be intermediary devices caching and/or forwarding requests or responses. In this section we study the message format (see Figure 1) and list the fields that need to be integrity protected as well as describe the procedure. Clearly the payload should be protected, but not all headers fields or options. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Ver| T | TKL | Code | Message ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Token (if any, TKL bytes) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options (if any) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1 1 1 1 1 1 1 1| Payload (if any) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: CoAP message Format Selander, et al. Expires April 30, 2015 [Page 17] INTERNET DRAFT Object Security for ACE October 27, 2014 A.3.1 CoAP Header We now describe which fields in the CoAP header that needs to be protected. o Version (Ver): This field is fixed for a given implementation. However, to allow backward compatibility with future versions of CoAP, Version SHALL NOT be integrity protected. o Type (T) and Message ID: These fields are only relevant on CoAP messaging layer. Different Types (CON, NON, ACK, RST) or Message IDs may be used to transport the same request/response and hence SHALL NOT be integrity protected. o Token Length (TKL) and Token: CoAP is using the Token as a request identifier to match responses against requests. In the case of multi-hop using intermediaries, the Token may be different between the hops and is not preserved end-to-end. These fields SHALL NOT be integrity protected. o Code: This field is an 8-bit unsigned integer, identifying request method or response code which should not change and hence SHALL be integrity protected. Summarizing: Only the Code header field is included in the JWS Payload of the JWS option. A.3.2 CoAP Options The options need to be integrity protected as follows: o ETag: This option defines resource local identifier of representation and hence SHALL be integrity protected. o If-Match, If-None-Match: These options are conditional control logic for requests which thus SHALL be integrity protected. o Observe: This option is elective and unsafe so may be discarded by a proxy. Hence it SHALL NOT be integrity protected. o Location-Path, Location-Query: These options are essentially the identifier of a new resource and hence SHALL be integrity protected. o Accept, Content-Format: These options indicates representation format of payload and hence SHALL be integrity protected. Selander, et al. Expires April 30, 2015 [Page 18] INTERNET DRAFT Object Security for ACE October 27, 2014 o Max-Age: The Max-Age option in the response is intended to be decreased by an intermediary device caching the response. Moreover it is elective and unsafe to forward. It SHALL NOT be integrity protected. o Size1: This option provides size information about the resource representation in a request and SHALL be integrity protected. o Proxy-Uri: This option contains the request URI, which identifies the requested resource, and hence it SHALL be integrity protected, see last item in this list. o Proxy-Scheme: This option contains the intended scheme to be used by a proxy, and hence it SHALL be integrity protected, see also last item in this list. o Uri-Host, Uri-Port, Uri-Path and Uri-Query: In a request to an origin server the request URI is decomposed into these options. In the case of requests made to an origin server, these options contain the complete information about the request URI. On the other hand in a proxy request, the request URI is specified by the client as a string in the Proxy-Uri option. The proxy which makes this a request to the origin server decomposes the Proxy- Uri into Uri-Host, Uri-Port, Uri-Path, and Uri-Query options. However, the full URI can be reconstructed at any involved endpoint. To allow integrity verification of the request URI, the client and forward proxies SHALL use explicit Uri-Host and Uri-Port options. The server SHALL compose the URI from options according to the method described in section 6.5 of the CoAP specification [RFC7252]. The so obtained URI is put into a Proxy-Uri option (no. 35), which is included in the integrity calculation. Table 2 summarizes which options to include in the integrity calculation. Options marked with "x" are included. Options marked with "d" are composed into a URI as described above and included as the Proxy-Uri option for the purpose of calculating the signature. (Proxy-Uri and the options marked with "d" are mutually exclusive.) +-----+---+---+---+---+----------------+--------+--------+--------+ | No. | C | U | N | R | Name | Format | Length | Signed | +-----+---+---+---+---+----------------+--------+--------+--------+ | 1 | x | | | x | If-Match | opaque | 0-8 | x | | 3 | x | x | - | | Uri-Host | string | 1-255 | d | Selander, et al. Expires April 30, 2015 [Page 19] INTERNET DRAFT Object Security for ACE October 27, 2014 | 4 | | | | x | ETag | opaque | 1-8 | x | | 5 | x | | | | If-None-Match | empty | 0 | x | | 6 | | x | - | | Observe | uint | 0-3 | | | 7 | x | x | - | | Uri-Port | uint | 0-2 | d | | 8 | | | | x | Location-Path | string | 0-255 | x | | 11 | x | x | - | x | Uri-Path | string | 0-255 | d | | 12 | | | | | Content-Format | uint | 0-2 | x | | 14 | | x | - | | Max-Age | uint | 0-4 | | | 15 | x | x | - | x | Uri-Query | string | 0-255 | d | | 17 | x | | | | Accept | uint | 0-2 | x | | 20 | | | | x | Location-Query | string | 0-255 | x | | 35 | x | x | - | | Proxy-Uri | string | 1-1034 | x | | 39 | x | x | - | | Proxy-Scheme | string | 1-255 | x | | 60 | | | x | | Size1 | uint | 0-4 | x | +-----+---+---+---+---+----------------+--------+--------+--------+ | TBD | x | | x | | JWS | opaque | 125-256| | +-----+---+---+---+---+----------------+--------+--------+--------+ C=Critical, U=Unsafe, N=NoCacheKey, R=Repeatable Table 2: Which options to integrity protect. Appendix B. Replay Protection - Special Cases In this section we show how one can use the JWS option to handle advance caching and subscribe (CoAP Observe) responses to GET requests. Please note that this is work in progress. The general problem introduced in these settings is that there is no longer an end-to-end challenge-response protocol: o An intermediary forward proxies may cache a response to a corresponding GET request, and serve that response to another client's GET request. o A server may produce multiple responses to one GET Observe request, i.e. there is no unique matching request for each response. This induces a number of changes: o In general, we can't hope to prove freshness, but can still protect from replayed responses using server sequence numbers, indicated with the "seq" header parameter. o However, to define an initial server sequence number we propose Selander, et al. Expires April 30, 2015 [Page 20] INTERNET DRAFT Object Security for ACE October 27, 2014 to rely on an end-to-end challenge-response protocol. o A response message containing a challenge, is neither available nor meaningful to other clients. Since we are using both server sequence numbers and challenge-response, we need to indicate which of these freshness/replay protection parameter is used in a given response. We introduce an indicator in section B.1. o Since the resource identifier cannot be inferred from a default CoAP response message when there is no associated integrity protected challenge, we need to add this explicitly when we rely on server sequence numbers. o Note that since there may be multiple receivers of a response, this scenario makes most sense with asymmetric crypto, i.e. that the signature of the response can verified using the public key of the server. B.1 "isi" (Integrity Scope Indication) Header Parameter We introduce a new JOSE Header parameter indicating in requests, what freshness/replay parameter to integrity protect, and in responses, what freshness/replay protection parameter is integrity protected. The "isi" header parameter is a 2-bit indication of what value shall be or is integrity protected in the response. The "isi" header parameter SHALL be marked as critical. B.1.1 "isi":"01" This indicates that the key identifier and sequence number of the request is placed in the JWS Payload of the response, and thus integrity protected. There is no server sequence number in the response. This the same procedure described in section 3. B.1.2 "isi":"10" This indicates that the server sequence number is in the "seq" header parameter of the response, and thus integrity protected. The key identifier and sequence number of the request is not included in the JWS payload. The response SHALL contain the request URI in the proxy-URI option. B.1.3 "isi":"11" This is a combination of the previous two. This indicates that the key identifier and sequence number of the request is placed in the JWS Payload, and the server sequence number is placed in the "seq" Selander, et al. Expires April 30, 2015 [Page 21] INTERNET DRAFT Object Security for ACE October 27, 2014 header parameter of the response. Thus both parameters are integrity protected. B.1.4 "isi":"00" This value is reserved for future use. B.2 Advance Caching B.2.1 Acquiring server sequence numbers Client Proxy Server | | | | | | | | | +----->| | Header: GET (Code=0.01) Token: 0x8c | GET | | Uri-Path: "temperature" | | | JWS: (JOSE Header: { "kid":"b00d4272ae41433e", | | | "seq":"00000142", | | | "isi":"11", | | | ...} ...) | | | | +----->| Header: GET (Code=0.01) Token: 0x4b | | GET | Uri-Path: "temperature" | | | JWS: (JOSE Header: { "kid":"b00d4272ae41433e", | | | "seq":"00000142", | | | "isi":"11", | | | ...} ...) | | | | | | | |<-----+ Header: 2.05 Content (Code=2.05) Token: 0x4b | | 2.05 | JWS: (JOSE Header: { "kid":"c1a6fa909502dd82", | | | "seq":"000000D7", | | | "isi":"11", | | | ...} ...) | | | Payload: "23.1 C" | | | | | | |<-----+ | Header: 2.05 Content (Code=2.05) Token: 0x8c | 2.05 | | JWS: (JOSE Header: { "kid":"c1a6fa909502dd82", | | | "seq":"000000D7", | | | "isi":"11", | | | ...} ...) | | | Payload: "23.1 C" | | | Selander, et al. Expires April 30, 2015 [Page 22] INTERNET DRAFT Object Security for ACE October 27, 2014 In this case, the proxy recognizes that it cannot serve a verifiably fresh cached answer to the client and therefore obtains a new one by forwarding the client's request. The CoAP server SHALL step the associated sequence number and SHALL include it in the "seq" header parameter. However, if the sequence number counter wraps, the server must first acquire a new key. (The latter is out of scope of this memo.) The server includes the key identifier and sequence number of the request in the JWS payload as described in section 3. The client can thus verify the freshness of the response and conclude the sequence number is fresh. Here either symmetric and asymmetric keys may be used. B.2.2 Proxy caching Client Proxy Server | | | | | | | +----->| Header: GET (Code=0.01) Token: 0x4c | | GET | Uri-Path: "temperature" | | | JWS: (JOSE Header: { "kid":"a1534e3c5fdc09bd", | | | "seq":"00000070", | | | "isi":"10", | | | ...} ...) | | | | |<-----+ Header: 2.05 Content (Code=2.05) Token: 0x4c | | 2.05 | JWS: (JOSE Header: { "kid":"c1a6fa909502dd82", | | | "seq":"000000DA", | | | "isi":"10", | | | ...} ...) | | | Payload: "22.7 C" | | | | | | | | | +----->| | Header: GET (Code=0.01) Token: 0x8d | GET | | Uri-Path: "temperature" | | | JWS: (JOSE Header: { "kid":"b00d4272ae41433e", | | | "seq":"00000044", | | | "isi":"10", | | | ...} ...) | | | |<-----+ | Header: 2.05 Content (Code=2.05) Token: 0x8d | 2.05 | | JWS: (JOSE Header: { "kid":"c1a6fa909502dd82", | | | "seq":"000000DA", | | | "isi":"10", Selander, et al. Expires April 30, 2015 [Page 23] INTERNET DRAFT Object Security for ACE October 27, 2014 | | | ...} ...) | | | Payload: "22.7 C" | | | In this case the proxy requests a response which includes the server sequence number but not the key identifier and the sequence number of the request. The response also contains the resource URI for identification of resource. When the proxy gets a request with an "isi" header parameter that is not required to be forwarded it is matched against the cached responses, and since a corresponding response is present, it is forwarded to the client. This setting makes most sense in the case of response "kid" identifies a public key of the server. B.3 Observe In certain cases, there may be more than one response associated to a request, e.g. in the case of the CoAP option Observe ([I-D.ietf-core- observe]). To securely distinguish between multiple responses and protect from replay of responses we propose the following approach: Client Server | | | | +----->| Header: GET (Code=0.02) Token: 0x4a | GET | Uri-Path: "temperature" | | Observe: register | | JWS: (JOSE Header: { "kid":"a1534e3c5fdc09bd", | | "seq":"0000006F", | | "isi":"11", ...} ...) | | | | |<-----+ Header: 2.05 Content (Code=2.05) Token: 0x4a | 2.05 | Observe: 12 | | JWS: (JOSE Header: { "kid":"c1a6fa909502dd82", | | "seq":"000001D6", | | "isi":"11", ...} ...) | | Payload: "22.9 C" | | |<-----+ Header: 2.05 Content (Code=2.05) Token: 0x4a | 2.05 | Observe: 44 | | JWS: (JOSE Header: { "kid":"c1a6fa909502dd82", | | "seq":"000001D7", | | "isi":"10", ...} ...) Selander, et al. Expires April 30, 2015 [Page 24] INTERNET DRAFT Object Security for ACE October 27, 2014 | | Payload: "22.8 C" | | |<-----+ Header: 2.05 Content (Code=2.05) Token: 0x4a | 2.05 | Observe: 60 | | JWS: (JOSE Header: { "kid":"c1a6fa909502dd82", | | "seq":"000001D8", | | "isi":"10", ...} ...) | | Payload: "23.1 C" | | The "GET Observe: register" request SHALL contain the "isi" header parameter with value "11". The response to the "GET Observe: register" shall contain the the "isi" header parameter with value "11". This response SHALL NOT be cached. GET Observe responses without a matching request SHALL contain the the "isi" header parameter with value "10", i.e. the response SHALL contain server sequence value "seq" in JOSE Header and no request key identifier and sequence number in the JWS payload. This procedure for replay protection of Observe also works in the presence of proxies by combining the procedures in section B.1 and B.2. This applies both to the cases of a client observing a resource through a proxy, and a proxy observing a resource to keep its cache up to date (section A.2 of [I-D.ietf-core-observe]). Authors' Addresses Goeran Selander Ericsson Farogatan 6 16480 Kista SWEDEN EMail: goran.selander@ericsson.com Ludwig Seitz SICS Swedish ICT AB Scheelevagen 17 22370 Lund SWEDEN EMail: ludwig@sics.se John Mattsson Ericsson Farogatan 6 16480 Kista SWEDEN EMail: john.mattsson@ericsson.com Selander, et al. Expires April 30, 2015 [Page 25] INTERNET DRAFT Object Security for ACE October 27, 2014 Selander, et al. Expires April 30, 2015 [Page 26]