One document matched: draft-arkko-core-security-arch-00.xml

<?xml version="1.0" encoding="iso-8859-1" ?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">

<rfc ipr="trust200902"
     docName="draft-arkko-core-security-arch-00"
     category="info">

<?rfc toc="yes"?> <?rfc symrefs="yes"?> <?rfc autobreaks="yes"?>
<?rfc tocindent="yes"?> <?rfc compact="yes"?> <?rfc subcompact="no"?>

<front>

<title abbrev="CoAP Security">CoAP Security Architecture</title>

<author initials="J" surname="Arkko" fullname="Jari Arkko">
<organization>Ericsson</organization>
<address>
<postal>
<street/>
<city>Jorvas</city> <code>02420</code>
<country>Finland</country>
</postal>
<email>jari.arkko@piuha.net</email>
</address>
</author>

<author initials="A" surname="Keranen" fullname="Ari Keranen">
<organization>Ericsson</organization>
<address>
<postal>
<street/>
<city>Jorvas</city> <code>02420</code>
<country>Finland</country>
</postal>
<email>ari.keranen@ericsson.com</email>
</address>
</author>

<date month="July" year="2011" />

<keyword>CoAP</keyword>
<keyword>security</keyword>

<abstract>

<t>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.</t>

</abstract>

</front>
<middle>

<section anchor="intro" title="Introduction">

<t>Constrained Application Protocol (CoAP)
<xref target="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.</t>

<t>This memo describes implementation and operational challenges
associated with securing CoAP in these environments
(<xref target="problem"/>), reviews related work in solving these
challenges (<xref target="related"/>), and proposes a security model
(<xref target="solution"/>) 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 (<xref target="protocol"/>). <xref target="sum"/> provides a summary
of the approach.</t>

</section>

<section anchor="related" title="Related Work">

<t>CoAP base specification <xref target="I-D.ietf-core-coap"/>
outlines how to use DTLS <xref target="RFC5238"/> and IPsec
<xref target="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.</t>

<t>The IPsec mode is described with regards to the protocol
requirements, noting that small implementations of IKEv2 exist
<xref target="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 <xref target="RFC5406"/>.</t>

<t><xref target="I-D.garcia-core-security"/> discusses the overall
security problem for Internet of Things devices. It also discusses
various solutions, including IKEv2/IPsec <xref target="RFC4306"/>,
TLS/SSL <xref target="RFC5246"/>, DTLS <xref target="RFC5238"/>, HIP
<xref target="RFC5201"/> <xref target="I-D.ietf-hip-rfc5201-bis"/>
<xref target="I-D.moskowitz-hip-rg-dex"/>, PANA
<xref target="RFC5191"/>, and EAP <xref target="RFC3748"/>. The draft
also discusses various operational scenarios, bootstrapping mechanisms,
and challenges associated with implementing secity mechanisms in these
environments.</t>

<t><xref target="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 to the Bluetooth pairing mechanism), understanding
the implementability of standard security mechanisms in small devices
(see, for instance,
<xref target="I-D.kivinen-ipsecme-ikev2-minimal"/>), and additional
research in the area of lightweight cryptographic primitives.</t>

<t><xref target="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 <xref target="RFC3748"/>,
PANA <xref target="RFC5191"/>, HIP Diet Exchange (HIP-DEX)
<xref target="I-D.moskowitz-hip-rg-dex"/>, and 802.1X
<xref target="IEEE.802-1X.2010"/> as potential solutions for
bootstrapping.</t>

<t><xref target="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.
<xref target="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.</t>

<t><xref target="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.</t>

<t>Cryptographically Generated Addresses (CGAs)
<xref target="RFC3972"/> and Host Identity Protocol (HIP)
<xref target="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 <xref target="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.</t>

<t><xref target="I-D.rescorla-jsms"/>,
<xref target="I-D.jones-json-web-signature"/>, and
<xref target="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.</t>

</section>

<section anchor="problem" title="Challenges">

<t>This section discusses three challenges: implementation
difficulties, practical provisioning problems, and layering and
communication models.</t>

<t>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.</t>

<t>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.</t>

<t>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:

<list style="symbols">

<t>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.</t>

<t>Manual configuration is rarely, if at all, possible, as the
necessary skills are missing in typical installation environments
(such as in family homes).</t>

