draft-ietf-lwig-crypto-sensors-04.txt   draft-ietf-lwig-crypto-sensors-05.txt 
Light-Weight Implementation Guidance M. Sethi Light-Weight Implementation Guidance M. Sethi
Internet-Draft J. Arkko Internet-Draft J. Arkko
Intended status: Informational A. Keranen Intended status: Informational A. Keranen
Expires: February 9, 2018 Ericsson Expires: June 27, 2018 Ericsson
H. Back H. Back
Comptel Comptel
August 8, 2017 December 24, 2017
Practical Considerations and Implementation Experiences in Securing Practical Considerations and Implementation Experiences in Securing
Smart Object Networks Smart Object Networks
draft-ietf-lwig-crypto-sensors-04 draft-ietf-lwig-crypto-sensors-05
Abstract Abstract
This memo describes challenges associated with securing resource- This memo describes challenges associated with securing resource-
constrained smart object devices. The memo describes a possible constrained smart object devices. The memo describes a possible
deployment model where resource-constrained devices sign message deployment model where resource-constrained devices sign message
objects, discusses the availability of cryptographic libraries for objects, discusses the availability of cryptographic libraries for
small devices and presents some preliminary experiences with those small devices and presents some preliminary experiences with those
libraries for message signing on small devices. Lastly, the memo libraries for message signing on small devices. Lastly, the memo
discusses trade-offs involving different types of security discusses trade-offs involving different types of security
approaches. approaches.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on February 9, 2018. This Internet-Draft will expire on June 27, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Related Work . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Related Work . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Challenges . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Challenges . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Proposed Deployment Model . . . . . . . . . . . . . . . . . . 5 4. Proposed Deployment Model . . . . . . . . . . . . . . . . . . 6
5. Provisioning . . . . . . . . . . . . . . . . . . . . . . . . 6 4.1. Provisioning . . . . . . . . . . . . . . . . . . . . . . 6
6. Protocol Architecture . . . . . . . . . . . . . . . . . . . . 8 4.2. Protocol Architecture . . . . . . . . . . . . . . . . . . 9
7. Code Availability . . . . . . . . . . . . . . . . . . . . . . 9 5. Code Availability . . . . . . . . . . . . . . . . . . . . . . 10
8. Implementation Experiences . . . . . . . . . . . . . . . . . 10 6. Implementation Experiences . . . . . . . . . . . . . . . . . 11
9. Example Application . . . . . . . . . . . . . . . . . . . . . 17 7. Example Application . . . . . . . . . . . . . . . . . . . . . 18
10. Design Trade-Offs . . . . . . . . . . . . . . . . . . . . . . 20 8. Design Trade-Offs . . . . . . . . . . . . . . . . . . . . . . 20
11. Feasibility . . . . . . . . . . . . . . . . . . . . . . . . . 20 8.1. Feasibility . . . . . . . . . . . . . . . . . . . . . . . 20
12. Freshness . . . . . . . . . . . . . . . . . . . . . . . . . . 21 8.2. Freshness . . . . . . . . . . . . . . . . . . . . . . . . 22
13. Layering . . . . . . . . . . . . . . . . . . . . . . . . . . 23 8.3. Layering . . . . . . . . . . . . . . . . . . . . . . . . 24
14. Symmetric vs. Asymmetric Crypto . . . . . . . . . . . . . . . 25 8.4. Symmetric vs. Asymmetric Crypto . . . . . . . . . . . . . 25
15. Security Considerations . . . . . . . . . . . . . . . . . . . 25 9. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 10. Security Considerations . . . . . . . . . . . . . . . . . . . 27
17. Informative references . . . . . . . . . . . . . . . . . . . 26 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 31 12. Informative references . . . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 33
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33
1. Introduction 1. Introduction
This memo describes challenges associated with securing smart object This memo describes challenges associated with securing smart object
devices in constrained implementations and environments. In devices in constrained implementations and environments. In
Section 3 we specifically discuss three challenges: the Section 3 we specifically discuss three challenges: the
implementation difficulties encountered on resource-constrained implementation difficulties encountered on resource-constrained
platforms, the problem of provisioning keys and making the choice of platforms, the problem of provisioning keys and making the choice of
implementing security at the appropriate layer. implementing security at the appropriate layer.
Section 4 discusses a deployment model that the authors are Section 4 discusses a deployment model that the authors are
considering for constrained environments. The model requires minimal considering for constrained environments. The model requires minimal
amount of configuration, and we believe it is a natural fit with the amount of configuration, and we believe it is a natural fit with the
typical communication practices in smart object networking typical communication practices in smart object networking
environments. environments.
Section 7 discusses the availability of cryptographic libraries. Section 5 discusses the availability of cryptographic libraries.
Section 8 presents some experiences in implementing cryptography on Section 6 presents some experiences in implementing cryptography on
small devices using those libraries, including information about small devices using those libraries, including information about
achievable code sizes and speeds on typical hardware. achievable code sizes and speeds on typical hardware.
Finally, Section 10 discusses trade-offs involving different types of Finally, Section 8 discusses trade-offs involving different types of
security approaches. security approaches.
2. Related Work 2. Related Work
Constrained Application Protocol (CoAP) [RFC7252] is a light-weight Constrained Application Protocol (CoAP) [RFC7252] is a light-weight
protocol designed to be used in machine-to-machine applications such protocol designed to be used in machine-to-machine applications such
as smart energy and building automation. Our discussion uses this as smart energy and building automation. Our discussion uses this
protocol as an example, but the conclusions may apply to other protocol as an example, but the conclusions may apply to other
similar protocols. CoAP base specification [RFC7252] outlines how to similar protocols. CoAP base specification [RFC7252] outlines how to
use DTLS [RFC6347] and IPsec [RFC4303] for securing the protocol. use DTLS [RFC6347] and IPsec [RFC4303] for securing the protocol.
DTLS can be applied with pairwise shared keys, raw public keys or DTLS can be applied with pairwise shared keys, raw public keys or
with certificates. The security model in all cases is mutual with certificates. The security model in all cases is mutual
authentication, so while there is some commonality to HTTP [RFC7230] authentication, so while there is some commonality to HTTP [RFC7230]
in verifying the server identity, in practice the models are quite in verifying the server identity, in practice the models are quite
different. The use of IPsec with CoAP is described with regards to different. The use of IPsec with CoAP is described with regards to
the protocol requirements, noting that small implementations of IKEv2 the protocol requirements, noting that small implementations of IKEv2
exist [RFC7815]. However, the CoAP specification is silent on policy exist [RFC7815]. However, the CoAP specification is silent on policy
and other aspects that are normally necessary in order to implement and other aspects that are normally necessary in order to implement
interoperable use of IPsec in any environment [RFC5406]. interoperable use of IPsec in any environment [RFC5406].
[I-D.irtf-t2trg-iot-seccons] documents the different stages in the
lifecycle of a smart object. Next, it highlights the security
threats for smart objects and the challenges that one might face to
protect against these threats. The document also looks at various
security protocols available, including IKEv2/IPsec [RFC7296], TLS/
SSL [RFC5246], DTLS [RFC6347], HIP [RFC7401],
[I-D.moskowitz-hip-dex], PANA [RFC5191], and EAP [RFC3748]. Lastly,
[I-D.sarikaya-t2trg-sbootstrapping] discusses bootstrapping
mechanisms available for resource-constrained IoT devices.
[RFC6574] gives an overview of the security discussions at the March [RFC6574] gives an overview of the security discussions at the March
2011 IAB workshop on smart objects. The workshop recommended that 2011 IAB workshop on smart objects. The workshop recommended that
additional work is needed in developing suitable credential additional work is needed in developing suitable credential
management mechanisms (perhaps something similar to the Bluetooth management mechanisms (perhaps something similar to the Bluetooth
pairing mechanism), understanding the implementability of standard pairing mechanism), understanding the implementability of standard
security mechanisms in small devices, and additional research in the security mechanisms in small devices, and additional research in the
area of lightweight cryptographic primitives. area of lightweight cryptographic primitives.
[I-D.moskowitz-hip-dex] defines a light-weight version of the HIP [I-D.moskowitz-hip-dex] defines a light-weight version of the HIP
protocol for low-power nodes. This version uses a fixed set of protocol for low-power nodes. This version uses a fixed set of
skipping to change at page 4, line 7 skipping to change at page 4, line 16
[I-D.daniel-6lowpan-security-analysis] makes a comprehensive analysis [I-D.daniel-6lowpan-security-analysis] makes a comprehensive analysis
of security issues related to 6LoWPAN networks, but its findings also of security issues related to 6LoWPAN networks, but its findings also
apply more generally for all low-powered networks. Some of the apply more generally for all low-powered networks. Some of the
issues this document discusses include the need to minimize the issues this document discusses include the need to minimize the
number of transmitted bits and simplify implementations, threats in number of transmitted bits and simplify implementations, threats in
the smart object networking environments, and the suitability of the smart object networking environments, and the suitability of
6LoWPAN security mechanisms, IPsec, and key management protocols for 6LoWPAN security mechanisms, IPsec, and key management protocols for
implementation in these environments. implementation in these environments.
[I-D.irtf-t2trg-iot-seccons] discusses the overall security problem
for Internet of Things devices. It also discusses various solutions,
including IKEv2/IPsec [RFC7296], TLS/SSL [RFC5246], DTLS [RFC6347],
HIP [RFC7401] [I-D.moskowitz-hip-dex], PANA [RFC5191], and EAP
[RFC3748]. The draft also discusses various operational scenarios,
and challenges associated with implementing security mechanisms in
these environments.
[I-D.sarikaya-t2trg-sbootstrapping] discusses bootstrapping
mechanisms available for resource-constrained IoT devices.
3. Challenges 3. Challenges
This section discusses three challenges: 1) implementation This section discusses three challenges: 1) implementation
difficulties, 2) practical provisioning problems, 3) layering and difficulties, 2) practical provisioning problems, 3) layering and
communication models. communication models.
One of the most often discussed issues in the security for the One of the most often discussed issues in the security for the
Internet of Things relate to implementation difficulties. The desire Internet of Things relate to implementation difficulties. The desire
to build small, battery-operated, and inexpensive devices drives the to build small, battery-operated, and inexpensive devices drives the
creation of devices with a limited protocol and application suite. creation of devices with a limited protocol and application suite.
skipping to change at page 5, line 6 skipping to change at page 4, line 51
order: a particular platform with a resource-constrained order: a particular platform with a resource-constrained
microcontroller is chosen first, and then the security features that microcontroller is chosen first, and then the security features that
can fit on it are decided. Also, the use of the most lightweight can fit on it are decided. Also, the use of the most lightweight
algorithms and cryptographic primitives is useful, but should not be algorithms and cryptographic primitives is useful, but should not be
the only consideration in the design and development. the only consideration in the design and development.
Interoperability is also important, and often other parts of the Interoperability is also important, and often other parts of the
system, such as key management protocols or certificate formats are system, such as key management protocols or certificate formats are
heavier to implement than the algorithms themselves. heavier to implement than the algorithms themselves.
The second challenge relates to practical provisioning problems. The second challenge relates to practical provisioning problems.
These are perhaps the most fundamental and difficult issue, and This is perhaps the most fundamental and difficult issue, and
unfortunately often neglected in the design. There are several unfortunately often neglected in the design. There are several
problems in the provisioning and management of smart object networks: problems in the provisioning and management of smart object networks:
o Small devices have no natural user interface for configuration o Small devices have no natural user interface for configuration
that would be required for the installation of shared secrets and that would be required for the installation of shared secrets and
other security-related parameters. Typically, there is no other security-related parameters. Typically, there is no
keyboard, no display, and there may not even be buttons to press. keyboard, no display, and there may not even be buttons to press.
Some devices may only have one interface, the interface to the Some devices may only have one interface, the interface to the
network. network.
o Manual configuration is rarely, if at all, possible, as the o Manual configuration is rarely, if at all, possible, as the
necessary skills are missing in typical installation environments necessary skills are missing in typical installation environments
(such as in family homes). (such as in family homes).
o There may be a large number of devices. Configuration tasks that o There may be a large number of devices. Configuration tasks that
may be acceptable when performed for one device may become may be acceptable when performed for one device may become
unacceptable with dozens or hundreds of devices. unacceptable with dozens or hundreds of devices.
o Smart object networks may rely on different radio technologies.
Provisioning methods that rely on specific link-layer features may
not work with other radio technologies in a heterogeneous network.
o Network configurations evolve over the lifetime of the devices, as o Network configurations evolve over the lifetime of the devices, as
additional devices are introduced or addresses change. Various additional devices are introduced or addresses change. Various
central nodes may also receive more frequent updates than central nodes may also receive more frequent updates than
individual devices such as sensors embedded in building materials. individual devices such as sensors embedded in building materials.
In light of the above challenges, small resource-constrained devices
are often shipped with a single static identity. In many cases, it
is a single raw public key. These long-term static identities makes
it easy to track the devices (and their owners) when they move. The
static identities may also allow an attacker to track these devices
across ownership changes.
Finally, layering and communication models present difficulties for Finally, layering and communication models present difficulties for
straightforward use of the most obvious security mechanisms. Smart straightforward use of the most obvious security mechanisms. Smart
object networks typically pass information through multiple object networks typically pass information through multiple
participating nodes [I-D.arkko-core-sleepy-sensors] and end-to-end participating nodes [I-D.arkko-core-sleepy-sensors] and end-to-end
security for IP or transport layers may not fit such communication security for IP or transport layers may not fit such communication
models very well. The primary reasons for needing middleboxes models very well. The primary reasons for needing middleboxes
relates to the need to accommodate for sleeping nodes as well to relates to the need to accommodate for sleeping nodes as well to
enable the implementation of nodes that store or aggregate enable the implementation of nodes that store or aggregate
information. information.
skipping to change at page 6, line 10 skipping to change at page 6, line 24
[RFC3972] or Host Identity Tags (HITs) [RFC7401]. That is, we assume [RFC3972] or Host Identity Tags (HITs) [RFC7401]. That is, we assume
the following holds: the following holds:
I = h(P|O) I = h(P|O)
where I is the secure identity of the device, h is a hash function, P 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 is the public key from a key pair generated by the device, and O is
optional other information. | here denotes the concatenation optional other information. | here denotes the concatenation
operator. operator.
5. Provisioning 4.1. Provisioning
As it is difficult to provision security credentials, shared secrets, As it is difficult to provision security credentials, shared secrets,
and policy information, the provisioning model is based only on the and policy information, the provisioning model is based only on the
secure identities. A typical network installation involves physical secure identities. A typical network installation involves physical
placement of a number of devices while noting the identities of these 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 devices. This list of short identifiers can then be fed to a central
server as a list of authorized devices. Secure communications can server as a list of authorized devices. Secure communications can
then commence with the devices, at least as far as information from 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 from the devices to the server is concerned, which is what is needed
for sensor networks. for sensor networks.
skipping to change at page 6, line 46 skipping to change at page 7, line 11
installation time. This requires either a separate user interface, installation time. This requires either a separate user interface,
local connection (such as USB), or using the network interface of the local connection (such as USB), or using the network interface of the
device for configuration. In any case, as with sensor networks the device for configuration. In any case, as with sensor networks the
amount of configuration information is minimized: just one short amount of configuration information is minimized: just one short
identity value needs to be fed in. Not both an identity and a identity value needs to be fed in. Not both an identity and a
certificate. Not shared secrets that must be kept confidential. An certificate. Not shared secrets that must be kept confidential. An
even simpler provisioning approach is that the devices in the device even simpler provisioning approach is that the devices in the device
group trust each other. Then no configuration is needed at group trust each other. Then no configuration is needed at
installation time. installation time.
When both peers know the expected cryptographic identity of the other Once both peers know the expected cryptographic identity of the other
peer off-line, secure communications can commence. Alternatively, peer off-line, secure communications can commence. Alternatively,
various pairing schemes can be employed. Note that these schemes can various pairing schemes can be employed. Note that these schemes can
benefit from the already secure identifiers on the device side. For benefit from the already secure identifiers on the device side. For
instance, the server can send a pairing message to each device after instance, the server can send a pairing message to each device after
their initial power-on and before they have been paired with anyone, their initial power-on and before they have been paired with anyone,
encrypted with the public key of the device. As with all pairing 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 schemes that do not employ a shared secret or the secure identity of
both parties, there are some remaining vulnerabilities that may or both parties, there are some remaining vulnerabilities that may or
may not be acceptable for the application in question. may not be acceptable for the application in question. For example,
leap-of-faith or trust-on-first-use based pairing methods assume that
the attacker is not present during the initial setup and are
vulnerable to eavesdropping or man-in-the-middle (MitM) attacks.
In any case, the secure identities help again in ensuring that the In any case, the secure identities help again in ensuring that the
operations are as simple as possible. Only identities need to be operations are as simple as possible. Only identities need to be
communicated to the devices, not certificates, not shared secrets or communicated to the devices, not certificates, not shared secrets or
e.g. IPsec policy rules. e.g. IPsec policy rules.
Where necessary, the information collected at installation time may Where necessary, the information collected at installation time may
also include other parameters relevant to the application, such as also include other parameters relevant to the application, such as
the location or purpose of the devices. This would enable the server the location or purpose of the devices. This would enable the server
to know, for instance, that a particular device is the temperature to know, for instance, that a particular device is the temperature
skipping to change at page 8, line 5 skipping to change at page 8, line 20
communicate with, messages from the peer can be signed by the peer's 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 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 the expected peer. There is no need to configure an identity and
certificate of that identity separately. There is no need to 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 group secret or a shared secret. There is no need to
configure a trust anchor. In addition, the identities are typically configure a trust anchor. In addition, the identities are typically
collected anyway for application purposes (such as identifying which collected anyway for application purposes (such as identifying which
sensor is in which room). Under most circumstances there is actually sensor is in which room). Under most circumstances there is actually
no additional configuration effort from provisioning security. no additional configuration effort from provisioning security.
As discussed in the previous section, long-term static identities
negatively affect the privacy of the devices and their owners.
Therefore, it is beneficial for devices to generate new identities at
appropriate times during their lifecycle. For example, after a
factory reset or an ownership handover. Thus, in our proposed
deployment model, the devices would generate a new asymmetric key
pair and use the new public-key P' to generate the new identity I'.
It is also desirable that these identities are only used during the
provisioning stage. Temporary identities (such as IPv6 addresses)
can be used for network communication protocols once the device is
operational.
Groups of devices can be managed through single identifiers as well. Groups of devices can be managed through single identifiers as well.
In these deployment cases it is also possible to configure the In these deployment cases it is also possible to configure the
identity of an entire group of devices, rather than registering the identity of an entire group of devices, rather than registering the
individual devices. For instance, many installations employ a kit of individual devices. For instance, many installations employ a kit of
devices bought from the same manufacturer in one package. It is easy devices bought from the same manufacturer in one package. It is easy
to provide an identity for such a set of devices as follows: to provide an identity for such a set of devices as follows:
Idev = h(Pdev|Potherdev1|Potherdev2|...|Potherdevn) Idev = h(Pdev|Potherdev1|Potherdev2|...|Potherdevn)
Igrp = h(Pdev1|Pdev2|...|Pdevm) Igrp = h(Pdev1|Pdev2|...|Pdevm)
skipping to change at page 8, line 31 skipping to change at page 9, line 9
The installation personnel can scan the identity of the group from 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 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 server that is expected to receive information from the nodes. Later
when the individual devices contact this server, they will be able to 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 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 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 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. group identity would change if any new keys were added to Igrp.
6. Protocol Architecture 4.2. Protocol Architecture
As noted above, the starting point of the architecture is that nodes As noted above, the starting point of the architecture is that nodes
self-generate secure identities which are then communicated out-of- self-generate secure identities which are then communicated out-of-
band to the peers that need to know what devices to trust. To 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 support this model in a protocol architecture, we also need to use
these secure identities to implement secure messaging between the these secure identities to implement secure messaging between the
peers, explain how the system can respond to different types of peers, explain how the system can respond to different types of
attacks such as replay attempts, and decide at what protocol layer attacks such as replay attempts, and decide at what protocol layer
and endpoints the architecture should use. and endpoints the architecture should use.
skipping to change at page 9, line 23 skipping to change at page 10, line 5
such as a protocol translators or even NATs (not that we recommend such as a protocol translators or even NATs (not that we recommend
their use in these environments). their use in these environments).
However, as we will see later there are also some technical However, as we will see later there are also some technical
implications, namely that link, network, and transport layer implications, namely that link, network, and transport layer
solutions are more likely to be able to benefit from sessions where solutions are more likely to be able to benefit from sessions where
the cost of expensive operations can be amortized over multiple data the cost of expensive operations can be amortized over multiple data
transmissions. While this is not impossible in data object security transmissions. While this is not impossible in data object security
solutions either, it is not the typical arrangement either. solutions either, it is not the typical arrangement either.
7. Code Availability 5. Code Availability
For implementing public key cryptography on resource constrained For implementing public key cryptography on resource constrained
environments, we chose Arduino Uno board [arduino-uno] as the test environments, we chose Arduino Uno board [arduino-uno] as the test
platform. Arduino Uno has an ATmega328 microcontroller, an 8-bit platform. Arduino Uno has an ATmega328 microcontroller, an 8-bit
processor with a clock speed of 16 MHz, 2 kB of RAM, and 32 kB of processor with a clock speed of 16 MHz, 2 kB of RAM, and 32 kB of
flash memory. Our choice of 8-bit platform may be surprising since flash memory. Our choice of a 8-bit platform may seem surprising
it. since cheaper and more energy-efficient 32-bit platforms are
available. However, our intention was to evaluate the performance of
public-key cryptography on the smallest platforms available. It is
reasonable to expect better performance results from 32-bit
microcontrollers.
For selecting potential asymmetric cryptographic libraries, we For selecting potential asymmetric cryptographic libraries, we
surveyed and came up with a set of possible code sources, and surveyed and came up with a set of possible code sources, and
performed an initial analysis of how well they fit the Arduino performed an initial analysis of how well they fit the Arduino
environment. Note that the results are preliminary, and could easily environment. Note that the results are preliminary, and could easily
be affected in any direction by implementation bugs, configuration be affected in any direction by implementation bugs, configuration
errors, and other mistakes. It is advisable to verify the numbers errors, and other mistakes. It is advisable to verify the numbers
before relying on them for building something. No significant effort before relying on them for building something. No significant effort
was done to optimize ROM memory usage beyond what the libraries was done to optimize ROM memory usage beyond what the libraries
provided themselves, so those numbers should be taken as upper provided themselves, so those numbers should be taken as upper
skipping to change at page 10, line 41 skipping to change at page 11, line 28
o MatrixSSL [matrix-ssl]: This library provides a low footprint o MatrixSSL [matrix-ssl]: This library provides a low footprint
implementation of several cryptographic algorithms including RSA implementation of several cryptographic algorithms including RSA
and ECC (with a commercial license). The library in the original and ECC (with a commercial license). The library in the original
form takes about 50 kB of ROM and is intended for 32-bit form takes about 50 kB of ROM and is intended for 32-bit
platforms. platforms.
o ARM mbed OS [mbed]: The ARM mbed operating system provides various o ARM mbed OS [mbed]: The ARM mbed operating system provides various
cryptographic primitives that are necessary for SSL/TLS protocol cryptographic primitives that are necessary for SSL/TLS protocol
implementation as well as X509 certificate handling. The library implementation as well as X509 certificate handling. The library
provides an intuitive API for developer with a minimal code provides an intuitive API for developer with a minimal code
foodprint. It is intended for various ARM platforms such as ARM footprint. It is intended for various ARM platforms such as ARM
Cortex M0, ARM Cortex M0+ and ARM Cortex M3. Cortex M0, ARM Cortex M0+ and ARM Cortex M3.
This is by no ways an exhaustive list and there exist other This is by no ways an exhaustive list and there exist other
cryptographic libraries targeting resource-constrained devices. cryptographic libraries targeting resource-constrained devices.
8. Implementation Experiences 6. Implementation Experiences
While evaluating the implementation experiences, we were particularly While evaluating the implementation experiences, we were particularly
interested in the signature generation operation. This was because interested in the signature generation operation. This was because
our example application discussed in Section 9 required only the our example application discussed in Section 7 required only the
signature generation operation on the resource-constrained platforms. signature generation operation on the resource-constrained platforms.
We have summarized the initial results of RSA private key We have summarized the initial results of RSA private key
exponentiation performance using AvrCryptolib [avr-crypto-lib] in exponentiation performance using AvrCryptolib [avr-crypto-lib] in
Table 1. All results are from a single run since repeating the test Table 1. All results are from a single run since repeating the test
did not change (or had only minimal impact on) the results. The did not change (or had only minimal impact on) the results. The
execution time for a key size of 2048 bits was inordinately long and execution time for a key size of 2048 bits was inordinately long and
would be a deterrent in real-world deployments. would be a deterrent in real-world deployments.
+--------------+------------------------+---------------------------+ +--------------+------------------------+---------------------------+
| Key length | Execution time (ms); | Memory footprint (bytes); | | Key length | Execution time (ms); | Memory footprint (bytes); |
skipping to change at page 14, line 49 skipping to change at page 15, line 30
Table 6 Table 6
It is important to note the following points about the elliptic curve It is important to note the following points about the elliptic curve
measurements: measurements:
o The Arduino board only provides pseudo random numbers with the o The Arduino board only provides pseudo random numbers with the
random() function call. Real-world deployments must rely on a random() function call. Real-world deployments must rely on a
hardware random number generator for cryptographic operations such hardware random number generator for cryptographic operations such
as generating a public-private key pair. The Nordic nRF52832 as generating a public-private key pair. The Nordic nRF52832
board [nordic] for example provides a hardware random number board [nordic] for example provides a hardware random number
generator. generator. A detailed discussion on requirements and best
practices for cryptographic-quality randomness is documented in
[RFC4086]
o For measuring the memory footprint of all the ECC libraries, we o For measuring the memory footprint of all the ECC libraries, we
used the Avrora simulator [avrora]. Only stack memory was used to used the Avrora simulator [avrora]. Only stack memory was used to
easily track the RAM consumption. easily track the RAM consumption.
Tschofenig and Pegourie-Gonnard [armecdsa] have also evaluated the Tschofenig and Pegourie-Gonnard [armecdsa] have also evaluated the
performance of Elliptic Curve Cryptography (ECC) on ARM Coretex performance of Elliptic Curve Cryptography (ECC) on ARM Coretex
platform. The results for ECDSA sign operation shown in Table 7 are platform. The results for ECDSA sign operation shown in Table 7 are
performed on a Freescale FRDM-KL25Z board [freescale] that has a ARM performed on a Freescale FRDM-KL25Z board [freescale] that has a ARM
Cortex-M0+ 48MHz microcontroller with 128kB of flash memory and 16kB Cortex-M0+ 48MHz microcontroller with 128kB of flash memory and 16kB
skipping to change at page 17, line 35 skipping to change at page 18, line 9
All the measurements here are only provided as an example to show All the measurements here are only provided as an example to show
that asymmetric-key cryptography (particularly, digital signatures) that asymmetric-key cryptography (particularly, digital signatures)
is possible on resource-constrained devices. These numbers by no way is possible on resource-constrained devices. These numbers by no way
are the final source for measurements and some curves presented here are the final source for measurements and some curves presented here
may not be acceptable for real in-the-wild deployments anymore. For may not be acceptable for real in-the-wild deployments anymore. For
example, Mosdorf et al. [mosdorf] and Liu et al. [tinyecc] also example, Mosdorf et al. [mosdorf] and Liu et al. [tinyecc] also
document performance of ECDSA on similar resource-constrained document performance of ECDSA on similar resource-constrained
devices. devices.
9. Example Application 7. Example Application
We developed an example application on the Arduino platform to use We developed an example application on the Arduino platform to use
public key crypto mechanisms, data object security, and an easy public key crypto mechanisms, data object security, and an easy
provisioning model. Our application was originally developed to test provisioning model. Our application was originally developed to test
different approaches to supporting communications to "always off" different approaches to supporting communications to "always off"
sensor nodes. These battery-operated or energy scavenging nodes do sensor nodes. These battery-operated or energy scavenging nodes do
not have enough power to be stay on at all times. They wake up not have enough power to be stay on at all times. They wake up
periodically and transmit their readings. periodically and transmit their readings.
Such sensor nodes can be supported in various ways. Such sensor nodes can be supported in various ways.
skipping to change at page 19, line 40 skipping to change at page 20, line 15
While compiling Relic for our prototype, we used the fast While compiling Relic for our prototype, we used the fast
configuration without any assembly optimizations. configuration without any assembly optimizations.
The gateway implements the CoAP base specification in the Java The gateway implements the CoAP base specification in the Java
programming language and extends it to add support for publish- programming language and extends it to add support for publish-
subscribe broker and Resource Directory REST interfaces. We also subscribe broker and Resource Directory REST interfaces. We also
developed a minimalistic CoAP C-library for the Arduino sensor and developed a minimalistic CoAP C-library for the Arduino sensor and
for the client requesting data updates for a resource. The library for the client requesting data updates for a resource. The library
has small RAM requirements and uses stack-based allocation only. It has small RAM requirements and uses stack-based allocation only. It
is interoperable with the Java implementation of CoAP running on the is interoperable with the Java implementation of CoAP running on the
gateway. The location of the publish-subscribe broker was configured gateway. The location of the resource directory was configured into
into the smart object sensor by hardcoding the IP address. the smart object sensor by hardcoding the IP address.
Our intention was to demonstrate that it is possible to implement the Our intention was to demonstrate that it is possible to implement the
entire architecture with public-key cryptography on an 8-bit entire architecture with public-key cryptography on an 8-bit
microcontroller. The stated values can be improved further by a microcontroller. The stated values can be improved further by a
considerable amount. For example, the flash memory and RAM considerable amount. For example, the flash memory and RAM
consumption is relatively high because some of the Arduino libraries consumption is relatively high because some of the Arduino libraries
were used out-of-the-box and there are several functions which can be were used out-of-the-box and there are several functions which can be
removed. Similarly we used the fast version of the Relic library in removed. Similarly we used the fast version of the Relic library in
the prototype instead of the low memory version. However, it is the prototype instead of the low memory version. However, it is
important to note that this was only a research prototype to verify important to note that this was only a research prototype to verify
the feasibility of this architecture and as stated elsewhere, most the feasibility of this architecture and as stated elsewhere, most
modern development boards have a 32-bit microcontroller since they modern development boards have a 32-bit microcontroller since they
are more economical and have better energy efficiency. are more economical and have better energy efficiency.
10. Design Trade-Offs 8. Design Trade-Offs
This section attempts to make some early conclusions regarding trade- This section attempts to make some early conclusions regarding trade-
offs in the design space, based on deployment considerations for offs in the design space, based on deployment considerations for
various mechanisms and the relative ease or difficulty of various mechanisms and the relative ease or difficulty of
implementing them. This analysis looks at layering and the choice of implementing them. In particular, this analysis looks at layering,
symmetric vs. asymmetric cryptography. freshness and the choice of symmetric vs. asymmetric cryptography.
11. Feasibility 8.1. Feasibility
The first question is whether using cryptographic security and The first question is whether using cryptographic security and
asymmetric cryptography in particular is feasible at all on small asymmetric cryptography in particular is feasible at all on small
devices. The numbers above give a mixed message. Clearly, an devices. The numbers above give a mixed message. Clearly, an
implementation of a significant cryptographic operation such as implementation of a significant cryptographic operation such as
public key signing can be done in surprisingly small amount of code public key signing can be done in surprisingly small amount of code
space. It could even be argued that our chosen prototype platform space. It could even be argued that our chosen prototype platform
was unnecessarily restrictive in the amount of code space it allows: was unnecessarily restrictive in the amount of code space it allows:
we chose this platform on purpose to demonstrate something that is as we chose this platform on purpose to demonstrate something that is as
small and difficult as possible. small and difficult as possible.
skipping to change at page 21, line 9 skipping to change at page 21, line 32
Yet, with reasonably long key sizes the execution times are in the Yet, with reasonably long key sizes the execution times are in the
seconds, dozens of seconds, or even longer. For some applications seconds, dozens of seconds, or even longer. For some applications
this is too long. Nevertheless, the authors believe that these this is too long. Nevertheless, the authors believe that these
algorithms can successfully be employed in small devices for the algorithms can successfully be employed in small devices for the
following reasons: following reasons:
o With the right selection of algorithms and libraries, the o With the right selection of algorithms and libraries, the
execution times can actually be very small (less than 500 ms). execution times can actually be very small (less than 500 ms).
o As discussed in [wiman], in general the power requirements o As discussed in [wiman], in general the power requirements
necessary to send or receive messages are far bigger than those necessary to turn the radio on/off and sending or receiving
needed to execute cryptographic operations. While there are newer messages are far bigger than those needed to execute cryptographic
radios that significantly lower the energy consumption of sending operations. While there are newer radios that significantly lower
and receiving messages, there is no good reason to choose the energy consumption of sending and receiving messages, there is
platforms that do not provide sufficient computing power to run no good reason to choose platforms that do not provide sufficient
the necessary cryptographic operations. computing power to run the necessary cryptographic operations.
o Commercial libraries and the use of full potential for various o Commercial libraries and the use of full potential for various
optimizations will provide a better result than what we arrived at optimizations will provide a better result than what we arrived at
in this memo. in this memo.
o Using public key cryptography only at the beginning of a session o Using public-key cryptography only at the beginning of a session
will reduce the per-packet processing times significantly. will reduce the per-packet processing times significantly.
12. Freshness While we did not do an exhaustive performance evaluation of
asymmetric key pair generation on resource-constrained devices, we
did note that it is possible for such devices to generate a new key
pair. Given that this operation would only occur in rare
circumstances (such as a factory reset or ownership change) and its
potential privacy benefits, developers should provide mechanisms for
generating new identities. It is however extremely important to note
that the security of this operation relies on access to
cryptographic-quality randomness.
8.2. Freshness
In our architecture, if implemented as described thus far, messages In our architecture, if implemented as described thus far, messages
along with their signatures sent from the sensors to the publish- along with their signatures sent from the sensors to the publish-
subscribe broker can be recorded and replayed by an eavesdropper. subscribe broker can be recorded and replayed by an eavesdropper.
The publish-subscribe broker has no mechanism to distinguish The publish-subscribe broker has no mechanism to distinguish
previously received packets from those that are retransmitted by the previously received packets from those that are retransmitted by the
sender or replayed by an eavesdropper. Therefore, it is essential sender or replayed by an eavesdropper. Therefore, it is essential
for the smart objects to ensure that data updates include a freshness for the smart objects to ensure that data updates include a freshness
indicator. However, ensuring freshness on constrained devices can be indicator. However, ensuring freshness on constrained devices can be
non-trivial because of several reasons which include: non-trivial because of several reasons which include:
skipping to change at page 23, line 25 skipping to change at page 24, line 10
obtain the current time from NTP, but this may consume additional obtain the current time from NTP, but this may consume additional
energy and give rise to security issues discussed in [RFC5905]. The energy and give rise to security issues discussed in [RFC5905]. The
smart objects could also have access to a mobile network or the smart objects could also have access to a mobile network or the
Global Positioning System (GPS), and they can be used obtain the Global Positioning System (GPS), and they can be used obtain the
current time. Finally, if the sensors need to co-ordinate their current time. Finally, if the sensors need to co-ordinate their
sleep cycles, or if the publish-subscribe broker computes an average sleep cycles, or if the publish-subscribe broker computes an average
or mean of updates collected from multiple smart objects, it is or mean of updates collected from multiple smart objects, it is
important for the network nodes to synchronize the time among them. important for the network nodes to synchronize the time among them.
This can be done by using existing synchronization schemes. This can be done by using existing synchronization schemes.
13. Layering 8.3. Layering
It would be useful to select just one layer where security is It would be useful to select just one layer where security is
provided at. Otherwise a simple device needs to implement multiple provided at. Otherwise a simple device needs to implement multiple
security mechanisms. While some code can probably be shared across security mechanisms. While some code can probably be shared across
such implementations (like algorithms), it is likely that most of the such implementations (like algorithms), it is likely that most of the
code involving the actual protocol machinery cannot. Looking at the code involving the actual protocol machinery cannot. Looking at the
different layers, here are the choices and their implications: different layers, here are the choices and their implications:
link layer link layer
skipping to change at page 25, line 11 skipping to change at page 25, line 44
The downside is that the lower layers are not protected. But The downside is that the lower layers are not protected. But
again, as long as the data is protected and checked upon every again, as long as the data is protected and checked upon every
time it passes through an application level entity, it is not time it passes through an application level entity, it is not
clear that there are attacks beyond denial-of-service. clear that there are attacks beyond denial-of-service.
The main question mark is whether this type of a solution provides The main question mark is whether this type of a solution provides
sufficient advantages over the more commonly implemented transport sufficient advantages over the more commonly implemented transport
and application layer solutions. and application layer solutions.
14. Symmetric vs. Asymmetric Crypto 8.4. Symmetric vs. Asymmetric Crypto
The second trade-off that is worth discussing is the use of plain The second trade-off that is worth discussing is the use of plain
asymmetric cryptographic mechanisms, plain symmetric cryptographic asymmetric cryptographic mechanisms, plain symmetric cryptographic
mechanisms, or some mixture thereof. mechanisms, or some mixture thereof.
Contrary to popular cryptographic community beliefs, a symmetric Contrary to popular cryptographic community beliefs, a symmetric
cryptographic solution can be deployed in large scale. In fact, one cryptographic solution can be deployed in large scale. In fact, one
of the largest deployment of cryptographic security, the cellular of the largest deployment of cryptographic security, the cellular
network authentication system, uses SIM cards that are based on network authentication system, uses SIM cards that are based on
symmetric secrets. In contrast, public key systems have yet to show symmetric secrets. In contrast, public key systems have yet to show
ability to scale to hundreds of millions of devices, let alone ability to scale to hundreds of millions of devices, let alone
billions. But the authors do not believe scaling is an important billions. But the authors do not believe scaling is an important
differentiator when comparing the solutions. differentiator when comparing the solutions.
As can be seen from the Section 8, the time needed to calculate some As can be seen from the Section 6, the time needed to calculate some
of the asymmetric cryptographic operations with reasonable key of the asymmetric cryptographic operations with reasonable key
lengths can be significant. There are two contrary observations that lengths can be significant. There are two contrary observations that
can be made from this. First, recent wisdom indicates that computing can be made from this. First, recent wisdom indicates that computing
power on small devices is far cheaper than transmission power power on small devices is far cheaper than transmission power
[wiman], and keeps on becoming more efficient very quickly. From [wiman], and keeps on becoming more efficient very quickly. From
this we can conclude that the sufficient CPU is or at least will be this we can conclude that the sufficient CPU is or at least will be
easily available. easily available.
But the other observation is that when there are very costly But the other observation is that when there are very costly
asymmetric operations, doing a key exchange followed by the use of asymmetric operations, doing a key exchange followed by the use of
generated symmetric keys would make sense. This model works very generated symmetric keys would make sense. This model works very
well for DTLS and other transport layer solutions, but works less well for DTLS and other transport layer solutions, but works less
well for data object security, particularly when the number of well for data object security, particularly when the number of
communicating entities is not exactly two. communicating entities is not exactly two.
15. Security Considerations 9. Summary
This document makes several security recommendations based on our
implementation experience. We summarize some of the important ones
here:
o Developers and product designers should choose the hardware after
determining the security requirements for their application
scenario.
o Elliptic Curve Cryptography (ECC) outperforms RSA based operations
and therefore it is recommended for resource-constrained devices.
o Cryptographic-quality randomness is needed for many security
protocols. Developers and vendors should ensure that the
sufficient randomness is available for security critical tasks.
o 32-bit microcontrollers are much more easily available, at lower
costs and are more power efficient. Therefore, real-world
deployments are better off using 32-bit microcontrollers.
o Planning for firmware updates is important. The hardware platform
chosen should at least have a flash memory size of the total code
size * 2, plus some space for buffer.
10. Security Considerations
This entire memo deals with security issues. This entire memo deals with security issues.
16. IANA Considerations 11. IANA Considerations
There are no IANA impacts in this memo. There are no IANA impacts in this memo.
17. Informative references 12. Informative references
[arduino-uno] [arduino-uno]
Arduino, "Arduino Uno", September 2015, Arduino, "Arduino Uno", September 2015,
<http://arduino.cc/en/Main/arduinoBoardUno>. <http://arduino.cc/en/Main/arduinoBoardUno>.
[armecdsa] [armecdsa]
Tschofenig, H. and M. Pegourie-Gonnard, "Performance Tschofenig, H. and M. Pegourie-Gonnard, "Performance
Investigations", March 2015, Investigations", March 2015,
<https://www.ietf.org/proceedings/92/slides/slides-92- <https://www.ietf.org/proceedings/92/slides/
lwig-3.pdf>. slides-92-lwig-3.pdf>.
[avr-crypto-lib] [avr-crypto-lib]
AVR-CRYPTO-LIB, "AVR-CRYPTO-LIB", September 2015, AVR-CRYPTO-LIB, "AVR-CRYPTO-LIB", September 2015,
<http://www.das-labor.org/wiki/AVR-Crypto-Lib/en>. <http://www.das-labor.org/wiki/AVR-Crypto-Lib/en>.
[avr-cryptolib] [avr-cryptolib]
Van der Laan, E., "AVR CRYPTOLIB", September 2015, Van der Laan, E., "AVR CRYPTOLIB", September 2015,
<http://www.emsign.nl/>. <http://www.emsign.nl/>.
[avrora] Titzer, Ben., "Avrora", September 2015, [avrora] Titzer, Ben., "Avrora", September 2015,
skipping to change at page 27, line 14 skipping to change at page 28, line 20
[I-D.ietf-core-coap-pubsub] [I-D.ietf-core-coap-pubsub]
Koster, M., Keranen, A., and J. Jimenez, "Publish- Koster, M., Keranen, A., and J. Jimenez, "Publish-
Subscribe Broker for the Constrained Application Protocol Subscribe Broker for the Constrained Application Protocol
(CoAP)", draft-ietf-core-coap-pubsub-02 (work in (CoAP)", draft-ietf-core-coap-pubsub-02 (work in
progress), July 2017. progress), July 2017.
[I-D.ietf-core-resource-directory] [I-D.ietf-core-resource-directory]
Shelby, Z., Koster, M., Bormann, C., Stok, P., and C. Shelby, Z., Koster, M., Bormann, C., Stok, P., and C.
Amsuess, "CoRE Resource Directory", draft-ietf-core- Amsuess, "CoRE Resource Directory", draft-ietf-core-
resource-directory-11 (work in progress), July 2017. resource-directory-12 (work in progress), October 2017.
[I-D.ietf-core-senml] [I-D.ietf-core-senml]
Jennings, C., Shelby, Z., Arkko, J., Keranen, A., and C. Jennings, C., Shelby, Z., Arkko, J., Keranen, A., and C.
Bormann, "Media Types for Sensor Measurement Lists Bormann, "Media Types for Sensor Measurement Lists
(SenML)", draft-ietf-core-senml-10 (work in progress), (SenML)", draft-ietf-core-senml-12 (work in progress),
July 2017. December 2017.
[I-D.irtf-t2trg-iot-seccons] [I-D.irtf-t2trg-iot-seccons]
Garcia-Morchon, O., Kumar, S., and M. Sethi, "State-of- Garcia-Morchon, O., Kumar, S., and M. Sethi, "State-of-
the-Art and Challenges for the Internet of Things the-Art and Challenges for the Internet of Things
Security", draft-irtf-t2trg-iot-seccons-04 (work in Security", draft-irtf-t2trg-iot-seccons-09 (work in
progress), June 2017. progress), December 2017.
[I-D.moskowitz-hip-dex] [I-D.moskowitz-hip-dex]
Moskowitz, R. and R. Hummen, "HIP Diet EXchange (DEX)", Moskowitz, R. and R. Hummen, "HIP Diet EXchange (DEX)",
draft-moskowitz-hip-dex-05 (work in progress), January draft-moskowitz-hip-dex-05 (work in progress), January
2016. 2016.
[I-D.sarikaya-t2trg-sbootstrapping] [I-D.sarikaya-t2trg-sbootstrapping]
Sarikaya, B., Sethi, M., and A. Sangi, "Secure IoT Sarikaya, B., Sethi, M., and A. Sangi, "Secure IoT
Bootstrapping: A Survey", draft-sarikaya-t2trg- Bootstrapping: A Survey", draft-sarikaya-t2trg-
sbootstrapping-03 (work in progress), February 2017. sbootstrapping-03 (work in progress), February 2017.
skipping to change at page 28, line 23 skipping to change at page 29, line 32
June 2017, <http://infocenter.nordicsemi.com/pdf/ June 2017, <http://infocenter.nordicsemi.com/pdf/
nRF52832_PS_v1.3.pdf>. nRF52832_PS_v1.3.pdf>.
[relic-toolkit] [relic-toolkit]
Aranha, D. and C. Gouv, "Relic Toolkit", September 2015, Aranha, D. and C. Gouv, "Relic Toolkit", September 2015,
<http://code.google.com/p/relic-toolkit/>. <http://code.google.com/p/relic-toolkit/>.
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
Levkowetz, Ed., "Extensible Authentication Protocol Levkowetz, Ed., "Extensible Authentication Protocol
(EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004, (EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004,
<http://www.rfc-editor.org/info/rfc3748>. <https://www.rfc-editor.org/info/rfc3748>.
[RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)",
RFC 3972, DOI 10.17487/RFC3972, March 2005, RFC 3972, DOI 10.17487/RFC3972, March 2005,
<http://www.rfc-editor.org/info/rfc3972>. <https://www.rfc-editor.org/info/rfc3972>.
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker,
"Randomness Requirements for Security", BCP 106, RFC 4086,
DOI 10.17487/RFC4086, June 2005,
<https://www.rfc-editor.org/info/rfc4086>.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, DOI 10.17487/RFC4303, December 2005, RFC 4303, DOI 10.17487/RFC4303, December 2005,
<http://www.rfc-editor.org/info/rfc4303>. <https://www.rfc-editor.org/info/rfc4303>.
[RFC5191] Forsberg, D., Ohba, Y., Ed., Patil, B., Tschofenig, H., [RFC5191] Forsberg, D., Ohba, Y., Ed., Patil, B., Tschofenig, H.,
and A. Yegin, "Protocol for Carrying Authentication for and A. Yegin, "Protocol for Carrying Authentication for
Network Access (PANA)", RFC 5191, DOI 10.17487/RFC5191, Network Access (PANA)", RFC 5191, DOI 10.17487/RFC5191,
May 2008, <http://www.rfc-editor.org/info/rfc5191>. May 2008, <https://www.rfc-editor.org/info/rfc5191>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, (TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008, DOI 10.17487/RFC5246, August 2008,
<http://www.rfc-editor.org/info/rfc5246>. <https://www.rfc-editor.org/info/rfc5246>.
[RFC5406] Bellovin, S., "Guidelines for Specifying the Use of IPsec [RFC5406] Bellovin, S., "Guidelines for Specifying the Use of IPsec
Version 2", BCP 146, RFC 5406, DOI 10.17487/RFC5406, Version 2", BCP 146, RFC 5406, DOI 10.17487/RFC5406,
February 2009, <http://www.rfc-editor.org/info/rfc5406>. February 2009, <https://www.rfc-editor.org/info/rfc5406>.
[RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch,
"Network Time Protocol Version 4: Protocol and Algorithms "Network Time Protocol Version 4: Protocol and Algorithms
Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010,
<http://www.rfc-editor.org/info/rfc5905>. <https://www.rfc-editor.org/info/rfc5905>.
[RFC6078] Camarillo, G. and J. Melen, "Host Identity Protocol (HIP) [RFC6078] Camarillo, G. and J. Melen, "Host Identity Protocol (HIP)
Immediate Carriage and Conveyance of Upper-Layer Protocol Immediate Carriage and Conveyance of Upper-Layer Protocol
Signaling (HICCUPS)", RFC 6078, DOI 10.17487/RFC6078, Signaling (HICCUPS)", RFC 6078, DOI 10.17487/RFC6078,
January 2011, <http://www.rfc-editor.org/info/rfc6078>. January 2011, <https://www.rfc-editor.org/info/rfc6078>.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
January 2012, <http://www.rfc-editor.org/info/rfc6347>. January 2012, <https://www.rfc-editor.org/info/rfc6347>.
[RFC6574] Tschofenig, H. and J. Arkko, "Report from the Smart Object [RFC6574] Tschofenig, H. and J. Arkko, "Report from the Smart Object
Workshop", RFC 6574, DOI 10.17487/RFC6574, April 2012, Workshop", RFC 6574, DOI 10.17487/RFC6574, April 2012,
<http://www.rfc-editor.org/info/rfc6574>. <https://www.rfc-editor.org/info/rfc6574>.
[RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link
Format", RFC 6690, DOI 10.17487/RFC6690, August 2012, Format", RFC 6690, DOI 10.17487/RFC6690, August 2012,
<http://www.rfc-editor.org/info/rfc6690>. <https://www.rfc-editor.org/info/rfc6690>.
[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Message Syntax and Routing", Protocol (HTTP/1.1): Message Syntax and Routing",
RFC 7230, DOI 10.17487/RFC7230, June 2014, RFC 7230, DOI 10.17487/RFC7230, June 2014,
<http://www.rfc-editor.org/info/rfc7230>. <https://www.rfc-editor.org/info/rfc7230>.
[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
Application Protocol (CoAP)", RFC 7252, Application Protocol (CoAP)", RFC 7252,
DOI 10.17487/RFC7252, June 2014, DOI 10.17487/RFC7252, June 2014,
<http://www.rfc-editor.org/info/rfc7252>. <https://www.rfc-editor.org/info/rfc7252>.
[RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T.
Kivinen, "Internet Key Exchange Protocol Version 2 Kivinen, "Internet Key Exchange Protocol Version 2
(IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October
2014, <http://www.rfc-editor.org/info/rfc7296>. 2014, <https://www.rfc-editor.org/info/rfc7296>.
[RFC7401] Moskowitz, R., Ed., Heer, T., Jokela, P., and T. [RFC7401] Moskowitz, R., Ed., Heer, T., Jokela, P., and T.
Henderson, "Host Identity Protocol Version 2 (HIPv2)", Henderson, "Host Identity Protocol Version 2 (HIPv2)",
RFC 7401, DOI 10.17487/RFC7401, April 2015, RFC 7401, DOI 10.17487/RFC7401, April 2015,
<http://www.rfc-editor.org/info/rfc7401>. <https://www.rfc-editor.org/info/rfc7401>.
[RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web
Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May
2015, <http://www.rfc-editor.org/info/rfc7515>. 2015, <https://www.rfc-editor.org/info/rfc7515>.
[RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves [RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves
for Security", RFC 7748, DOI 10.17487/RFC7748, January for Security", RFC 7748, DOI 10.17487/RFC7748, January
2016, <http://www.rfc-editor.org/info/rfc7748>. 2016, <https://www.rfc-editor.org/info/rfc7748>.
[RFC7815] Kivinen, T., "Minimal Internet Key Exchange Version 2 [RFC7815] Kivinen, T., "Minimal Internet Key Exchange Version 2
(IKEv2) Initiator Implementation", RFC 7815, (IKEv2) Initiator Implementation", RFC 7815,
DOI 10.17487/RFC7815, March 2016, DOI 10.17487/RFC7815, March 2016,
<http://www.rfc-editor.org/info/rfc7815>. <https://www.rfc-editor.org/info/rfc7815>.
[RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital
Signature Algorithm (EdDSA)", RFC 8032, Signature Algorithm (EdDSA)", RFC 8032,
DOI 10.17487/RFC8032, January 2017, DOI 10.17487/RFC8032, January 2017,
<http://www.rfc-editor.org/info/rfc8032>. <https://www.rfc-editor.org/info/rfc8032>.
[RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)",
RFC 8152, DOI 10.17487/RFC8152, July 2017, RFC 8152, DOI 10.17487/RFC8152, July 2017,
<http://www.rfc-editor.org/info/rfc8152>. <https://www.rfc-editor.org/info/rfc8152>.
[rsa-8bit] [rsa-8bit]
Gura, N., Patel, A., Wander, A., Eberle, H., and S. Gura, N., Patel, A., Wander, A., Eberle, H., and S.
Shantz, "Comparing Elliptic Curve Cryptography and RSA on Shantz, "Comparing Elliptic Curve Cryptography and RSA on
8-bit CPUs", 2010. 8-bit CPUs", 2010.
[rsa-high-speed] [rsa-high-speed]
Koc, C., "High-Speed RSA Implementation", November 1994, Koc, C., "High-Speed RSA Implementation", November 1994,
<http://cs.ucsb.edu/~koc/docs/r01.pdf>. <http://cs.ucsb.edu/~koc/docs/r01.pdf>.
 End of changes. 63 change blocks. 
96 lines changed or deleted 168 lines changed or added

This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/