ACE Working Group G. Selander Internet-Draft J. Mattsson Intended Status: Standards Track Ericsson Expires: September 10, 2015 L. Seitz SICS Swedish ICT March 9, 2015 Object Security for CoAP draft-selander-ace-object-security-01 Abstract This memo presents a scheme for data object security applicable to protection of payload of generic message formats as well as request and response messages of the Constrained Application Protocol (CoAP). 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) 2015 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 September 10, 2015 [Page 1] INTERNET DRAFT Object Security for ACE March 9, 2015 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. End-to-end Security in Presence of Intermediary Nodes . . . . . 6 4. Secure Message . . . . . . . . . . . . . . . . . . . . . . . . 7 4.1 Secure Message format . . . . . . . . . . . . . . . . . . . 8 4.1.1 Secure Message Header . . . . . . . . . . . . . . . . . 8 4.1.2 Secure Message Body . . . . . . . . . . . . . . . . . . 9 4.1.2.1 Secure Signed Message Body . . . . . . . . . . . . . 9 4.1.2.2 Secure Encrypted Message Body . . . . . . . . . . . 9 4.1.3 Secure Message Tag . . . . . . . . . . . . . . . . . . . 9 5. Message Protection . . . . . . . . . . . . . . . . . . . . . . 9 5.1 CoAP Message Protection . . . . . . . . . . . . . . . . . . 10 5.1.1 The Sig Option . . . . . . . . . . . . . . . . . . . . . 10 5.1.1.1 Option Structure . . . . . . . . . . . . . . . . . . 10 5.1.1.2 Integrity Protection and Verification . . . . . . . 11 5.1.1.3 SSM Body . . . . . . . . . . . . . . . . . . . . . . 11 5.1.2 The Enc Option . . . . . . . . . . . . . . . . . . . . . 12 5.1.2.1 Option Structure . . . . . . . . . . . . . . . . . . 12 5.1.2.2 Encryption and Decryption . . . . . . . . . . . . . 12 5.1.2.3 SEM Body . . . . . . . . . . . . . . . . . . . . . . 13 5.1.2.4 CoAP Message with Enc Option . . . . . . . . . . . . 13 5.1.3 SM Tag . . . . . . . . . . . . . . . . . . . . . . . . . 14 5.2 Application Layer Protection . . . . . . . . . . . . . . . . 14 5.3 Replay Protection and Freshness . . . . . . . . . . . . . . 15 5.3.1 Replay Protection . . . . . . . . . . . . . . . . . . . 15 5.3.2 Freshness . . . . . . . . . . . . . . . . . . . . . . . 15 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 16 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 17 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 10.1 Normative References . . . . . . . . . . . . . . . . . . . 19 10.2 Informative References . . . . . . . . . . . . . . . . . . 19 Appendix A. Which CoAP Header Fields and Options to Protect . . . 20 A.1 CoAP Header Fields . . . . . . . . . . . . . . . . . . . . . 20 A.2 CoAP Options . . . . . . . . . . . . . . . . . . . . . . . . 20 A.2.1 Integrity Protection . . . . . . . . . . . . . . . . . . 21 Selander, et al. Expires September 10, 2015 [Page 2] INTERNET DRAFT Object Security for ACE March 9, 2015 A.2.2 Encryption . . . . . . . . . . . . . . . . . . . . . . . 22 A.2.3 Summary . . . . . . . . . . . . . . . . . . . . . . . . 22 Appendix B. JOSE Objects as Secure Messages . . . . . . . . . . . 23 B.1 JWS as Secure Signed Message . . . . . . . . . . . . . . . 23 B.2 JWE as Secure Encrypted Message . . . . . . . . . . . . . . 23 B.3 "seq" (Sequence Number) Header Parameter . . . . . . . . . . 24 B.4 "mod" (Mode) Header Parameter . . . . . . . . . . . . . . . 24 B.4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 Appendix C. Compact Secure Message . . . . . . . . . . . . . . . 25 C.1 CSM Format . . . . . . . . . . . . . . . . . . . . . . . . . 25 C.2 Comparison of Secure Message sizes . . . . . . . . . . . . . 27 Appendix D. Examples . . . . . . . . . . . . . . . . . . . . . . 29 D.1 CoAP Message Protection . . . . . . . . . . . . . . . . . . 29 D.1.1 Integrity protection of CoAP Message . . . . . . . . . . 29 D.1.2 Encryption of CoAP Message . . . . . . . . . . . . . . . 30 D.2 Application Layer Protection . . . . . . . . . . . . . . . . 32 D.2.1 Proxy Caching . . . . . . . . . . . . . . . . . . . . . 32 D.2.2 Publish-Subscribe . . . . . . . . . . . . . . . . . . . 33 D.2.3 Transporting Authorization Information . . . . . . . . . 34 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35 Selander, et al. Expires September 10, 2015 [Page 3] INTERNET DRAFT Object Security for ACE March 9, 2015 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 exchanges. Two commonly used features of CoAP are store-and-forward and publish-subscribe exchanges, which are problematic to secure with DTLS and transport layer security. As DTLS offers hop-by-hop security, in case of store-and-forward exchanges it necessitates a trusted intermediary. On the other hand, securing publish-subscribe CoAP exchanges with DTLS requires the use of the keep-alive mechanism which incurs additional overhead and actually takes away most of the benefits of asynchronous communication. The pervasive monitoring debate has illustrated the need to protect data also from trustworthy intermediary nodes as they can be compromised. The community has reacted strongly to the revelations, and new solutions must consider this attack [RFC7258] and include encryption by default. This memo presents an object security approach for secure messaging in constrained environments that may be used as a complement to DTLS for store-and-forward and publish-subscribe CoAP exchanges. Note that the solution sketched in this memo can be combined with DTLS thus enabling, for example, end-to-end security of CoAP payload in combination with hop-by-hop protection of the entire CoAP messages during transport between end-point and intermediary node. This version of the draft focuses on symmetric key based algorithms. Public key based algorithms will be addressed in the next version. 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, such as "resource" or "representation", are to be understood as used in HTTP [RFC7231] and CoAP. Selander, et al. Expires September 10, 2015 [Page 4] INTERNET DRAFT Object Security for ACE March 9, 2015 Terminology for constrained environments, such as "constrained device", "constrained-node network", is defined in [RFC7228]. Client, Resource Server, and Authorization Server are defined in [I- D.seitz-ace-problem-description]. The terms "server" and "Resource Server" are used interchangeably. JSON Web Signature (JWS), JOSE Header, JWS Payload, and JWS Signature are defined in [I-D.ietf-jose-json-web-signature]. JSON Web Encryption (JWE), JWE AAD, JWE Ciphertext, and JWE Authentication Tag are defined in [I-D.ietf-jose-json-web- encryption]. Secure Message (SM), Secure Signed Message (SSM), and Secure Encrypted Message (SEM) are message formats defined in this memo. The Compact Secure Message (CSM) format is defined in Appendix C. The Sig and Enc options are CoAP options defined in this memo. Excluded Authenticated Data (EAD) is defined in this memo (see Sections 4.1.2). Transaction Identifier (TID) is defined in this memo (see Section 4.1.1). 2. Background The background for this work is provided by the use cases and problem description in [I-D.ietf-ace-usecases] and [I-D.seitz-ace-problem- description]. The overall objective is that (a) only authorized requests are granted, and (b) messages between client and server are protected (according to requirements of the particular use case). The focus of this memo is on end-to-end security in constrained environments in the presence of intermediary nodes, which corresponds to point (b). For constrained-node networks there may be several reasons for messages to be cached or stored in one node and later forwarded. For example, connectivity between the nodes may be intermittent, or some node may be sleeping at the time when the message should have been forwarded (see e.g. [I-D.ietf-ace-usecases] sections 2.1.1, and 2.5.1). Also, the architectural model or protocol applied may require an intermediary node which breaks security on transport layer (see e.g. [I-D.ietf-ace-usecases] sections 2.1.1, and 2.5.2). Examples of intermediary nodes include forward proxies, reverse proxies, pub-sub brokers, HTTP-CoAP cross-proxies, and SMS servers. On a high level, end-to-end security in this setting encompasses: 1. Protection against eavesdropping and manipulation of resource Selander, et al. Expires September 10, 2015 [Page 5] INTERNET DRAFT Object Security for ACE March 9, 2015 representations in intermediary nodes; 2. Protection against message replay; 3. Protection of authorization information ("access tokens") in transport from an Authorization Server to a Resource Server via a Client, or other intermediary nodes which could gain from changing the information; 4. Allowing a client to verify that a response comes from a certain server and is the response to a particular request; 5. Protection of the RESTful method used by the client, or the response code used by the server. For example if a malicious proxy replaces the client requested GET with a DELETE this must be detected by the server; 6. Protection against eavesdropping of meta-data of the request or response, including CoAP options such as for example Uri-Path and Uri-Query, which may reveal some information on what is requested. From the listed examples, there are two main categories of security requirements and corresponding solutions. The first category deals essentially with application layer protection, i.e. protecting the payload of the RESTful protocol (1-3). The second category deals with protecting an entire CoAP message, targeting also CoAP options and header fields (4-6). The next section formulates security requirements for the two categories, which are denoted Mode:APPL and Mode:COAP, respectively. 3. End-to-end Security in Presence of Intermediary Nodes For high-level security requirements related to resource access, see section 4.6 of [I-D.seitz-ace-problem-description]. This section defines the specific requirements that address the two categories of examples identified in the previous section, taking into account potential intermediary nodes. In the case of application layer protection (Mode:APPL), the end-to- end security requirements apply to the RESTful protocol payload data, such as Resource Representations: a. The payload shall be integrity protected and should be encrypted end-to-end from sender to receiver. b. It shall be possible for an intended receiver to detect if it has received this message previously, i.e. replay protection. Selander, et al. Expires September 10, 2015 [Page 6] INTERNET DRAFT Object Security for ACE March 9, 2015 In this case there may be multiple receivers of a given message, for example in the case of a proxy that is caching responses used to serve multiple clients, or in a publish-subscribe setting with multiple subscribers to a given publication. In the case of protecting specific Client-Server CoAP message exchanges (Mode:COAP), potentially passing via intermediary nodes, there are additional end-to-end security requirements: c. The CoAP options which are not intended to be changed by an intermediary node shall be integrity protected between Client and Server. d. The CoAP options which are not intended to be read by an intermediary node shall be encrypted between Client and Server. e. The CoAP header field "Code" shall be integrity protected between Client and Server. f. A Client shall be able to verify that a message is the response to a particular request the Client made. The requirements listed above can be met by encryption, integrity protection and replay protection. What differs is the actual data that is protected, i.e. application layer data or CoAP message data. This memo specifies a common "Secure Message" format that can be used to wrap either payload only or also additional selected CoAP message fields, and be sent as part of the message. 4. Secure Message There exist already standardized and draft content formats for cryptographically protected data such as CMS [RFC5652], JWS, JWE, and COSE [I-D.bormann-jose-cose]. None of the listed formats provide support for replay protection, but it is noted in section 10.10 of [I-D.ietf-jose-json-web-signature]) that one way to thwart replay attacks is to include a unique transaction identifier and have the recipient verify that the message has not been previously received or acted upon. The term Secure Message (SM) format refers to a content format for cryptographically protected data which includes a unique transaction identifier and allows customization to support different variants of format and message processing (Modes). This memo uses JOSE content formats as a model to specify format and processing of messages. The terms Secure Signed Message (SSM) format Selander, et al. Expires September 10, 2015 [Page 7] INTERNET DRAFT Object Security for ACE March 9, 2015 and Secure Encrypted Message (SEM) format to refer to Secure Message formats supporting integrity protection only and additional encryption, analogous to JWS and JWE, respectively. Appendix B shows how JWS and JWE could be extended to become Secure Message formats. It should be noted that the current JOSE objects are undesirably large for very constrained devices. In their current size they can lead to packet fragmentation in constrained-node networks due to limited frame sizes, and to problems with limited storage capacity on constrained devices due to limited RAM. COSE renders more compact objects, and further optimizations are considered. See Appendix C for a discussion of minimum message expansion and message format overhead. 4.1 Secure Message format A Secure Message (SM) SHALL consist of Header, Body and Tag. 4.1.1 Secure Message Header The following parameters SHALL be included in the SM Header: o Algorithm. This parameter allows the receiver to identify the cryptographic algorithm(s) used to protect the Secure Message. In case of SSM it has the same syntax as the JOSE Header Parameter "alg" defined in Section 4.1.1 of [I-D.ietf-jose-json- web-signature]. In case of SEM, it has the same syntax as the JOSE Header Parameter "enc" defined in Section 4.1.2 of [I- D.ietf-jose-json-web-encryption]. (Assuming direct key agreement, corresponding to the JWE "alg" = "dir" setting.) o Key Identifier. This parameter allows the receiver to uniquely identify the sender and the security context/key(s) used with the Algorithm. It has the same syntax as the JOSE Header Parameter "kid" defined in Section 4.1.4 of [I-D.ietf-jose-json- web-signature]. o Sequence Number. The Sequence Number parameter enumerates the Secure Messages protected using the key(s) identified by the Key Identifier, and is used for replay protection and uniqueness of nonce. The start sequence number SHALL be 0. For a given key, any Sequence Number MUST NOT be used more than once. o Mode. The Mode parameter defines application specific message format, content and processing. This parameter provides means for customization of the Secure Message format, in particular to distinguish between Secure Messages containing application layer data only or CoAP message data. Selander, et al. Expires September 10, 2015 [Page 8] INTERNET DRAFT Object Security for ACE March 9, 2015 The ordered sequence (Sequence Number, Key Identifier) is called Transaction Identifier (TID), and SHALL be unique for each SM. 4.1.2 Secure Message Body Analogously to JWS and JWE, the SM Body contains what is being protected. The SM Body is different for SSM and SEM. In order to obtain a compact representation, certain data is integrity protected but excluded from the Secure Message. Such data is referred to as Excluded Authenticated Data (EAD). To further reduce message size, the unencrypted part of the SM Body may be "detached" from the Secure Message, see sections 4.1.2.1 and 4.1.2.2. The assumption behind excluding integrity protected data from the SM, or detaching integrity protected but not encrypted parts of the SM during transport, is that the data in question is known to the receiver, e.g. because it is exchanged beforehand or because it is transported as part of the CoAP message carrying the Secure Message. 4.1.2.1 Secure Signed Message Body For SSM, the Body consists of the payload data which is integrity protected, analogously to the JWS Payload. Detached Content is defined to mean that the Body is removed from the Secure Message, analogously to Appendix F of [I-D.ietf-jose-json-web-signature]. Hence a SSM with Detached Content consists of Header and Tag. 4.1.2.2 Secure Encrypted Message Body Analogously to JWE, the terms Plaintext, Ciphertext and Additional Authenticated Data (AAD) are used for the SEM. The Body of a SEM consists of Ciphertext and Additional Authenticated Data (AAD). For SEM Detached Content is defined to mean that the AAD is removed from the Secure Message. Hence a SEM with Detached Content consists of the Header, Ciphertext and Tag. 4.1.3 Secure Message Tag The SM Tag consists of the Signature / Authentication Tag value as defined by the Algorithm, calculated over the SM Header, SM Body and EAD (if present). The content of EAD depends on the Mode, see 5.1.3 and 5.2 5. Message Protection Selander, et al. Expires September 10, 2015 [Page 9] INTERNET DRAFT Object Security for ACE March 9, 2015 This section describes what is protected in a Secure Message and how it depends on the defined Modes ("CoAP Message Protection" and "Application Layer Protection"). Both formats SSM and SEM defined in the previous section are applicable to both Modes. For examples, see Appendix D. For any Secure Message Mode, the SEM format SHALL be used by default. The SM Header is defined in 4.1.1, indicates the Mode, but is in all other respects handled similarly in both Modes. This section also describes the differences in SM Body and SM Tag. 5.1 CoAP Message Protection Referring to examples 4-6 in Section 2 and requirements a-f in Section 3, this section presents how to protect individual CoAP messages including options and header fields, as well as request- response message exchanges, using the Secure Message format. This is called Secure Message Mode:COAP. An endpoint receiving a CoAP request containing a Secure Message with Mode:COAP MUST respond with a CoAP message containing a Secure Message with Mode:COAP. Since slightly different message formats are used for integrity protection only (SSM), and additional encryption (SEM), these cases are treated separately. Two new CoAP security options are introduced: the Enc option and the Sig option. A CoAP message SHALL NOT include both Enc and Sig options. 5.1.1 The Sig Option In order to integrity protect CoAP message exchanges, a new CoAP option is introduced: the Sig option, containing a SSM Mode:COAP object. Endpoints supporting this scheme MUST check for the presence of a Sig option, and verify the SSM as described in Section 5.1.1.2 before accepting a message as valid. 5.1.1.1 Option Structure The Sig option indicates that certain CoAP Header Fields, Options, and Payload (if present) are integrity and replay protected using a Secure Signed Message (SSM). The Sig option SHALL contain a SSM with Detached Content (see Section 4.1.2.1). This option is critical, safe to forward, it is not part of a cache key, and it is not repeatable. Table 1 illustrates the structure of this option. Selander, et al. Expires September 10, 2015 [Page 10] INTERNET DRAFT Object Security for ACE March 9, 2015 +-----+---+---+---+---+---------+--------+-----------+ | No. | C | U | N | R | Name | Format | Length *) | +-----+---+---+---+---+---------+--------+-----------+ | TBD | x | | x | | Sig | opaque | 12-TBD | +-----+---+---+---+---+---------+--------+-----------+ C=Critical, U=Unsafe, N=NoCacheKey, R=Repeatable Table 1: The Sig Option *) Length is essentially Length(SSM Header) + Length(SSM Tag). The minimum length is estimated in Appendix C. The maximum length depends on actual message format selected and is TBD. 5.1.1.2 Integrity Protection and Verification A CoAP endpoint composing a message with the Sig option SHALL process the SSM and produce the SSM Tag, as defined in 5.1.1.3 and 5.1.3, analogously to the specification for producing a JWS object as described in Section 5.1 of [I-D.ietf-jose-json-web-signature] (cf. Appendix B). In addition, the sending endpoint SHALL process the Sequence Number as described in Section 5.3. A CoAP endpoint receiving a message containing the Sig option SHALL first recreate the SSM Body as described in Section 5.1.1.3, and then verify the SSM Tag as described in Section 5.1.3, analogously to the specification for verifying a JWS object as described in Section 5.2 of [I-D.ietf-jose-json-web-signature] (cf. Appendix B). In addition, the receiving endpoint SHALL process the Sequence Number as described in Section 5.3. NOTE: The explicit steps of the protection and verification procedure will be included in a future version of this draft. 5.1.1.3 SSM Body The SSM Body SHALL consist of the following data, in this order: o the 8-bit CoAP header field Code; o all CoAP options present which are marked as IP in Table 3 (Appendix A), in the order as given by the option number (each Option with Option Header including delta to previous IP-marked Option which is present); and o the CoAP Payload (if any). Selander, et al. Expires September 10, 2015 [Page 11] INTERNET DRAFT Object Security for ACE March 9, 2015 5.1.2 The Enc Option In order to encrypt and integrity protect CoAP messages, a new CoAP option is introduced: the Enc option, indicating the presence of a SEM Mode:COAP object in the CoAP message, containing the encrypted part of the CoAP message. Endpoints supporting this scheme MUST check for the presence of an Enc option, and verify the SEM as described in 5.1.2.2 before accepting a message as valid. NOTE: This version of the draft is only considering AEAD algorithms. 5.1.2.1 Option Structure The Enc option indicates that certain CoAP Options and Payload (if present) are encrypted, integrity and replay protected using a Secure Encrypted Message (SEM) with Detached Content (see Section 4.1.2.2). The structure of a CoAP message with an Enc option is described in Section 5.1.2.4. This option is critical, safe to forward, it is not part of a cache key, and it is not repeatable. Table 2 illustrates the structure of this option. +-----+---+---+---+---+---------+--------+-------------+ | No. | C | U | N | R | Name | Format | Length *) | +-----+---+---+---+---+---------+--------+-------------+ | TBD | x | | x | | Enc | opaque | 0 or 12-TBD | +-----+---+---+---+---+---------+--------+-------------+ C=Critical, U=Unsafe, N=NoCacheKey, R=Repeatable Table 2: The Enc Option *) Length indicates in this case the additional length added to the total length of all CoAP options. If the CoAP message has Payload, then the Enc option is empty, otherwise it contains the SEM (see Section 5.1.2.4). In the latter case, the SEM Ciphertext contains the encrypted CoAP Options (see Section 5.1.2.3), which are thus excluded from plaintext part of the message. Hence the additional length is essentially Length(SEM Header) + Length(SEM Tag). The minimum length is estimated in Appendix C. The maximum length depends on actual message format selected and is TBD. 5.1.2.2 Encryption and Decryption A CoAP endpoint composing a message with the Enc option SHALL process Selander, et al. Expires September 10, 2015 [Page 12] INTERNET DRAFT Object Security for ACE March 9, 2015 the SEM and produce the SEM Ciphertext and SEM Tag, as defined in 5.1.2.3 and 5.1.3, analogously to the specification for producing a JWE object as described in Section 5.1 of [I-D.ietf-jose-json-web- encryption] (cf. Appendix B). In addition, the sending endpoint SHALL process the Sequence Number as described in Section 5.3. A CoAP endpoint receiving a message containing the Enc option SHALL first recreate the SEM Body as described in Section 5.1.2.3, and then decrypt and verify the SEM analogously to the specification for verifying a JWE object as describe in Section 5.2 of [I-D.ietf-jose- json-web-encryption] (cf. Appendix B). In addition, the receiving endpoint SHALL process the Sequence Number as described in Section 5.3. NOTE: The explicit steps of the protection and verification procedure will be included in a future version of this draft. 5.1.2.3 SEM Body The SEM Plaintext SHALL consist of the following data, formatted as a CoAP message without Header consisting of: o all CoAP Options present which are marked as E in Table 3 (see Appendix A), in the order as given by the Option number (each Option with Option Header including delta to previous E-marked Option); and o the CoAP Payload, if present, and in that case prefixed by the one-byte Payload Marker (0xFF). The SEM Additional Authenticated Data SHALL consist of the following data, in this order: o the 8-bit CoAP header field Code; o all CoAP options present which are marked as IP and not marked as E in Table 2 (see Appendix A), in the order as given by the Option number (each Option with Option Header including delta to previous such Option). 5.1.2.4 CoAP Message with Enc Option An unprotected CoAP message is encrypted and integrity protected by means of an Enc option and a SEM. The structure and format of the protected CoAP message being sent instead of the unprotected CoAP message is now described. Selander, et al. Expires September 10, 2015 [Page 13] INTERNET DRAFT Object Security for ACE March 9, 2015 The protected CoAP message is formatted as an ordinary CoAP message, with the following Header, Options and Payload: o The CoAP header SHALL be the same as the unprotected CoAP message o The CoAP options SHALL consist of the unencrypted options of the unprotected CoAP message, and the Enc option. The options SHALL be formatted as in a CoAP message (each Option with Options Header including delta to previous unencrypted Option). o If the unprotected CoAP message has no Payload then the Enc option SHALL contain the SEM with Detached Content. If the unprotected CoAP message has Payload, then the SEM option SHALL be empty and the Payload of the CoAP message SHALL be the SEM with Detached Content. The Payload is prefixed by the one-byte Payload Marker (0xFF). 5.1.3 SM Tag This section describes the SM Tag for Mode:COAP, which applies both to SEM and SSM. The SM Tag is defined in 4.1.3. If the message is a CoAP Request, then EAD SHALL be empty. If the message is a CoAP Response, then EAD SHALL consist of the TID of the associated CoAP Request. 5.2 Application Layer Protection Referring to examples 1-3 in Section 2 and requirements a and b in Section 3, the case of only protecting Payload sent in a RESTful protocol using the Secure Message format is now discussed. This is called Secure Message Mode:APPL. The sending endpoint SHALL wrap the Payload, and the receiving endpoint unwrap the Payload in the relevant SM format (SSM or SEM) Mode:APPL. The SSM (SEM) SHALL be protected (encrypted) and verified (decrypted) as described in 5.1.1.2 (5.1.2.2), including replay protection as described in section 5.3. NOTE: The explicit steps of the protection and verification procedure will be included in a future version of this draft. For Mode:APPL, the EAD SHALL be empty. Hence, the SM Tag is calculated over the SM Header and SM Body. A CoAP message where the Payload is wrapped as a Secure Message Selander, et al. Expires September 10, 2015 [Page 14] INTERNET DRAFT Object Security for ACE March 9, 2015 Mode:APPL object is indicated by setting the option Content- Format to application/sm. A CoAP client may request a response containing such a payload wrapping by setting the option Accept to application/sm. (See Section 8.) 5.3 Replay Protection and Freshness In order to protect from replay of messages and verify freshness of responses, a CoAP endpoint SHALL maintain Transaction Identifiers (TIDs) of sent and received Secure Messages (see section 4.1.1). 5.3.1 Replay Protection An endpoint supporting Secure Message SHALL maintain two TIDs and associated security context/key(s) for each other endpoint it communicates with, one TID for protecting sent messages, and one TID for verifying the received messages. Depending on use case, an endpoint MAY maintain a sliding receive window for Sequence Numbers associated to TIDs in received messages, equivalent to the functionality described in section 4.1.2.6 of [RFC6347]. Before composing a new message a sending endpoint supporting Secure Message SHALL step the Sequence Number of the associated send TID and SHALL include it in the SM Header parameter Sequence Number as defined in section 4.1.1. However, if the Sequence Number counter wraps, the client must first acquire a new TID and associated security context/key(s). The latter is out of scope of this memo. A receiving endpoint supporting Secure Message SHALL verify that the Sequence Number received in the SM Header is greater than the Sequence Number in the TID for received messages (or within the sliding window and not previously received) and update the TID (window) accordingly. 5.3.2 Freshness If a CoAP server receives a valid Secure Message request in Mode:COAP, then the response SHALL include the TID of the request as EAD, as defined in section 5.1.3. If the CoAP client receives a Secure Message response in Mode:COAP, then the client SHALL verify the signature by reconstructing SM Body and using the TID of its own associated request as EAD, as defined in section 5.1.3. Selander, et al. Expires September 10, 2015 [Page 15] INTERNET DRAFT Object Security for ACE March 9, 2015 6. Security Considerations In scenarios with proxies, gateways, or caching, DTLS only protects data hop-by-hop meaning that all intermediary nodes can read and 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 make 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, e.g. 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. Secure Message Mode:COAP addresses point to point encryption, integrity and replay protection, and freshness of response. Payload as well as relevant options and header field Code are protected. It is possible to define unique session keys to enable perfect forward secrecy. Secure Message Mode:APPL only protects payload and only gives replay protection (not freshness), but this allows more use cases such as point to multi-point including publish-subscribe, reverse proxies and proxy caching of responses. In case of symmetric keys the receiver does not get data origin authentication, which requires a digital signature using a private asymmetric key. 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 Sig or Enc 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. The Version header field is not integrity protected to allow backwards compatibility with future versions of CoAP. Considering this, it may in theory be possible to launch a Selander, et al. Expires September 10, 2015 [Page 16] INTERNET DRAFT Object Security for ACE March 9, 2015 cross-version attack, e.g. something analogously to a bidding down attack. Future updates of CoAP would need to take this into account. The use of sequence numbers for replay protection introduces the problem related to wrapping of the counter. The alternatives also have issues: very constrained devices may not be able to support accurate time or 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. Independently of message format, and whether the target is application layer protection or CoAP message protection, this specification needs to be complemented with a procedure whereby the client and the server establish the keys used for wrapping and unwrapping the Secure Message. 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.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 which can be used in the Secure Message exchange. The security contexts required for SSM and SEM are different. For a SSM, the security context is essentially Algorithm, Key Identifier, Sequence Number and Key. For a SEM it is also required to have a unique AEAD Initialization Vector for each message. The AEAD Initialization Vector SHALL be the concatenation of a Salt (8 bytes unsigned integer) and the Sequence Number. The Salt SHOULD be established between sender and receiver before the message is sent, to avoid the overhead of sending it. For example, the Salt may be established by the same means as the keys used to secure the protocol between the sender and receiver. For a SEM, the security context is essentially Algorithm, Key Identifier, Salt, Sequence Number and Key. NOTE: This last paragraph will be moved into the main document in a future version of this draft. 7. Privacy Considerations End-to-end integrity protection provides certain privacy properties, e.g. protection of communication with sensor and actuator from manipulation which may affect the personal sphere. End-to-end encryption of payload and certain options provides Selander, et al. Expires September 10, 2015 [Page 17] INTERNET DRAFT Object Security for ACE March 9, 2015 additional protection as to the content and nature of the message exchange. The headers sent in plaintext allows for example matching of CON and ACK (CoAP Message Identifier), matching of request and response (Token). Plaintext options could also reveal information, e.g. lifetime of measurement (Max-age), or that this message contains one data point in a sequence (Observe). 8. IANA Considerations Note to RFC Editor: Please replace all occurrences of "[this document]" with the RFC number of this specification. The following entry is added to the CoAP Option Numbers registry: +--------+---------+-------------------+ | Number | Name | Reference | +--------+---------+-------------------+ | TBD | Sig | [[this document]] | +--------+---------+-------------------+ | TBD | Enc | [[this document]] | +--------+---------+-------------------+ NOTE: IANA considerations for Mode is TBD This document registers the following value in the CoAP Content Format registry established by [RFC7252]. Media Type: application/sm Encoding: - Id: 70 Reference: [this document] 9. Acknowledgements Klaus Hartke has independently been working on the same problem and a similar solution: establishing end-to-end security across proxies by adding a CoAP option. The authors would like to Selander, et al. Expires September 10, 2015 [Page 18] INTERNET DRAFT Object Security for ACE March 9, 2015 thank Francesca Palombini for contributing to the discussion and giving helpful implementation input to the specification. We are grateful to Malisa Vucinic for providing many helpful comments. 10. References 10.1 Normative References [I-D.ietf-jose-json-web-signature] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Signature (JWS)", draft-ietf-jose-json-web-signature-41 (work in progress), January 2015. [I-D.ietf-jose-json-web-encryption] Jones, M., and J. Hildebrand, "JSON Web Encryption (JWE)", draft-ietf-jose-json-web-encryption-40 (work in progress), January 2015. [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 Application Protocol (CoAP)", RFC 7252, June 2014, . 10.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-02 (work in progress), May 2015. [I-D.ietf-ace-usecases] Seitz, L., Gerdes, S., Selander, G., Mani, M., and S. Kumar, "ACE use cases", draft-ietf-ace-usecases-02 (work in progress), February 2015. [I-D.bormann-jose-cose] Bormann, C., "Constrained Object Signing and Encryption Selander, et al. Expires September 10, 2015 [Page 19] INTERNET DRAFT Object Security for ACE March 9, 2015 (COSE)", draft-bormann-jose-cose-00 (work in progress, October 2014 [I-D.ietf-core-coap-block] Bormann, C., and Z. Shelby, "Blockwise transfers in CoAP", draft-ietf-core-block-17 (work in progress), March 2015. [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 Transfer Protocol (HTTP/1.1): Semantics and Content", RFC 7231, June 2014, . [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an Attack", BCP 188, RFC 7258, May 2014, . Appendix A. Which CoAP Header Fields and Options to Protect In the case of CoAP Message Protection (Mode:COAP) as much as possible of the CoAP message is protected. However, not all CoAP header fields or options can be encrypted and integrity protected, because some are intended to be read or changed by an intermediary node. A.1 CoAP Header Fields The CoAP Message Layer parameters, Type and Message ID, as well as Token and Token Length may be changed by a proxy and thus SHALL neither be integrity protected nor encrypted. Example 5 in Section 2 shows that the Code SHALL be integrity protected. The Version parameter SHALL neither be integrity protected nor encrypted (see Section 6). A.2 CoAP Options Selander, et al. Expires September 10, 2015 [Page 20] INTERNET DRAFT Object Security for ACE March 9, 2015 This section describes what options need to be integrity protected and encrypted. On a high level, all CoAP options must be encrypted by default, unless intended to be read by an intermediate node; and integrity protected, unless intended to be changed by an intermediate node. However, some special considerations are necessary because CoAP defines certain legitimate proxy operations, because the security information itself may be transported as an option, and because different processing is performed for SSM and SEM. A.2.1 Integrity Protection As a general rule, CoAP options which are Safe-to-Forward SHALL be integrity protected, with the only exception being Enc and Sig, which are the security-providing options. The Unsafe options are divided in two categories, those that are intended to change in a way that can be reconstructed by the server, and those which are not. The following options are of the latter kind and SHALL NOT be integrity protected: Max-Age, Observe, Proxy- Scheme. These options are intended to be changed by a proxy. For options related to URI of resource (Uri-Host, Uri-Port, Uri-Path, Uri-Query, Proxy-Uri) a Forward Proxy is intended to replace the Uri- * options with the content of the Proxy-Uri option. These options are Unsafe, but the Forward Proxy is intended to perform this precise operation and we can use this predictability to integrity protect the destination endpoint URI, even if the options where the information elements of the URI is located is changed by the Proxy. This memo makes the full URI located in option 35 (Proxy-Uri) into a common denominator for the URI integrity, as described in the following. The following processing applies to a SSM, for SEM see next section: o If there is a Proxy-Uri present, then the client MUST integrity protect the Proxy-Uri option and the Uri-* options MUST NOT be integrity protected. o If there is no Proxy-Uri option present, then the client SHALL compose the full URI from Uri-* options according to the method described in section 6.5 of [RFC7252]. The SM Tag is calculated on the following message, modified compared to what is sent: o All Uri-* options removed o A Proxy-Uri option with the full URI included Selander, et al. Expires September 10, 2015 [Page 21] INTERNET DRAFT Object Security for ACE March 9, 2015 The server SHALL compose the URI from the Uri-* options according to the method described in section 6.5 of [RFC7252]. The so obtained URI is placed into a Proxy-Uri option (no. 35), which is included in the integrity verification. A.2.2 Encryption All CoAP options MUST be encrypted, except the options below which MUST NOT be encrypted: o Max-Age, Observe: This information is intended to be read by a proxy. o Enc, Sig: These are the security-providing options. o Uri-Host, Uri-Port: This information can be inferred from destination IP address and port. o Proxy-Uri, Proxy-Scheme: This information is intended to be read by a proxy. In the case of a SEM, the Proxy-Uri MUST only contain Uri-Host and Uri-Port and MUST NOT contain Uri-Path and Uri-Query because the latter options are not intended to be revealed to a Forward Proxy. A.2.3 Summary Table 3 summarizes which options are encrypted and integrity protected, if present. In a SSM, options marked with "a" and "b" are composed into a URI as described above and included as the Proxy-Uri option which is part of the SSM Body. In a SEM, options marked "a" are composed into a URI as described above and included as the Proxy-Uri option in the SEM Additional Authenticated Data. +-----+---+---+---+---+----------------+--------+--------+--------+ | No. | C | U | N | R | Name | Format | Length | E | IP | +-----+---+---+---+---+----------------+--------+--------+--------+ | 1 | x | | | x | If-Match | opaque | 0-8 | x | x | | 3 | x | x | - | | Uri-Host | string | 1-255 | | a | | 4 | | | | x | ETag | opaque | 1-8 | x | x | | 5 | x | | | | If-None-Match | empty | 0 | x | x | | 6 | | x | - | | Observe | uint | 0-3 | | | Selander, et al. Expires September 10, 2015 [Page 22] INTERNET DRAFT Object Security for ACE March 9, 2015 | 7 | x | x | - | | Uri-Port | uint | 0-2 | | a | | 8 | | | | x | Location-Path | string | 0-255 | x | x | | 11 | x | x | - | x | Uri-Path | string | 0-255 | x | b | | 12 | | | | | Content-Format | uint | 0-2 | x | x | | 14 | | x | - | | Max-Age | uint | 0-4 | | | | 15 | x | x | - | x | Uri-Query | string | 0-255 | x | b | | 17 | x | | | | Accept | uint | 0-2 | x | x | | 20 | | | | x | Location-Query | string | 0-255 | x | x | | 35 | x | x | - | | Proxy-Uri | string | 1-1034 | | x | | 39 | x | x | - | | Proxy-Scheme | string | 1-255 | | | | 60 | | | x | | Size1 | uint | 0-4 | x | x | +-----+---+---+---+---+----------------+--------+--------+--------+ C=Critical, U=Unsafe, N=NoCacheKey, R=Repeatable, E=Encrypt, IP=Integrity Protect. Table 3: Protected CoAP options in Mode=COAP. Appendix B. JOSE Objects as Secure Messages This section shows how to extend JWS and JWE to Secure Message formats (see Section 4.1). The use of compact serialization is assumed. B.1 JWS as Secure Signed Message The JOSE Header of JWS contains the mandatory parameter "alg", defined in Section 4.1.1 of [I-D.ietf-jose-json-web-signature], which corresponds to the parameter Algorithm of the Secure Message. A JWS is a Secure Message if the JOSE Header includes o the Parameter "kid" defined in Section 4.1.4 of [I-D.ietf-jose- json-web-signature]; o the new Parameter "seq" defined in B.3; and o the new Parameter "mod" defined in B.4. In case of JWS, a SSM with Detached Content consists of the JOSE Header and JWS Signature; i.e. no JWS Payload. B.2 JWE as Secure Encrypted Message In case of JWE, the SM Header parameters of a JWE consists of the JOSE Header Parameters and JWE Initialization Vector (IV). Selander, et al. Expires September 10, 2015 [Page 23] INTERNET DRAFT Object Security for ACE March 9, 2015 The JOSE Header of JWE contains the mandatory parameter "enc", defined in Section 4.1.2 of [I-D.ietf-jose-json-web-encryption], which corresponds to the parameter Algorithm of the Secure Message. The JOSE Header also contains the mandatory parameter "alg", the key encryption algorithm, which in the current version of the draft is assumed to be equal to "dir" (constant). It is also assumed that plaintext compression (zip) is not used. A JWE is a Secure Message if the IV contains the SM Sequence Number, and the JOSE Header includes o the Parameter "kid" defined in Section 4.1.4 of [I-D.ietf-jose- json-web-signature]; and o the new Parameter "mod" defined in B.4. The IV also contain a Salt (see Section 6). For JWE it is mandatory to include the IV and hence the Salt is sent in each message. In case of JWE, a SEM with Detached Content consists of JOSE Header, JWE Initialization Vector, JWE Ciphertext and JWE Authentication Tag; i.e. no JWE AAD. B.3 "seq" (Sequence Number) Header Parameter The Sequence Number SHALL be a 64-bit unsigned integer in hexadecimal representation. Only the significant bytes are sent (initial bytes with zeros are removed). The start sequence number SHALL be 0. For a given key, any Sequence Number MUST NOT be used more than once. The parameter "seq" SHALL be marked as critical using the "crit" header parameter (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 message. B.4 "mod" (Mode) Header Parameter The Mode parameter SHALL be an 8-byte unsigned integer defining application specific message format, content and processing. The parameter "mod" SHALL be marked as critical. "mod":"0" indicates Mode:APPL which is defined in Section 5.2. "mod":"1" indicates Mode:COAP which is defined in Section 5.1. B.4 The TID consists of the concatenation of SEQ and KID, in that order, formatted as in the JOSE. For "seq" the initial bytes with zeros are removed. Selander, et al. Expires September 10, 2015 [Page 24] INTERNET DRAFT Object Security for ACE March 9, 2015 Appendix C. Compact Secure Message For constrained environments it is important that the message expansion due to security overhead is kept at a minimum. As an attempt to assess what this minimum expansion could be, an optimized Secure Message format is defined, tailor-made for this setting. This is intended as a benchmark for generic content formats, to allow an informed decision about which Secure Message format to mandate in a future version of this draft. C.1 CSM Format This section defines a compact Secure Message format (see Section 4.1) called the Compact Secure Message (CSM) format, see Figure 4. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | M | ALG | KL | SL | KID ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ SEQ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Body ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Tag ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: Compact Secure Message format The CSM Header (see Section 4.1.1.) consists of 2 bytes of fixed length parameters and two variable length parameters, Key Identifier (KID) and Sequence Number (SEQ). The Header parameters are (compare Table 5): o Mode (M). M=0 indicates Mode:APPL as defined in Section 5.2. M=1 indicates Mode:COAP as defined in Section 5.1. M=2 and M=3 are reserved for future use. o Algorithm (ALG). This parameter consists of an encoding of the ciphersuite used in the Secure Message. The encoding is TBD. o KID Length (KL). This parameter consist of a length indication of the header parameter Key Identifier. The actual length of KID is KL + 1 bytes. o SEQ Length (SL). This parameter consist of a length indication of the header parameter Sequence Number. The actual length of Selander, et al. Expires September 10, 2015 [Page 25] INTERNET DRAFT Object Security for ACE March 9, 2015 SEQ is SL + 1 bytes. o Key Identifier (KID). This parameter identifies the key(s) used to protect the Secure Message. Only the significant bytes are sent (initial bytes with zeros are removed). o Sequence Number (SEQ). This parameter consists of the sequence number used by the sender of the Secure Message. Only the significant bytes are sent (initial bytes with zeros are removed). +------+-------------------------+--------------------+ | Name | Parameter | Length | +------+-------------------------+--------------------+ | M | Mode | 2 bits | +------+-------------------------+--------------------+ | ALG | Algorithm | 6 bits | +------+-------------------------+--------------------+ | KL | Key Identifier Length | 5 bits | +------+-------------------------+--------------------+ | SL | Sequence Number Length | 3 bits | +------+-------------------------+--------------------+ | KID | Key Identifier | KL + 1: 1-32 bytes | +------+-------------------------+--------------------+ | SEQ | Sequence Number | SL + 1: 1-8 bytes | +------+-------------------------+--------------------+ Table 5: CSM Header Parameters. The minimum CSM Header is 4 bytes. The TID consists of the concatenation of SEQ and KID, in that order, formatted as in the CSM format (initial bytes with zeros are removed). The content of CSM Body depends on whether it is a SSM or a SEM (see Section 4.1.2) which is determined by the Algorithm. This version of the draft focuses on Secure Message with Detached Content. Hence, the SSM Body is empty and the SEM Body consists of the Ciphertext. In the former case, the length of the CSM Body is 0. In the latter case, the length of the CSM Body equals the sum of the lengths of the present CoAP options marked encrypted in Table 3 and the length of the payload of the unprotected CoAP message. The CSM Tag contains the MAC/Signature as determined from the Algorithm. The length is determined by ALG. Selander, et al. Expires September 10, 2015 [Page 26] INTERNET DRAFT Object Security for ACE March 9, 2015 C.2 Comparison of Secure Message sizes This section gives some examples of overhead incurred with JOSE, the current proposal for COSE at the time of writing (00-draft), and CSM. The goal is not to give exact measurements, but to help the reader appreciate the rough order of magnitude of the overhead involved. COSE seems to be the most promising approach and CSM should be viewed as an attempt to define a lower bound for COSE. The comparison is complicated further by the fact that algorithms suitable for constrained environments are not supported by JOSE, and thereby not by COSE. This comparison does not consider the ciphertext or signed payload expansion due to Base64url encoding in JWS/JWE. This would increase the overhead of JWS and JWE even more. The size of the header is shown separately from the size of the authentication tag, since JWS/JWE has no provisions for truncating it, a feature that could easily be added to the JOSE specifications. For CSM the encoding of certain additional algorithms is assumed and this could also easily be added to COSE. An 8-byte kid is used throughout all examples. Finally compact serialization for both JWS and JWE is assumed. SSM uses HMAC-SHA256, with truncation to 16 bytes. For JWS the following header is used: {"alg":"HS256", "kid":"a1534e3c5fdc09bd", "seq":"00000142", "mod":"0"} which encodes to a size of 90 bytes in Base64url, and the 32 bytes of HS256 MAC encode to 43 bytes. The concatenation marks add 2 bytes to that in the total overhead. The same header in COSE, representing the "kid" as bytes (not as string) and the "seq" as positive integer encodes to a size of 35 bytes, and the MAC would add to 32 bytes to that. Note that encoding the header and the MAC together incurs an additional overhead of 3 bytes. For CSM the same header is represented by 12 bytes. The MAC could in this case safely be truncated to 16 bytes, and a corresponding algorithm identifier would need to be defined in the list of supported algorithms. Table 6 summarizes these results. Selander, et al. Expires September 10, 2015 [Page 27] INTERNET DRAFT Object Security for ACE March 9, 2015 +--------+----------------+----------------+ | Scheme | Header | MAC | Total Overhead | +--------+----------------+----------------+ | JWS | 90 B | 43 B | 135 bytes | +--------+---------+------+----------------+ | COSE | 35 B | 32 B | 70 bytes | +--------+---------------------------------+ | CSM | 12 B | 16 B | 28 bytes | +--------+---------------------------------+ Table 6: Comparison of JWS, COSE, and CSM For SEM the use of AES-128-CCM-8 would be ideal, but since this is not supported by JOSE, AES-128-GCM is used there instead. For JWE it is assumed that the IV is generated from the sequence number and some previously agreed upon Salt. This means it is not required to explicitly send the IV in the CSM format, but also that the JWE and COSE formats can omit the sequence number. The JWE header {"alg":"dir", "kid":"a1534e3c5fdc09bd", "enc":"A128GCM", "mod":"0"} encodes to a size of 86 bytes in Base64url, while the necessary 12 byte IV for GCM mode is expanded to 16 bytes by encoding. The 16 bytes of the authentication tag expand to 22 bytes. The concatenation marks add 3 bytes to the total overhead. In COSE the same header encodes to 40 bytes and the IV and authentication tag could be represented as 12 and 16 bytes respectively. Note that encoding the header, the IV and the authentication tag together incurs an additional overhead of 2 bytes. For CSM this tests uses CCM mode instead of GCM. CCM requires a 16 byte IV, but is better suited for constrained devices, and for CSM there is no impact since the IV can be deduced from the sequence number and a previously agreed upon Salt. The corresponding header for AES-128-CCM-8, including the 8 byte sequence number, is represented by 12 bytes. Table 7 summarizes these results. +--------+----------------+-------+----------------+ | Scheme | Header | IV | Tag | Total Overhead | +--------+----------------+-------+----------------+ Selander, et al. Expires September 10, 2015 [Page 28] INTERNET DRAFT Object Security for ACE March 9, 2015 | JWE | 86 B | 16 B | 22 B | 127 bytes | +--------+---------+------+-------+----------------+ | COSE | 40 B | 12 B | 16 B | 70 bytes | +--------+------------------------+----------------+ | CSM | 12 B | 0 B | 8 B | 20 bytes | +--------+------------------------+----------------+ Table 7: Comparison of JWE, COSE, and CSM Appendix D. Examples This section gives examples of how to use the new options and message formats defined in this memo. D.1 CoAP Message Protection This section illustrates the Secure Message Mode:COAP. The message exchange assumes there is a security context established between client and server. One key is used for each direction of the message transfer. The intermediate node detects that the CoAP message contains a SM Mode:COAP object (Sig or Enc option is set) and thus forwards the message as it cannot serve a cached response. D.1.1 Integrity protection of CoAP Message Here is an example of a PUT request/response message exchange passing an intermediate node protected with the Sig option. The example illustrates a client opening a lock and getting a confirmation that the lock is opened. Code, Uri-Path and Payload are integrity protected (see Appendix A). Client Proxy Server | | | | | | | | | +----->| | Code: 0.03 (PUT) | PUT | | Token: 0x8c | | | Uri-Path: lock | | | Sig: SSM {"mod"="1","seq":"00000142", | | | "kid":"a1534e3c5fdc09bd", ...} | | | Payload: 1 | | | | +----->| Code: 0.03 (PUT) | | PUT | Token: 0x7b | | | Uri-Path: lock | | | Sig: SSM {"mod"="1","seq":"00000142", Selander, et al. Expires September 10, 2015 [Page 29] INTERNET DRAFT Object Security for ACE March 9, 2015 | | | "kid":"a1534e3c5fdc09bd", ...} | | | Payload: 1 | | | | | | | |<-----+ Code: 2.04 (Changed) | | 2.04 | Token: 0x7b | | | Sig: SSM {"mod"="1","seq":"000000a6", | | | "kid":"5fdc09bda1534e3c", ...} | | | |<-----+ | Code: 2.04 (Changed) | 2.04 | | Token: 0x8c | | | Sig: SSM {"mod"="1","seq":"000000a6", | | | "kid":"5fdc09bda1534e3c", ...} | | | Figure 8: CoAP PUT protected with Sig/SSM (Mode:COAP) The Key Identifier is a hint to the receiver indicating which security context was used to integrity protect the message, 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.) The server and client can verify that the Sequence Number has not been received and used with this key before, and since Mode is COAP, the client can additionally verify the freshness of the response, i.e. that the response message is generated as an answer to the received request message (see Section 5.3). The SSM also contains the Tag as specified in the Algorithm (not shown). This example deviates from encryption (SEM) by default (see Section 6) just to illustrate the Sig option. If there is no compelling reason why the CoAP message should be in plaintext, then the Enc option must be used. D.1.2 Encryption of CoAP Message Here is an example of a GET request/response message exchange passing an intermediate node protected with the Enc option. The example illustrates a client requesting a blood sugar measurement resource (GET /glucose) and receiving the value 220 mg/dl. Uri-Path and Payload are encrypted and integrity protected. Code is integrity protected only (see Appendix A). Client Proxy Server | | | | | | Selander, et al. Expires September 10, 2015 [Page 30] INTERNET DRAFT Object Security for ACE March 9, 2015 | | | +----->| | Code: 0.01 (GET) | GET | | Token: 0x83 | | | Enc: SEM {"mod"="1","seq":"000015b7", | | | "kid":"34e3c5fdca1509bd", | | | ["glucose" ... ], ...} | | | | +----->| Code: 0.01 (GET) | | GET | Token: 0xbe | | | Enc: SEM {"mod"="1","seq":"000015b7", | | | "kid":"34e3c5fdca1509bd", | | | ["glucose" ... ], ...} | | | | | | | |<-----+ Code: 2.05 (Content) | | 2.05 | Token: 0xbe | | | Enc: | | | Payload: SEM {"mod"="1","seq":"000015b7", | | | "kid":"c09bda155fd34e3c", | | | [... 220], ...} | | | |<-----+ | Code: 2.05 (Content) | 2.05 | | Token: 0x83 | | | Enc: | | | Payload: SEM {"mod"="1","seq":"000015b7", | | | "kid":"c09bda155fd34e3c", | | | [... 220], ...} | | | Figure 9: CoAP GET protected with Enc/SEM (Mode:COAP). The bracket [ ... ] indicates encrypted data. Since the request message (GET) does not support payload, the SEM is carried in the Enc option. Since the response message (Content) supports payload, the Enc option is empty and the SEM is carried in the payload. The Key Identifier is a hint to the receiver indicating which security context was used to encrypt and integrity protect the message, and may be used as an identifier for the AEAD secret key. One key is used for each direction of the message transfer. The server and client can verify that the Sequence Number has not been received and used with this key before, and since Mode:COAP the client can additionally verify the freshness of the response, i.e. that the response message is generated as an answer to the received request message (see Section 5.3). Selander, et al. Expires September 10, 2015 [Page 31] INTERNET DRAFT Object Security for ACE March 9, 2015 The SEM also contains the Tag as specified by the Algorithm (not shown). D.2 Application Layer Protection This section gives examples that illustrate Secure Message Mode:APPL. This mode assumes that only the intended receiver(s) has the relevant security context related to the resource. D.2.1 Proxy Caching This example outlines how a proxy forwarding request and response of one client can cache a response whose payload is a SEM object, and serve this response to another client request, such that both clients can verify integrity and non-replay. Client1 Proxy Server | | | | | | +----->| | Code: 0.01 (GET) | GET | | Token: 0x83 | | | Proxy-Uri: example.com/temp | | | | | | | +----->| Code: 0.01 (GET) | | GET | Token: 0xbe | | | Uri-Host: example.com | | | Uri-Path: temp | | | | | | | |<-----+ Code: 2.05 (Content) | | 2.05 | Token: 0xbe | | | Payload: SEM {"mod"="0","seq":"000015b7", | | | "kid":"c09bda155fd34e3c", | | | ["471 F"], ...} | | | |<-----+ | Code: 2.05 (Content) | 2.05 | | Token: 0x83 | | | Payload: SEM {"mod"="0","seq":"000015b7", | | | "kid":"c09bda155fd34e3c", | | ["471 F"], ...} Client2 | | | | | | | | | | +----->| | Code: 0.01 (GET) Selander, et al. Expires September 10, 2015 [Page 32] INTERNET DRAFT Object Security for ACE March 9, 2015 | GET | | Token: 0xa1 | | | Proxy-Uri: example.com/temp | | | |<-----+ | Code: 2.05 (Content) | 2.05 | | Token: 0xa1 | | | Payload: SEM {"mod"="0","seq":"000015b7", | | | "kid":"c09bda155fd34e3c", | | | ["471 F"], ...} Figure 10: Proxy caching protected with SEM (Mode:APPL) D.2.2 Publish-Subscribe This example outlines a publish-subscribe setting where the payload is integrity and replay protected end-to-end between Publisher and Subscriber. The example illustrates a subscription registration and a new publication of birch pollen count of 300 per cubic meters. The PubSub Broker can define the Observe count arbitrarily (as could any intermediary node, even in Mode:COAP), but cannot manipulate the Sequence Number without being noticed. Sub- PubSub- Publisher scriber Broker | | | +----->| | Code: 0.01 (GET) | GET | | Token: 0x72 | | | Uri-Path: ps | | | Uri-Path: birch-pollen | | | Observe: 0 (register) | | | | | | |<-----+ | Code: 2.05 (Content) | 2.05 | | Token: 0x72 | | | Observe: 1 | | | Payload: SSM {"mod"="0","seq":"000015b7", | | | "kid":"c09bda155fd34e3c", | | | ["270"], ...} | | | | | | | | | | |<-----+ Code: 0.03 (PUT) | | PUT | Token: 0x1f | | | Uri-Path: ps | | | Uri-Path: birch-pollen | | | Payload: SSM {"mod"="0","seq":"000015b8", Selander, et al. Expires September 10, 2015 [Page 33] INTERNET DRAFT Object Security for ACE March 9, 2015 | | | "kid":"c09bda155fd34e3c", | | | ["300"], ...} | | | | +----->| Code: 2.04 (Changed) | | 2.04 | Token: 0x1f | | | | | | |<-----+ | Code: 2.05 (Content) | 2.05 | | Token: 0x72 | | | Observe: 2 | | | Payload: SSM {"mod"="0","seq":"000015b8", | | | "kid":"c09bda155fd34e3c", | | | ["300"], ...} Figure 11: Publish-subscribe protected with SSM (Mode:APPL) This example deviates from encryption (SEM) by default (see Section 6) just to illustrate the SSM in Mode:APPL. If there is no compelling reason why the payload should be in plaintext, then SEM must be used. D.2.3 Transporting Authorization Information This example outlines the transportation of authorization information from a node producing (Authorization Server, AS) to a node consuming (Resource Server, RS) such information. Authorization information may for example be an authorization decision with respect to a Client (C) accessing a Resource to be enforced by RS. See Section 4.4-4.5 of [I-D.seitz-ace-problem-description]. Here, C is clearly not trusted with modifying the information, but may need to be involved with mediating the authorization information to the RS, for example, because AS and RS does not have direct connectivity. So end-to-end security is required and object security is a natural candidate (cf. "Access Tokens"). This example considers the authorization information to be encapsulated in a SEM Mode:APPL object, generated by AS. How C accesses the SSM is out of scope for this example, it may e.g. be using CoAP. C then requests RS to configure the authorization information in the SEM by doing PUT to /authorization. This particular resource has a default access policy that only new messages signed by AS are authorized. RS thus verifies the integrity and sequence number by using the existing security context for the AS, and responds accordingly, a) or b), see Figure 12. Authz Resource Server Client Server Selander, et al. Expires September 10, 2015 [Page 34] INTERNET DRAFT Object Security for ACE March 9, 2015 | | | | | | Client access Access Token: +- - ->| | SEM {"mod"="0","seq":"00000142", | | | "kid":"c09bda1534e3c5fdc09bd", ...} | | | | | | | +----->| Code: 0.03 (PUT) | | PUT | Token: 0xac | | | Uri-Path: authorization | | | Payload: SEM {"mod"="0","seq":"00000142", | | | "kid":"c09bda1534e3c5fdc09bd", ...} a) | | | | |<-----+ Code: 2.04 (Changed) | | 2.04 | Token: 0xac | | | b) | | | | |<-----+ Code: 4.01 (Unauthorized) | | 4.01 | Token: 0xac | | | Figure 12: Protected Transfer of Access Token = SEM (Mode:APPL) Authors' Addresses Goeran Selander Ericsson Farogatan 6 16480 Kista SWEDEN EMail: goran.selander@ericsson.com John Mattsson Ericsson Farogatan 6 16480 Kista SWEDEN EMail: john.mattsson@ericsson.com Ludwig Seitz SICS Swedish ICT AB Scheelevagen 17 22370 Lund SWEDEN Selander, et al. Expires September 10, 2015 [Page 35] INTERNET DRAFT Object Security for ACE March 9, 2015 EMail: ludwig@sics.se Selander, et al. Expires September 10, 2015 [Page 36]