<t>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.</t>

<t>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.</t>

</list></t>

<t>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 <xref target="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.</t>

</section>

<section anchor="solution" title="Proposed Architecture">

<t>The proposed security architecture describes both a deployment
model for provisioning as well as a technical model for networks and
protocols.</t>

<t>The basis of the architecture are self-generated secure identities,
similar to Cryptographically Generated Addresses (CGAs)
<xref target="RFC3972"/> or Host Identity Tags (HITs)
<xref target="RFC5201"/>. That is, we assume the following holds:

<list style="empty">
<t>I = h(P|O)</t>
</list>
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.</t>

<section anchor="provisioning" title="Provisioning">

<t>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 <xref target="actuators"/>.</t>

<t>Where necessary, the information collected at installation time may
also include other parameters relevant to the application, such as 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.</t>

<t>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.</t>

<t>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.</t>

</section>

<section anchor="grpprov" title="Device Groups">

<t>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:

<list style="empty">
<t>Idev = h(Pdev|Potherdev1|Potherdev2|...|Potherdevn)</t>
<t>Igrp = h(Pdev1|Pdev2|...|Pdevm)</t>
</list>
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).</t>

<t>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.</t>

</section>

<section anchor="protocolarch" title="Protocol Architecture">

<t>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.</t>

<t>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
<xref target="RFC3971"/>.</t>

<t>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 <xref target="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 number
greater than the one they have seen last.</t>

<t>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:

<list style="symbols">

<t>Ability for intermediaries to act as caches to support different
sleep schedules, without the security model being impacted.</t>

<t>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.</t>

<t>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).</t>

</list></t>

<t>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 <xref target="RFC4862"/>, but this is not
required.</t>

</section>

<section anchor="actuators" title="Actuator Networking">

<t>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.</t>

<t>This can be supported, with some additional provisioning effort and optional
pairing protocols. The basic provisioning approach is as described in
<xref target="provisioning"/>, 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 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 <xref target="grpprov"/> trust each other. Then no
configuration is needed at installation time.</t>

<t>When both peers know the expected cryptographic identity of
the other peer off-line, secure communications can commence.</t>

<t>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.</t>

<t>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.</t>

</section>

</section>

<section anchor="protocol" title="Proposed Protocol Extensions">

<t>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.</t>

<t>The data format part of this specification could be implemented in
various ways, as S/MIME data <xref target="RFC3851"/>, XML signatures
<xref target="RFC3275"/>, or as additional data in JSON
<xref target="I-D.jennings-senml"/> <xref target="RFC4627"/>. We have
chosen to use the JSON format in this memo.</t>

<section anchor="identity" title="Identity Format">

<t>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.</t>

<t>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.

<list style="empty">
<t>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
<xref target="I-D.ietf-core-coap"/>), IKE or other lower-level
protocols.</t>
</list></t>

</section>

<section anchor="idgen" title="Identity Generation">

<t>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.</t>

<t>An identity and associated Identity Parameters Block (defined
further below) SHOULD be generated as follows:

<list style="numbers">

<t>Generate a modifier, a random or pseudo-random 128-bit value.</t>

<t>Concatenate from left to right the modifier value, the encoded
public key, and any optional other parameters.  Execute the SHA-256
algorithm <xref target="FIPS.180-3.2008"/> on the concatenation. Take
the 128 leftmost bits of the SHA-256 hash value. The result is
the identity.</t>

<t>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.</t>

</list></t>

<t>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:</t>

<figure>
<artwork>
    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)         ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>

<t>The Public Key field MUST be formatted as a DER-encoded
<xref target="CCITT.X690.2002"/> ASN.1 structure of the type SubjectPublicKeyInfo,
defined in the Internet X.509 certificate profile <xref target="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
<xref target="RFC3279"/>.</t>

<t>The other parameters is a sequence of extension blocks with the
following format:</t>

<figure>
<artwork>
    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                          ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>

<t>Where

<list style="hanging">

<t hangText="Extension Type"><vspace blankLines="1"/> 16-bit
identifier of the type of the Extension Field. Identifier for the one
currently defined extension is defined in <xref target="grp"/>, and
some reserved values and values for testing use are given in
<xref target="iana"/>. The summary of the defined values is as follows:
<vspace blankLines="1"/>
<figure>
<artwork>
    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)
