Network Working Group J. Arkko Internet-Draft A. Keranen Intended status: Informational Ericsson Expires: January 27, 2012 July 26, 2011 CoAP Security Architecture draft-arkko-core-security-arch-00 Abstract Constrained Application Protocol (CoAP) is a light-weight protocol designed to be used in machine-to-machine applications. This memo describes challenges associated with securing CoAP and proposes a new security model that the authors believe is suitable for these environments. The model requires minimal amount of configuration, but still provides strong security and is a natural fit with the typical communication practices smart object networking environments. This memo also proposes JSON payload format extensions to support the architecture. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on January 27, 2012. Copyright Notice Copyright (c) 2011 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 carefully, as they describe your rights and restrictions with respect Arkko & Keranen Expires January 27, 2012 [Page 1] Internet-Draft CoAP Security July 2011 to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Related Work . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Challenges . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Proposed Architecture . . . . . . . . . . . . . . . . . . . . 6 4.1. Provisioning . . . . . . . . . . . . . . . . . . . . . . . 6 4.2. Device Groups . . . . . . . . . . . . . . . . . . . . . . 7 4.3. Protocol Architecture . . . . . . . . . . . . . . . . . . 8 4.4. Actuator Networking . . . . . . . . . . . . . . . . . . . 9 5. Proposed Protocol Extensions . . . . . . . . . . . . . . . . . 10 5.1. Identity Format . . . . . . . . . . . . . . . . . . . . . 10 5.2. Identity Generation . . . . . . . . . . . . . . . . . . . 11 5.2.1. Identifier Groups . . . . . . . . . . . . . . . . . . 13 5.3. JSON Identity . . . . . . . . . . . . . . . . . . . . . . 13 5.3.1. The id Field . . . . . . . . . . . . . . . . . . . . . 13 5.3.2. The ipb Field . . . . . . . . . . . . . . . . . . . . 13 5.4. JSON Signature Envelope . . . . . . . . . . . . . . . . . 14 5.4.1. The jmsg Field . . . . . . . . . . . . . . . . . . . . 14 5.4.2. The jid Field . . . . . . . . . . . . . . . . . . . . 15 5.4.3. The jts Field . . . . . . . . . . . . . . . . . . . . 15 5.4.4. The jsq Field . . . . . . . . . . . . . . . . . . . . 15 5.4.5. The jsig Field . . . . . . . . . . . . . . . . . . . . 15 6. Concluding Remarks . . . . . . . . . . . . . . . . . . . . . . 16 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 9.1. Normative References . . . . . . . . . . . . . . . . . . . 18 9.2. Informative References . . . . . . . . . . . . . . . . . . 19 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 Arkko & Keranen Expires January 27, 2012 [Page 2] Internet-Draft CoAP Security July 2011 1. Introduction Constrained Application Protocol (CoAP) [I-D.ietf-core-coap] is a light-weight protocol designed to be used in machine-to-machine applications such as smart energy and building automation. This memo describes implementation and operational challenges associated with securing CoAP in these environments (Section 3), reviews related work in solving these challenges (Section 2), and proposes a security model (Section 4) that the authors believe is suitable for many machine-to-machine application environments. The model requires minimal amount of configuration, but still provides strong security and is a natural fit with the typical communication practices smart object networking environments. Finally, this memo proposes some protocol and payload format extensions to support the architecture (Section 5). Section 6 provides a summary of the approach. 2. Related Work CoAP base specification [I-D.ietf-core-coap] outlines how to use DTLS [RFC5238] and IPsec [RFC4306] for securing the protocol. DTLS can be applied with group keys, pairwise shared keys, or with certificates. The security model in all cases is mutual authentication, so while there is some commonality to HTTP in verifying the server identity, in practice the models are quite different. The specification says little about how DTLS keys are managed. The IPsec mode is described with regards to the protocol requirements, noting that small implementations of IKEv2 exist [I-D.kivinen-ipsecme-ikev2-minimal]. However, the specification is silent on policy and other aspects that are normally necessary in order to implement interoperable use of IPsec in any environment [RFC5406]. [I-D.garcia-core-security] discusses the overall security problem for Internet of Things devices. It also discusses various solutions, including IKEv2/IPsec [RFC4306], TLS/SSL [RFC5246], DTLS [RFC5238], HIP [RFC5201] [I-D.ietf-hip-rfc5201-bis] [I-D.moskowitz-hip-rg-dex], PANA [RFC5191], and EAP [RFC3748]. The draft also discusses various operational scenarios, bootstrapping mechanisms, and challenges associated with implementing secity mechanisms in these environments. [I-D.iab-smart-object-workshop] gives an overview of the security discussions at the March 2011 IAB workshop on smart objects. The workshop recommended that additional work is needed in developing suitable credential management mechanisms (perhaps something similar Arkko & Keranen Expires January 27, 2012 [Page 3] Internet-Draft CoAP Security July 2011 to the Bluetooth pairing mechanism), understanding the implementability of standard security mechanisms in small devices (see, for instance, [I-D.kivinen-ipsecme-ikev2-minimal]), and additional research in the area of lightweight cryptographic primitives. [I-D.sarikaya-core-sbootstrapping] discusses the bootstrapping problem with low-powered nodes, and argues that this problem should be solved at a general level and not left to link layer specific mechanisms. The draft looks at EAP [RFC3748], PANA [RFC5191], HIP Diet Exchange (HIP-DEX) [I-D.moskowitz-hip-rg-dex], and 802.1X [IEEE.802-1X.2010] as potential solutions for bootstrapping. [I-D.moskowitz-hip-rg-dex] defines a light-weight version of the HIP protocol for low-power nodes. This version uses a fixed set of algorithms, elliptic curve cryptography, and eliminates hash functions. The protocol still operates based on host identities, and runs end-to-end between hosts, protecting IP layer communications. [RFC6078] describes an extension of HIP that can be used to send upper layer protocol messages without running the usual HIP base exchange at all. [I-D.daniel-6lowpan-security-analysis] makes a comprehensive analysis of security issues related to 6LOWPAN networks, but its findings also apply more generally for all low-powered networks. Some of the issues this document discusses include the need to minimize the number of transmitted bits and simplify implementations, threats in the smart object networking environments, and the suitability of 6LOWPAN security mechanisms, IPsec, and key management protocols for implementation in these environments. Cryptographically Generated Addresses (CGAs) [RFC3972] and Host Identity Protocol (HIP) [RFC5201] have employed similar ideas as those proposed in this memo, though with slightly different purpose in mind, and at a different protocol layer. Similarly, PGP [RFC4880] and other similar tools have popularized the concept of exchanging key fingerprint values off-line. This is very similar to what is proposed in this memo. [I-D.rescorla-jsms], [I-D.jones-json-web-signature], and [I-D.jones-json-web-token] propose JSON extensions similar to those discussed in this memo, though constructed for other purposes. Further work is needed to analyze if these proposals could be used as a basis for smart object security communication security as well. Obviously, general-purpose JSON signature mechanisms should be used if they exist, even if some additional data elements might have to be defined to carry all the information that this memo requires. Arkko & Keranen Expires January 27, 2012 [Page 4] Internet-Draft CoAP Security July 2011 3. Challenges This section discusses three challenges: implementation difficulties, practical provisioning problems, and layering and communication models. The most often discussed issues in the security for the Internet of Things relates to implementation difficulties. The desire to build small, battery-operated, and inexpensive devices drives the creation of devices with a limited protocol and application suite. Some of the typical limitations include running CoAP instead of HTTP, limited support for security mechanisms, limited processing power for long key lengths, sleep schedule that does not allow communication at all times, and so on. In addition, the devices typically have very limited support for configuration, making it hard to set up secrets and trust anchors. The implementation difficulties are important, but they should not be overemphasized. It is important to select the right security mechanisms and avoid duplicated or unnecessary functionality. But at the end of the day, if strong cryptographic security is needed, the implementations have to support that. Also, the use of the most lightweight algorithms and cryptographic primitives is useful, but should not be the only consideration in the design. Interoperability is also important, and often other parts of the system, such as key management protocols or certificate formats are heavier to implement than the algorithms themselves. The second challenge relates to practical provisioning problems. These are perhaps the most fundamental and difficult issue, and unfortunately often neglected in the design. There are several problems in the provisioning and management of smart object networks: o Small devices have no natural user interface for configuration that would be required for the installation of shared secrets and other security-related parameters. Typically, there is no keyboard, no display, and there may not even be buttons to press. Some devices may only have one interface, the interface to the network. o Manual configuration is rarely, if at all, possible, as the necessary skills are missing in typical installation environments (such as in family homes). o There may be a large number of devices. Configuration tasks that may be acceptable when performed for one device may become unacceptable with dozens or hundreds of devices. Arkko & Keranen Expires January 27, 2012 [Page 5] Internet-Draft CoAP Security July 2011 o Network configurations evolve over the lifetime of the devices, as additional devices are introduced or addresses change. Various central nodes may also receive more frequent updates than individual devices such as sensors embedded in building materials. Finally, layering and communication models present difficulties for straightforward use of the most obvious security mechanisms. Smart object networks typically pass information through multiple participating nodes [I-D.arkko-core-sleepy-sensors] and end-to-end security for IP or transport layers may not fit such communication models very well. The primary reasons for needing middleboxes relates to the need to accommodate for sleeping nodes as well to enable the implementation of nodes that store or aggregate information. 4. Proposed Architecture The proposed security architecture describes both a deployment model for provisioning as well as a technical model for networks and protocols. The basis of the architecture are self-generated secure identities, similar to Cryptographically Generated Addresses (CGAs) [RFC3972] or Host Identity Tags (HITs) [RFC5201]. That is, we assume the following holds: I = h(P|O) where I is the secure identity of the device, h is a hash function, P is the public key from a key pair generated by the device, and O is optional other information. 4.1. Provisioning As provisioning security credentials, shared secrets, and policy information is difficult, the provisioning model is based only on the secure identities. A typical network installation involves physical placement of a number of devices while noting the identities of these devices. This list of short identifiers can then be fed to a central server as a list of authorized devices. Secure communications can then commence with the devices, at least as far as information from from the devices to the server is concerned, which is what is needed for sensor networks. Actuator networks and server-to-device communication is covered in Section 4.4. Where necessary, the information collected at installation time may also include other parameters relevant to the application, such as Arkko & Keranen Expires January 27, 2012 [Page 6] Internet-Draft CoAP Security July 2011 the location or purpose of the devices. This would enable the server to know, for instance, that a particular device is the temperature sensor for the kitchen. Collecting the identity information at installation time can be arranged in a number of ways. The authors have employed a simple but not completely secure method where the last few digits of the identity are printed on a tiny device just a few millimeters across. Alternatively, the packaging for the device may include the full identity (typically 32 hex digits), retrieved from the device at manufacturing time. This identity can be read, for instance, by a bar code reader carried by the installation personnel. (Note that the identities are not secret, the security of the system is not dependent on the identity information leaking to others. The real owner of an identity can always prove its ownership with the private key which never leaves the device.) Finally, the device may use its wired network interface or proximity-based communications, such as Near-Field Communications (NFC) or Radio-Frequency Identity tags (RFIDs). Such interfaces allow secure communication of the device identity to an information gathering device at installation time. No matter what the method of information collection is, this provisioning model minimizes the effort required to set up the security. Each devices generates its own identity in a random, secure key generation process. The identities are self-securing in the sense that if you know the identity of the peer you want to communicate with, messages from the peer can be signed by the peer's private key and it is trivial to verify that the message came from the expected peer. There is no need to configure an identity and certificate of that identity separately. There is no need to configure a group secret or a shared secret. There is no need to configure a trust anchor. In addition, the identities are typically collected anyway for application purposes (such as identifying which sensor is in which room). Under most circumstances there is actually no additional configuration effort from provisioning security. 4.2. Device Groups In some deployment cases it is also possible to configure the identity of an entire group of devices, rather than registering the individual devices. For instance, many installations employ a kit of devices bought from the same manufacturer in one package. It is easy to provide an identity for such a set of devices as follows: Idev = h(Pdev|Potherdev1|Potherdev2|...|Potherdevn) Igrp = h(Pdev1|Pdev2|...|Pdevm) Arkko & Keranen Expires January 27, 2012 [Page 7] Internet-Draft CoAP Security July 2011 where Idev is the identity of an individual device, Pdev is the public key of that device, and Potherdevi are the public keys of other devices in the group. Now, we can define the secure identity of the group (Igrp) as a hash of all the public keys of the devices in the group (Pdevi). The installation personnel can scan the identity of the group from the box that the kit came in, and this identity can be stored in a server that is expected to receive information from the nodes. Later when the individual devices contact this server, they will be able to show that they are part of the group, as they can reveal their own public key and the public keys of the other devices. Devices that do not belong to the kit can not claim to be in the group, because the group identity would change if any new keys were added to Igrp. 4.3. Protocol Architecture As noted above, the starting point of the architecture is that nodes self-generate secure identities which are then communicated out-of- band to the peers that need to know what devices to trust. To support this model in a protocol architecture, we also need to use these secure identities to implement secure messaging between the peers, explain how the system can respond to different types of attacks such as replay attempts, and decide at what protocol layer and endpoints the architecture should use. Securing the messages is straightforward. A node with identity I should sign each message it sends with the private key associated with the identity I. This allows the recipient to verify that the message was constructed by the sender. This is similar to what Secure Neighbor Discovery (SEND) does with its RSA Signature Option [RFC3971]. However, this simple model needs some enhancements to be able to withstand denial-of-service and replay attacks. As we expect connectivity in smart object networks to be intermittent, traditional active methods such as nonce exchanges are not suitable. Instead, an optional timestamp-based approach SHOULD be used in addition to the basic signatures. This approach is similar to the one used to secure unsolicited SEND messages. Nodes that implement the timestamp approach need to have a real-time clock or they need to synchronize to one using a network time protocol [RFC5905]. Additionally, nodes that have persistent memory, SHOULD implement a monotonically increasing sequence number. Message recipients SHOULD silently ignore messages when they see a timestamp value that is out of range from the current time plus or minus a small time drift factor. Similarly, recipients that have seen multiple messages from the same sender SHOULD silently ignore messages that do not have a sequence Arkko & Keranen Expires January 27, 2012 [Page 8] Internet-Draft CoAP Security July 2011 number greater than the one they have seen last. These exchanges are basic cryptographic protocol tools, and have been used in different layers of the IP protocol stack for different purposes. For instance, HIP in its opportunistic mode could be used to implement largely the same functionality at the IP layer. However, it is our belief that the right layer for this solution is at the application layer. More specifically, in the data formats transported in the payload part of CoAP. This approach provides the following benefits: o Ability for intermediaries to act as caches to support different sleep schedules, without the security model being impacted. o Ability for intermediaries to be built to perform aggregation, filtering, storage and other actions, again without impacting the security of the data being transmitted or stored. o Ability to operate in the presence of traditional middleboxes, such as a protocol translators or even NATs (not that we recommend their use in these environments). Note that there is no requirement that the secure identities be associated with IP addresses. They can certainly be used as input material for constructing addresses for stateless address autoconfiguration [RFC4862], but this is not required. 4.4. Actuator Networking The above architecture is a perfect fit for sensor networks where information flows from large number of devices to small number of servers. But it is not sufficient alone for other types of applications. For instance, in actuator applications a large number of devices need to take commands from somewhere else. In such applications it is necessary to secure that the commands come from an authorized source. This can be supported, with some additional provisioning effort and optional pairing protocols. The basic provisioning approach is as described in Section 4.1, but in addition there must be something that informs the devices of the identity of the trusted server(s). There are multiple ways to provide this information. One simple approach is to feed the identities of the trusted server(s) to devices at installation time. This requires either a separate user interface, local connection (such as USB), or using the network interface of the device for configuration. In any case, as with sensor networks the amount of configuration information is minimized: just one short identity value needs to be fed in. Not both an Arkko & Keranen Expires January 27, 2012 [Page 9] Internet-Draft CoAP Security July 2011 identity and a certificate. Not shared secrets that must be kept confidential. An even simpler provisioning approach is that the devices in the device group discussed in Section 4.2 trust each other. Then no configuration is needed at installation time. When both peers know the expected cryptographic identity of the other peer off-line, secure communications can commence. Alternatively, various pairing schemes can be employed. Note that these schemes can benefit from the already secure identifiers on the device side. For instance, the server can send a pairing message to each device after their initial power-on and before they have been paired with anyone, encrypted with the public key of the device. As with all pairing schemes that do not employ a shared secret or the secure identity of both parties, there are some remaining vulnerabilities that may or may not be acceptable for the application in question. In any case, the secure identities help again in ensuring that the operations are as simple as possible. Only identities need to be communicated to the devices, not certificates, not shared secrets or IPsec policy rules. 5. Proposed Protocol Extensions The concrete implementation of the proposed architecture involves a specification for the identity format and generation, and a specification of the data format necessary to carry the signature, public key, timestamp, and sequence number data objects. The data format part of this specification could be implemented in various ways, as S/MIME data [RFC3851], XML signatures [RFC3275], or as additional data in JSON [I-D.jennings-senml] [RFC4627]. We have chosen to use the JSON format in this memo. 5.1. Identity Format The format of identifiers in binary representation is 128-bit identifiers. These identifiers have no association with any existing number space managed by IANA. In particular, they are not part of the IPv6 address space; they exist at application layer. The identifiers can be represented in textual form as Universal Resource Names (URNs), with the format "device:cgi-HEX" where "device" is the designated new URN type, "cgi" is a subtype that stands for cryptographically generated identifiers, and HEX is an exactly 32 characters long string of hex digits. Arkko & Keranen Expires January 27, 2012 [Page 10] Internet-Draft CoAP Security July 2011 While not at the right layer from the point of view of our architecture, these identities could also be used in the Authority Name part of CoAP DTLS (Section 10 of [I-D.ietf-core-coap]), IKE or other lower-level protocols. 5.2. Identity Generation The process of generating a new identity takes two input values: the public key of the identity owner as a DER-encoded ASN.1 structure of the type SubjectPublicKeyInfo, and optional other parameters. An identity and associated Identity Parameters Block (defined further below) SHOULD be generated as follows: 1. Generate a modifier, a random or pseudo-random 128-bit value. 2. Concatenate from left to right the modifier value, the encoded public key, and any optional other parameters. Execute the SHA- 256 algorithm [FIPS.180-3.2008] on the concatenation. Take the 128 leftmost bits of the SHA-256 hash value. The result is the identity. 3. Form an Identity Parameters Block data structure by concatenating from left to right the modifier value, the encoded public key, and any optional other parameters. The output of the address generation algorithm is a new identity and a new Identity Parameters Block data structure. The latter data structure has the following format: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Modifier (16 octets) + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Public Key (variable length) ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Optional other parameters (variable length) ~ | | Arkko & Keranen Expires January 27, 2012 [Page 11] Internet-Draft CoAP Security July 2011 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Public Key field MUST be formatted as a DER-encoded [CCITT.X690.2002] ASN.1 structure of the type SubjectPublicKeyInfo, defined in the Internet X.509 certificate profile [RFC3280]. RSA public/private key pair SHOULD be used. When RSA is used, the algorithm identifier MUST be rsaEncryption, which is 1.2.840.113549.1.1.1, and the RSA public key MUST be formatted by using the RSAPublicKey type as specified in Section 2.3.1 of RFC 3279 [RFC3279]. The other parameters is a sequence of extension blocks with the following format: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Extension Type | Extension Data Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Extension Data ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Where Extension Type 16-bit identifier of the type of the Extension Field. Identifier for the one currently defined extension is defined in Section 5.2.1, and some reserved values and values for testing use are given in Section 8. The summary of the defined values is as follows: Value Name ------------------------------------------------- 0x0000 Reserved (Section 8) 0x0001 Identifier_Group (Section 5.2.1) 0xFFFD Exp_FFFD (Section 8) 0xFFFE Exp_FFFE (Section 8) 0xFFFF Exp_FFFF (Section 8) Extension Data Length 16-bit unsigned integer. Length of the Extension Data field of this option, in octets. Arkko & Keranen Expires January 27, 2012 [Page 12] Internet-Draft CoAP Security July 2011 Extension Data Variable-length field. Extension-Type-specific data. 5.2.1. Identifier Groups This extension has the Extension Type 0x0001 (Identifier_Group). The purpose of the extension is to carry the public keys of other devices in a group of devices. As discussed in Section 4.2, this can be used to show membership of a group and ease the provisioning process. The extension data should consist of a 16-bit length field that expresses the number of public keys that follow, followed by each public key, encoded as described in Section 5.2. 5.3. JSON Identity Messages that employ secure identities and carry JSON [RFC4627] payloads need to carry information about the identity of the device that ultimately provided the payload. This information is necessary to understand the source of the information, and is also necessary to verify a cryptographic signature attached to the payload. However, the mechanisms for transporting information about the identity and making a signature are kept separate. An identity is represented by a two-field object in JSON, for instance: { "id": "device:cgi-27611bc81020716627ff0000cfaa1234", "ipb": "4e26b808cd05d4e26b80912ae3e26b809143fe4e26b4GFTR35f8266" } The "id" field MUST be included, and an additional "ipb" field for the Identity Parameters Block MAY be included. To save communications bandwidth, the optional field MAY be omitted even when the sender has the information. However, the "ipb" field SHOULD appear frequently enough in messages that recipients have likely cached it. 5.3.1. The id Field This field MUST contain an identity string in the format defined in Section 5.1. 5.3.2. The ipb Field This field MUST contain the BASE64-encoded Identity Parameters Block associated with the same identity as given in the "id" field. Arkko & Keranen Expires January 27, 2012 [Page 13] Internet-Draft CoAP Security July 2011 5.4. JSON Signature Envelope Messages that employ secure identities and carry JSON [RFC4627] payloads need to carry enough information to prove that the message came from the right source. The JSON Signature Envelope is a JSON object that carries a signature. Together with the JSON identity fields it becomes possible for the recipients to verify the signature. This object can be used to implement secure communication for devices that have the secure identifiers described above and that use JSON to transport information. Other signature envelope formats are needed for other payload formats, but the authors believe that the JSON format is widely applicable to smart objects. Note that multiple competing ways to represent signature envelopes in JSON are under development [I-D.rescorla-jsms], [I-D.jones-json-web-signature], and [I-D.jones-json-web-token]. The exact choice of encoding remains to be determined; this memo provides its own signature envelope format only for completeness. Every secure message MUST carry a JSON envelope object. This object MUST have exactly one "jmsg" field for the actual payload, "jid" field for the identity, and "jsig" field for the signature. The fields MUST also appear in this order. The messages MAY carry an additional "jts" field for the timestamp, and "jsq" field for the sequence number. If these fields are included, they MUST appear after the mandatory fields and in the given order. For instance, the following example contains a JSON signature envelope and a JSON payload from a temperature sensor: { "jmsg": { "temp": 27.5 }, "jid": { "id": "device:cgi-27611bc81020716627ff0000cfaa1234", "ipb": "4e26b808cd05d4e26b912ae3e26b809143fe4eb4GFTR35f82" }, "jts": { "s": 1311176727, "f": 123987 }, "jsq": 23, "jsig": "18929abqxc67juil7ff231000912927755bRRwlkadbfddceab"} Note that signatures envelopes can be nested; a JSON signature envelope can be placed inside another signature envelope in the "jmsg" field and signed. This is useful to implement secure intermediaries that want to include additional information beyond what the device itself provided. 5.4.1. The jmsg Field This field MUST contain the actual payload that the device wants to send, in the usual JSON format. Arkko & Keranen Expires January 27, 2012 [Page 14] Internet-Draft CoAP Security July 2011 Note that the JSON envelope needs to be useful without securing information in the rest of the CoAP message carrying it, as well as in situations where it is retransmitted in CoAP or HTTP via an intermediary. For this reason all the relevant information MUST be in the payload part. This is usually the case when taking an information centric approach as in [I-D.arkko-core-sleepy-sensors]. The jid field carries the identity of the device, and the jmsg carries all relevant information about what the devices wants to communicate. Consequently, the payload SHOULD be self-contained, without reference to the source or destination IP addresses of the CoAP message, or to the CoAP/HTTP method or URI. 5.4.2. The jid Field This field MUST contain an identity as defined in Section 5.3. 5.4.3. The jts Field This field MUST contain an object with two fields. The first field, "s", indicates the number of seconds since January 1, 1970, 00:00 UTC. At least 48 bits of accuracy is required. The second field, "f" indicate the number of 1/64K fractions of a second, with 16 bits of accuracy. Implementation note: This format is compatible with the usual representation of time under UNIX, although the number of bits available for the integer and fraction parts may vary. 5.4.4. The jsq Field This field MUST contain an integer representing a monotonically increasing sequence number of all messages sent by the sender. At least 32 bits of accuracy are required. 5.4.5. The jsig Field This field MUST contain a variable-length string containing a BASE64- encoded PKCS#1 v1.5 signature, constructed by using the sender's private key over the following sequence of octets: 1. The 128-bit CGI Usage Discriminator value for this specification, 0x53eb e540 4a92 5517 57b6 e398 7aaf a085. (The value has been generated randomly by the editor of this specification.) 2. The entire JSON payload, verbatim and in text as carried in the message, with the contents of the jsig field set to an empty string (jsig: ""). Arkko & Keranen Expires January 27, 2012 [Page 15] Internet-Draft CoAP Security July 2011 The signature value is computed with the RSASSA-PKCS1-v1_5 algorithm and SHA-256 hash, as defined in [PKCS.1.1993]. Senders use their private key associated with the claimed identity. The "jsig" field MUST be the last one in JSON payload. The resulting PKCS#1 v1.5 signature is put in the "jsig" field. Receivers MUST treat messages without the "jsig" field as unsecured. A received "jsig" field MUST be checked as follows: o The receiver MUST ignore any fields that come after the first "jsig" field, for both verification and other processing purposes. o There must be an associated JSON identity information, so that both the identity and associated public key must be apparent from the secured message, or learned from a preceding message. o The "jsig" field MUST have correct encoding. o The signature verification MUST show that the signature has been calculated as specified above. Messages that do not pass all the above tests MUST be silently discarded if the host has been configured to accept only secured CoAP messages. The messages MAY be accepted if the host has been configured to accept both secured and unsecured messages but MUST be treated as an unsecured message. The receiver MAY also otherwise silently discard packets (e.g., as a response to an apparent CPU exhausting DoS attack). 6. Concluding Remarks This memo has presented a deployment model, security architecture, and an initial sketch of protocol design to support the architecture. To recap, the main benefits of this model are o Minimal configuration: per device or per group registration of identities in a server, but no configuration in every device. o Support for deployment models that are easily implementable by installation personnel. The necessary practices are already employed in typical current smart object networks, even when there is particular support for security. o Architecture that naturally supports information-centric networking, multicast, middleboxes, aggregation, sleeping nodes, and other aspects that are typical for networking for smart objects. Arkko & Keranen Expires January 27, 2012 [Page 16] Internet-Draft CoAP Security July 2011 7. Security Considerations This entire memo deals with security issues. Some analysis of the security of the mechanisms proposed in this memo is necessary, however. The security of the architecture rests on the choice of the number of bits in the identifier and the used hash and signature algorithm. With the use of 128 bits identifiers and SHA-256 and RSA, it is expected that the security level is similar to the one in HIP, and goes beyond the 59 bit security of CGAs. The basic architecture concerns itself only with integrity and data origin verification, not about confidentiality. Where confidentiality or identity privacy is required, additional mechanisms are needed. Replay attacks can be prevented beyond a small time window of acceptable clock drift, when devices employ the optional timestamp mechanism. This rests on the assumption of secure time synchronization or configuration in the nodes, however. Where NTP is used, its security properties in different modes are discussed in Section 15 of [RFC5905]. In general, no major security problems have been experienced with NTP protocol or reference implementation [NTP.Wikipedia], but protection against determined hostile attackers does require authentication at NTP the layer. Alternative, simpler approaches include relying on the accuracy of clocks set at manufacturing time. The optional sequence number mechanism can prevent all replay attacks for persistent communications between two peers. Without the use of these two mechanisms there is no support for preventing replay attacks. This may be acceptable in some environments, but not in all. Any information centric communication model is resistant to attacks against nodes only sending information, as they are not expected to process any security-related messages. Thus, the "sleep torture deprivation attack" described by Stajano and Anderson in [Resurrecting-Duckling] and other denial-of-service attacks of the same nature are not applicable in the architecture proposed in this memo. However, by the same token nodes that receive information become more vulnerable to denial-of-service attacks, as nonce exchanges, puzzles and other standard protocol mechanisms are not used to guard against the receiver having to verify a cryptographic operation on a received packet. The authors believe that this is the right tradeoff for sensor networking, given that server and gateway implementations are more likely to have the necessary capabilities to Arkko & Keranen Expires January 27, 2012 [Page 17] Internet-Draft CoAP Security July 2011 deal with attacks than sensor nodes. 8. IANA Considerations IANA should reserve the new URN type "device" (Section 5.1). A new registry should be created to hold subtypes of this URN type, with the initial value "cgi" defined in this memo. New values can be created through IETF Review or IESG Approval [RFC5226]. IANA should also create a new registry for Cryptographically Generated Identifiers, and add a new name space Extension Type (Section 5.2) there. Policy for adding new extensions in this registry is RFC Required or IESG Approval [RFC5226]. Initial values for the Extension Type field are given below. Assignments consist of a name and the value. Extension Type 0x0000 should be marked as reserved. Section 5.2.1 allocates Extension Type 0x0001. As recommended in [RFC3692], this document also makes the following assignments for experimental and testing use: the value 0xFFFD, with name Exp_FFFD; the value 0xFFFE, with name Exp_FFFE, and the value 0xFFFF, with name Exp_FFFF. IANA should also add another new name space to the same registry, for 128-bit CGI Usage Discriminators. These values are allocated on a First Come, First Served basis [RFC5226]. The one initial value in the registry is given in Section 5.4.5. 9. References 9.1. Normative References [I-D.ietf-core-coap] Shelby, Z., Hartke, K., Bormann, C., and B. Frank, "Constrained Application Protocol (CoAP)", draft-ietf-core-coap-06 (work in progress), May 2011. [I-D.jennings-senml] Jennings, C., "Media Type for Sensor Markup Language (SENML)", draft-jennings-senml-05 (work in progress), March 2011. [RFC3279] Bassham, L., Polk, W., and R. Housley, "Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3279, April 2002. Arkko & Keranen Expires January 27, 2012 [Page 18] Internet-Draft CoAP Security July 2011 [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002. [RFC4627] Crockford, D., "The application/json Media Type for JavaScript Object Notation (JSON)", RFC 4627, July 2006. [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network Time Protocol Version 4: Protocol and Algorithms Specification", RFC 5905, June 2010. [PKCS.1.1993] RSA Laboratories, "RSA Encryption Standard, Version 1.5", PKCS 1, November 1993. [FIPS.180-3.2008] National Institute of Standards and Technology, "Secure Hash Standard", FIPS PUB 180-3, October 2008, . [CCITT.X690.2002] International International Telephone and Telegraph Consultative Committee, "ASN.1 encoding rules: Specification of basic encoding Rules (BER), Canonical encoding rules (CER) and Distinguished encoding rules (DER)", CCITT Recommendation X.690, July 2002. 9.2. Informative References [RFC3275] Eastlake, D., Reagle, J., and D. Solo, "(Extensible Markup Language) XML-Signature Syntax and Processing", RFC 3275, March 2002. [RFC3692] Narten, T., "Assigning Experimental and Testing Numbers Considered Useful", BCP 82, RFC 3692, January 2004. [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004. [RFC3851] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification", RFC 3851, July 2004. Arkko & Keranen Expires January 27, 2012 [Page 19] Internet-Draft CoAP Security July 2011 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005. [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", RFC 3972, March 2005. [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005. [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, September 2007. [RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. Thayer, "OpenPGP Message Format", RFC 4880, November 2007. [RFC5191] Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H., and A. Yegin, "Protocol for Carrying Authentication for Network Access (PANA)", RFC 5191, May 2008. [RFC5201] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson, "Host Identity Protocol", RFC 5201, April 2008. [RFC5238] Phelan, T., "Datagram Transport Layer Security (DTLS) over the Datagram Congestion Control Protocol (DCCP)", RFC 5238, May 2008. [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008. [RFC5406] Bellovin, S., "Guidelines for Specifying the Use of IPsec Version 2", BCP 146, RFC 5406, February 2009. [RFC6078] Camarillo, G. and J. Melen, "Host Identity Protocol (HIP) Immediate Carriage and Conveyance of Upper-Layer Protocol Signaling (HICCUPS)", RFC 6078, January 2011. [I-D.arkko-core-sleepy-sensors] Arkko, J., Rissanen, H., Loreto, S., Turanyi, Z., and O. Novo, "Implementing Tiny COAP Sensors", draft-arkko-core-sleepy-sensors-01 (work in progress), July 2011. [I-D.daniel-6lowpan-security-analysis] Park, S., Kim, K., Haddad, W., Chakrabarti, S., and J. Laganier, "IPv6 over Low Power WPAN Security Analysis", draft-daniel-6lowpan-security-analysis-05 (work in progress), March 2011. Arkko & Keranen Expires January 27, 2012 [Page 20] Internet-Draft CoAP Security July 2011 [I-D.garcia-core-security] Garcia-Morchon, O., Keoh, S., Kumar, S., Hummen, R., and R. Struik, "Security Considerations in the IP-based Internet of Things", draft-garcia-core-security-02 (work in progress), July 2011. [I-D.iab-smart-object-workshop] Tschofenig, H. and J. Arkko, "Report from the 'Interconnecting Smart Objects with the Internet' Workshop, 25th March 2011, Prague", draft-iab-smart-object-workshop-01 (work in progress), July 2011. [I-D.ietf-hip-rfc5201-bis] Moskowitz, R., Heer, T., Jokela, P., and T. Henderson, "Host Identity Protocol Version 2 (HIPv2)", draft-ietf-hip-rfc5201-bis-06 (work in progress), July 2011. [I-D.jones-json-web-signature] Jones, M., Balfanz, D., Bradley, J., Goland, Y., Panzer, J., Sakimura, N., and P. Tarjan, "JSON Web Signature (JWS)", draft-jones-json-web-signature-02 (work in progress), April 2011. [I-D.jones-json-web-token] Jones, M., Balfanz, D., Bradley, J., Goland, Y., Panzer, J., Sakimura, N., and P. Tarjan, "JSON Web Token (JWT)", draft-jones-json-web-token-05 (work in progress), July 2011. [I-D.kivinen-ipsecme-ikev2-minimal] Kivinen, T., "Minimal IKEv2", draft-kivinen-ipsecme-ikev2-minimal-00 (work in progress), February 2011. [I-D.moskowitz-hip-rg-dex] Moskowitz, R., "HIP Diet EXchange (DEX)", draft-moskowitz-hip-rg-dex-05 (work in progress), March 2011. [I-D.rescorla-jsms] Rescorla, E. and J. Hildebrand, "JavaScript Message Security Format", draft-rescorla-jsms-00 (work in progress), March 2011. [I-D.sarikaya-core-sbootstrapping] Sarikaya, B., Ohba, Y., Moskowitz, R., Cao, Z., and R. Arkko & Keranen Expires January 27, 2012 [Page 21] Internet-Draft CoAP Security July 2011 Cragie, "Security Bootstrapping of Resource-Constrained Devices", draft-sarikaya-core-sbootstrapping-02 (work in progress), June 2011. [IEEE.802-1X.2010] Institute of Electrical and Electronics Engineers, "IEEE 802.1X Port-Based Network Access Control", IEEE IEEE Standard 802.1X, February 2010. [Resurrecting-Duckling] Stajano, F. and R. Anderson, "The Resurrecting Duckling: Security Issues for Ubiquitous Computing", IEEE Computer Journal Volume 42, Issue 5, 2002. [NTP.Wikipedia] Wikipedia, "Network Time Protocol", Wikipedia article , July 2011, . Appendix A. Acknowledgments The authors would like to thank to Oscar Novo, Heidi-Maria Rissanen, Samita Chakrabarti, and Fredrik Garneij for interesting discussions in this problem space. Authors' Addresses Jari Arkko Ericsson Jorvas 02420 Finland Email: jari.arkko@piuha.net Ari Keranen Ericsson Jorvas 02420 Finland Email: ari.keranen@ericsson.com Arkko & Keranen Expires January 27, 2012 [Page 22]