[Docs] [txt|pdf|xml] [Tracker] [Email] [Nits] [IPR]

Versions: 00

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, <http://
              csrc.nist.gov/publications/fips/fips180-3/fips180-3.pdf>.

   [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,
              <http://en.wikipedia.org/wiki/Network_Time_Protocol>.


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]


Html markup produced by rfcmarkup 1.120, available from https://tools.ietf.org/tools/rfcmarkup/