</artwork>
</figure>
</t>

<t hangText="Extension Data Length"><vspace blankLines="1"/>
16-bit unsigned integer. Length of the Extension Data field of this
option, in octets.</t>

<t hangText="Extension Data"><vspace blankLines="1"/>
Variable-length field. Extension-Type-specific data.</t>

</list></t>

<section anchor="grp" title="Identifier Groups">

<t>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 <xref target="grpprov"/>, this can be used to show membership of a group
and ease the provisioning process.</t>

<t>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 <xref target="idgen"/>.</t>

</section>

</section>

<section anchor="jid" title="JSON Identity">

<t>Messages that employ secure identities and carry JSON <xref target="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.</t>

<t>An identity is represented by a two-field object in JSON, for instance:</t>

<figure>
<artwork>
{ "id": "device:cgi-27611bc81020716627ff0000cfaa1234",
  "ipb":  "4e26b808cd05d4e26b80912ae3e26b809143fe4e26b4GFTR35f8266" }
</artwork>
</figure>

<t>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.</t>

<section title="The id Field">

<t>This field MUST contain an identity string in the format defined in
<xref target="identity"/>.</t>

</section>

<section title="The ipb Field">

<t>This field MUST contain the BASE64-encoded Identity Parameters
Block associated with the same identity as given in the "id"
field.</t>

</section>

</section>

<section anchor="sigenv" title="JSON Signature Envelope">

<t>Messages that employ secure identities and carry JSON <xref target="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.</t>

<t>Note that multiple competing ways to represent signature envelopes in JSON are
under development <xref target="I-D.rescorla-jsms"/>,
<xref target="I-D.jones-json-web-signature"/>, and
<xref target="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.</t>

<t>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.</t>

<t>For instance, the following example contains a JSON signature
envelope and a JSON payload from a temperature sensor:</t>

<figure>
<artwork>
    { "jmsg": { "temp": 27.5 },
      "jid":  { "id": "device:cgi-27611bc81020716627ff0000cfaa1234",
                "ipb":  "4e26b808cd05d4e26b912ae3e26b809143fe4eb4GFTR35f82" },
      "jts":  { "s": 1311176727, "f": 123987 },
      "jsq":  23,
      "jsig": "18929abqxc67juil7ff231000912927755bRRwlkadbfddceab"}
</artwork>
</figure>

<t>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.</t>

<section title="The jmsg Field">

<t>This field MUST contain the actual payload that the device wants to
send, in the usual JSON format.</t>

<t>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 <xref target="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.</t>

</section>
<section title="The jid Field">

<t>This field MUST contain an identity as defined in <xref target="jid"/>.</t>

</section>

<section title="The jts Field">

<t>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.</t>

<t>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.</t>

</section>

<section title="The jsq Field">

<t>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.</t>

</section>

<section anchor="jsig" title="The jsig Field">

<t>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:

<list style="numbers">

<t>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.)</t>

<t>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: "").</t>.

</list></t>

<t>The signature value is computed with the RSASSA-PKCS1-v1_5
algorithm and SHA-256 hash, as defined in
<xref target="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.</t>

<t>Receivers MUST treat messages without the "jsig" field as unsecured.
A received "jsig" field MUST be checked as follows:

<list style="symbols">

<t>The receiver MUST ignore any fields that come after the first
"jsig" field, for both verification and other processing purposes.</t>

<t>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.</t>

<t>The "jsig" field MUST have correct encoding.</t>

<t>The signature verification MUST show that the signature has been
calculated as specified above.</t>

</list></t>

<t>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).</t>

</section>

</section>

</section>

<section anchor="sum" title="Concluding Remarks">

<t>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

<list style="symbols">

<t>Minimal configuration: per device or per group registration of identities in a
server, but no configuration in every device.</t>

<t>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.</t>
 
<t>Architecture that naturally supports information-centric networking, multicast,
middleboxes, aggregation, sleeping nodes, and other aspects that are typical for
networking for smart objects.</t>

</list></t>

</section>

<section title="Security Considerations">

<t>This entire memo deals with security issues. Some analysis of the
security of the mechanisms proposed in this memo is necessary,
however.</t>

<t>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.</t>

<t>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.</t>

<t>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
<xref target="RFC5905"/>. In general, no major security problems have
been experienced with NTP protocol or reference implementation
<xref target="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.</t>

<t>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.</t>

<t>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
<xref target="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 deal with attacks than sensor nodes.</t>

</section>

<section anchor="iana" title="IANA Considerations">

<t>IANA should reserve the new URN type "device" (<xref target="identity"/>).
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 <xref target="RFC5226"/>.</t>

<t>IANA should also create a new registry for Cryptographically
Generated Identifiers, and add a new name space Extension Type
(<xref target="idgen"/>) there. Policy for adding new extensions in
this registry is RFC Required or IESG Approval
<xref target="RFC5226"/>.  Initial values for the Extension Type field
are given below. Assignments consist of a name and the value.</t>

<t>Extension Type 0x0000 should be marked as
reserved. <xref target="grp"/> allocates Extension Type 0x0001.  As
recommended in <xref target="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.</t>

<t>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 <xref target="RFC5226"/>. The one
initial value in the registry is given in <xref target="jsig"/>.</t>

</section>

</middle>

<back>

<references title="Normative References">
      <?rfc include="reference.I-D.draft-ietf-core-coap-06.xml"?>
      <?rfc include="reference.I-D.jennings-senml.xml"?>
      <?rfc include="reference.RFC.3279.xml"?>
      <?rfc include="reference.RFC.3280.xml"?>
      <?rfc include="reference.RFC.4627.xml"?>
      <?rfc include="reference.RFC.5226.xml"?>
      <?rfc include="reference.RFC.5905.xml"?>
      <?rfc include="reference.PKCS.1.1993.xml"?>
      <?rfc include="reference.FIPS.180-3.2008.xml"?>
      <?rfc include="reference.CCITT.X690.2002.xml"?>
</references>

<references title="Informative References">
      <?rfc include="reference.RFC.3275.xml"?>
      <?rfc include="reference.RFC.3692.xml"?>
      <?rfc include="reference.RFC.3748.xml"?>
      <?rfc include="reference.RFC.3851.xml"?>
      <?rfc include="reference.RFC.3971.xml"?>
      <?rfc include="reference.RFC.3972.xml"?>
      <?rfc include="reference.RFC.4306.xml"?>
      <?rfc include="reference.RFC.4862.xml"?>
      <?rfc include="reference.RFC.4880.xml"?>
      <?rfc include="reference.RFC.5191.xml"?>
      <?rfc include="reference.RFC.5201.xml"?>
      <?rfc include="reference.RFC.5238.xml"?>
      <?rfc include="reference.RFC.5246.xml"?>
      <?rfc include="reference.RFC.5406.xml"?>
      <?rfc include="reference.RFC.6078.xml"?>
      <?rfc include="reference.I-D.arkko-core-sleepy-sensors.xml"?>
      <?rfc include="reference.I-D.daniel-6lowpan-security-analysis.xml"?>
      <?rfc include="reference.I-D.garcia-core-security.xml"?>
      <?rfc include="reference.I-D.iab-smart-object-workshop.xml"?>
      <?rfc include="reference.I-D.ietf-hip-rfc5201-bis.xml"?>
      <?rfc include="reference.I-D.jones-json-web-signature.xml"?>
      <?rfc include="reference.I-D.jones-json-web-token.xml"?>
      <?rfc include="reference.I-D.kivinen-ipsecme-ikev2-minimal.xml"?>
      <?rfc include="reference.I-D.moskowitz-hip-rg-dex.xml"?>
      <?rfc include="reference.I-D.rescorla-jsms.xml"?>
      <?rfc include="reference.I-D.sarikaya-core-sbootstrapping.xml"?>
      <?rfc include="reference.IEEE.802.1X.2010.xml"?>
      <?rfc include="reference.duckling.xml"?>
      <?rfc include="reference.ntp.wikipedia.xml"?>
</references>

<section title="Acknowledgments">

<t>The authors would like to thank to Oscar Novo, Heidi-Maria
Rissanen, Samita Chakrabarti, and Fredrik Garneij for interesting
discussions in this problem space.</t>

</section>

</back>
</rfc>