Security Considerations in the IP-based Internet of Things
draft-irtf-t2trg-iot-seccons-00
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft that was ultimately published as RFC 8576.
|
|
|---|---|---|---|
| Authors | Oscar Garcia-Morchon , Sandeep Kumar , Mohit Sethi | ||
| Last updated | 2016-10-09 | ||
| Replaces | draft-garcia-core-security | ||
| RFC stream | Internet Research Task Force (IRTF) | ||
| Formats | |||
| IETF conflict review | conflict-review-irtf-t2trg-iot-seccons, conflict-review-irtf-t2trg-iot-seccons, conflict-review-irtf-t2trg-iot-seccons, conflict-review-irtf-t2trg-iot-seccons, conflict-review-irtf-t2trg-iot-seccons, conflict-review-irtf-t2trg-iot-seccons | ||
| Additional resources | Mailing list discussion | ||
| Stream | IRTF state | (None) | |
| Consensus boilerplate | Unknown | ||
| Document shepherd | (None) | ||
| IESG | IESG state | Became RFC 8576 (Informational) | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-irtf-t2trg-iot-seccons-00
Network Working Group O. Garcia-Morchon
Internet-Draft S. Kumar
Intended status: Informational Philips Research
Expires: April 12, 2017 M. Sethi
Ericsson
October 09, 2016
Security Considerations in the IP-based Internet of Things
draft-irtf-t2trg-iot-seccons-00
Abstract
A direct interpretation of the Internet of Things concept refers to
the usage of standard Internet protocols to allow for human-to-thing
or thing-to-thing communication. Although the security needs are
well-recognized, it is still not fully clear how existing IP-based
security protocols can be applied to this new setting. This
Internet-Draft first provides an overview of security architecture,
its deployment model and general security needs in the context of the
lifecycle of a thing. Then, it presents challenges and requirements
for the successful roll-out of new applications and usage of standard
IP-based security protocols when applied to get a functional Internet
of Things.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 12, 2017.
Garcia-Morchon, et al. Expires April 12, 2017 [Page 1]
Internet-Draft Security Considerations for the IoT October 2016
Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Conventions and Terminology Used in this Document . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
3. The Thing Lifecycle and Architectural Considerations . . . . 4
3.1. Threat Analysis . . . . . . . . . . . . . . . . . . . . . 5
3.2. Security Aspects . . . . . . . . . . . . . . . . . . . . 9
4. State of the Art . . . . . . . . . . . . . . . . . . . . . . 12
4.1. IP-based Security Solutions . . . . . . . . . . . . . . . 12
5. Security Levels for the IP-based Internet of Things . . . . . 14
5.1. Security Architecture . . . . . . . . . . . . . . . . . . 18
5.2. Security Model . . . . . . . . . . . . . . . . . . . . . 19
5.3. Security Bootstrapping and Management . . . . . . . . . . 20
5.4. Network Security . . . . . . . . . . . . . . . . . . . . 22
5.5. Application Security . . . . . . . . . . . . . . . . . . 23
6. Challenges and Security Considerations for a Secure Internet
of Things . . . . . . . . . . . . . . . . . . . . . . . . . . 25
6.1. Constraints and Heterogeneous Communication . . . . . . . 25
6.1.1. Tight Resource Constraints . . . . . . . . . . . . . 25
6.1.2. Denial-of-Service Resistance . . . . . . . . . . . . 26
6.1.3. Protocol Translation and End-to-End Security . . . . 27
6.2. Bootstrapping of a Security Domain . . . . . . . . . . . 28
6.3. Operation . . . . . . . . . . . . . . . . . . . . . . . . 28
6.3.1. End-to-End Security . . . . . . . . . . . . . . . . . 29
6.3.2. Group Membership and Security . . . . . . . . . . . . 29
6.3.3. Mobility and IP Network Dynamics . . . . . . . . . . 30
6.4. Software update . . . . . . . . . . . . . . . . . . . . . 30
6.5. Verifying device behavior . . . . . . . . . . . . . . . . 31
6.6. End-of-life . . . . . . . . . . . . . . . . . . . . . . . 32
6.7. Penetration testing . . . . . . . . . . . . . . . . . . . 32
6.8. Quantum-resistance . . . . . . . . . . . . . . . . . . . 32
7. Next Steps towards a Flexible and Secure Internet of Things . 33
8. Security Considerations . . . . . . . . . . . . . . . . . . . 33
Garcia-Morchon, et al. Expires April 12, 2017 [Page 2]
Internet-Draft Security Considerations for the IoT October 2016
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 34
11. Informative References . . . . . . . . . . . . . . . . . . . 34
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40
1. Conventions and Terminology Used in this Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in "Key words for use in
RFCs to Indicate Requirement Levels" [RFC2119].
2. Introduction
The Internet of Things (IoT) denotes the interconnection of highly
heterogeneous networked entities and networks following a number of
communication patterns such as: human-to-human (H2H), human-to-thing
(H2T), thing-to-thing (T2T), or thing-to-things (T2Ts). The term IoT
was first coined by the Auto-ID center [AUTO-ID] in 1999. Since
then, the development of the underlying concepts has ever increased
its pace. Nowadays, the IoT presents a strong focus of research with
various initiatives working on the (re)design, application, and usage
of standard Internet technology in the IoT.
The introduction of IPv6 and web services as fundamental building
blocks for IoT applications [RFC6568] promises to bring a number of
basic advantages including: (i) a homogeneous protocol ecosystem that
allows simple integration with Internet hosts; (ii) simplified
development of very different appliances; (iii) an unified interface
for applications, removing the need for application-level proxies.
Such features greatly simplify the deployment of the envisioned
scenarios ranging from building automation to production environments
to personal area networks, in which very different things such as a
temperature sensor, a luminaire, or an RFID tag might interact with
each other, with a human carrying a smart phone, or with backend
services.
This Internet Draft presents an overview of the security aspects of
the envisioned all-IP architecture as well as of the lifecycle of an
IoT device, a thing, within this architecture. In particular, we
review the most pressing aspects and functionalities that are
required for a secure all-IP solution.
With this, this Internet-Draft pursues several goals. First, we aim
at presenting a comprehensive view of the interactions and
relationships between an IoT application and security. Second, we
aim at describing challenges for a secure IoT in the specific context
of the lifecycle of a resource-constrained device. The final goal of
Garcia-Morchon, et al. Expires April 12, 2017 [Page 3]
Internet-Draft Security Considerations for the IoT October 2016
this draft is to discuss the security considerations that need to be
taken into consideration towards a secure IoT.
The rest of the Internet-Draft is organized as follows. Section 3
depicts the lifecycle of a thing and gives general definitions for
the main security aspects within the IoT domain. In Section 4, we
review existing protocols and work done in the area of security for
wireless sensor networks. Section 5 identifies general challenges
and needs for an IoT security protocol design and discusses existing
protocols and protocol proposals against the identified requirements.
Section 6 proposes a number of illustrative security suites
describing how different applications involve distinct security
needs. Section 7 includes final remarks and conclusions.
3. The Thing Lifecycle and Architectural Considerations
We consider the installation of a Building Automation and Control
(BAC) system to illustrate the lifecycle of a thing but can be
similarly extended to other scenarios. A BAC system consists of a
network of interconnected nodes that perform various functions in the
domains of HVAC (Heating, Ventilating, and Air Conditioning),
lighting, safety etc. The nodes vary in functionality and a majority
of them represent resource constrained devices such as sensors and
luminaries. Some devices may also be battery operated or battery-
less nodes, demanding for a focus on low energy consumption and on
sleeping devices.
In our example, the life of a thing starts when it is manufactured.
Due to the different application areas (i.e., HVAC, lighting, safety)
nodes are tailored to a specific task. It is therefore unlikely that
one single manufacturer will create all nodes in a building. Hence,
interoperability as well as trust bootstrapping between nodes of
different vendors is important. The thing is later installed and
commissioned within a network by an installer during the
bootstrapping phase. Specifically, the device identity and the
secret keys used during normal operation are provided to the device
during this phase. Different subcontractors may install different
IoT devices for different purposes. Furthermore, the installation
and bootstrapping procedures may not be a defined event but may
stretch over an extended period of time. After being bootstrapped,
the device and the system of things are in operational mode and run
the functions of the BAC system. During this operational phase, the
device is under the control of the system owner. For devices with
lifetimes spanning several years, occasional maintenance cycles may
be required. During each maintenance phase, the software on the
device can be upgraded or applications running on the device can be
reconfigured. The maintenance tasks can thereby be performed either
locally or from a backend system. Depending on the operational
Garcia-Morchon, et al. Expires April 12, 2017 [Page 4]
Internet-Draft Security Considerations for the IoT October 2016
changes of the device, it may be required to re-bootstrap at the end
of a maintenance cycle. The device continues to loop through the
operational phase and the eventual maintenance phase until the device
is decommissioned at the end of its lifecycle. However, the end-of-
life of a device does not necessarily mean that it is defective but
rather denotes a need to replace and upgrade the network to next-
generation devices in order to provide additional functionality.
Therefore the device can be removed and re-commissioned to be used in
a different network under a different owner by starting the lifecycle
over again. Figure 1 shows the generic lifecycle of a thing. This
generic lifecycle is also applicable for various IoT scenarios other
than BAC systems.
More recently building control networks employ IP-based standards
allowing seamless control over the various nodes with a single
management system. While allowing for easier integration, this shift
towards IP-based standards results in new requirements regarding the
implementation of IP security protocols on constrained devices and
the bootstrapping of security keys for devices across multiple
manufacturers.
_Manufactured _SW update _Decommissioned
/ / /
| _Installed | _ Application | _Removed &
| / | / reconfigured | / replaced
| | _Commissioned | | | |
| | / | | | | _Reownership &
| | | _Application | | _Application | | / recommissioned
| | | / running | | / running | | |
| | | | | | | | | | \\
+##+##+###+#############+##+##+#############+##+##+##############>>>
\/ \______________/ \/ \_____________/ \___/ time //
/ / \ \ \
Bootstrapping / Maintenance & \ Maintenance &
/ re-bootstrapping \ re-bootstrapping
Operational Operational
Figure 1: The lifecycle of a thing in the Internet of Things.
3.1. Threat Analysis
This section explores the security threats and vulnerabilities of a
network of things in the IoTs. Security threats have been analyzed
in related IP protocols including HTTPS [RFC2818], COAP[RFC7252]
6LoWPAN [RFC4919], ANCP [RFC5713], DNS security threats [RFC3833],
SIP [RFC3261], IPv6 ND [RFC3756], and PANA [RFC4016]. Nonetheless,
the challenge is about their impacts on scenarios of the IoTs. In
this section, we specifically discuss the threats that could
Garcia-Morchon, et al. Expires April 12, 2017 [Page 5]
Internet-Draft Security Considerations for the IoT October 2016
compromise an individual thing, or network as a whole, with regard to
different phases in the thing's lifecycle. Note that these set of
threats might go beyond the scope of Internet protocols but we gather
them here for the sake of completeness.
1. Cloning of things: During the manufacturing process of a thing,
an untrusted manufacturer can easily clone the physical
characteristics, firmware/software, or security configuration of
the thing. Subsequently, such a cloned thing may be sold at a
cheaper price in the market, and yet be still able to function
normally, as a genuine thing. For example, two cloned devices
can still be associated and work with each other. In the worst
case scenario, a cloned device can be used to control a genuine
device. One should note here, that an untrusted manufacturer may
also change functionality of the cloned thing, resulting in
degraded functionality with respect to the genuine thing
(thereby, inflicting potential reputational risk to the original
thing manufacturer). Moreover, it can implement additional
functionality with the cloned thing, such as a backdoor.
2. Malicious substitution of things: During the installation of a
thing, a genuine thing may be substituted with a similar variant
of lower quality without being detected. The main motivation may
be cost savings, where the installation of lower-quality things
(e.g., non-certified products) may significantly reduce the
installation and operational costs. The installers can
subsequently resell the genuine things in order to gain further
financial benefits. Another motivation may be to inflict
reputational damage on a competitor's offerings.
3. Eavesdropping attack: During the commissioning of a thing into a
network, it may be susceptible to eavesdropping, especially if
operational keying materials, security parameters, or
configuration settings, are exchanged in clear using a wireless
medium. After obtaining the keying material, the attacker might
be able to recover the secret keys established between the
communicating entities (e.g., H2T, T2Ts, or Thing to the backend
management system), thereby compromising the authenticity and
confidentiality of the communication channel, as well as the
authenticity of commands and other traffic exchanged over this
communication channel. When the network is in operation, T2T
communication may be eavesdropped upon if the communication
channel is not sufficiently protected or in the event of session
key compromise due to a long period of usage without key renewal
or updates.
4. Man-in-the-middle attack: Both the commissioning phase and
operational phases may also be vulnerable to man-in-the-middle
Garcia-Morchon, et al. Expires April 12, 2017 [Page 6]
Internet-Draft Security Considerations for the IoT October 2016
attacks, e.g., when keying material between communicating
entities is exchanged in the clear and the security of the key
establishment protocol depends on the tacit assumption that no
third party is able to eavesdrop on or sit in between the two
communicating entities during the execution of this protocol.
Additionally, device authentication or device authorization may
be nontrivial, or may need support of a human decision process,
since things usually do not have a priori knowledge about each
other and can, therefore, not always be able to differentiate
friends and foes via completely automated mechanisms. Thus, even
if the key establishment protocol provides cryptographic device
authentication, this knowledge on device identities may still
need complementing with a human-assisted authorization step
(thereby, presenting a weak link and offering the potential of
man-in-the-middle attacks this way).
5. Firmware Replacement attack: When a thing is in operation or
maintenance phase, its firmware or software may be updated to
allow for new functionality or new features. An attacker may be
able to exploit such a firmware upgrade by replacing the thing's
with malicious software, thereby influencing the operational
behavior of the thing. For example, an attacker could add a
piece of malicious code to the firmware that will cause it to
periodically report the energy usage of the lamp to a data
repository for analysis.
6. Extraction of security parameters: A thing deployed in the
ambient environment (such as sensors, actuators, etc.) is usually
physically unprotected and could easily be captured by an
attacker. Such an attacker may then attempt to extract security
information such as keys (e.g., device's key, private-key, group
key) from this thing or try and re-program it to serve his needs.
If a group key is used and compromised this way, the whole
network may be compromised as well. Compromise of a thing's
unique key has less security impact, since only the communication
channels of this particular thing in question are compromised.
Here, one should caution that compromise of the communication
channel may also compromise all data communicated over this
channel. In particular, one has to be weary of, e.g., compromise
of group keys communicated over this channel (thus, leading to
transitive exposure ripple effects).
7. Routing attack: As highlighted in [ID-Daniel], routing
information in IoT can be spoofed, altered, or replayed, in order
to create routing loops, attract/repel network traffic, extend/
shorten source routes, etc. Other relevant routing attacks
include 1) Sinkhole attack (or blackhole attack), where an
attacker declares himself to have a high-quality route/path to
Garcia-Morchon, et al. Expires April 12, 2017 [Page 7]
Internet-Draft Security Considerations for the IoT October 2016
the base station, thus allowing him to do anything to all packets
passing through it. 2) Selective forwarding, where an attacker
may selectively forward packets or simply drop a packet. 3)
Wormhole attack, where an attacker may record packets at one
location in the network and tunnel them to another location,
thereby influencing perceived network behavior and potentially
distorting statistics, thus greatly impacting the functionality
of routing. 4) Sybil attack, whereby an attacker presents
multiple identities to other things in the network.
8. Privacy threat: The tracking of a thing's location and usage may
pose a privacy risk to its users. An attacker can infer
information based on the information gathered about individual
things, thus deducing behavioral patterns of the user of interest
to him. Such information can subsequently be sold to interested
parties for marketing purposes and targeted advertising.
9. Denial-of-Service attack: Typically, things have tight memory and
limited computation, they are thus vulnerable to resource
exhaustion attack. Attackers can continuously send requests to
be processed by specific things so as to deplete their resources.
This is especially dangerous in the IoTs since an attacker might
be located in the backend and target resource-constrained devices
in an LLN. Additionally, DoS attack can be launched by
physically jamming the communication channel, thus breaking down
the T2T communication channel. Network availability can also be
disrupted by flooding the network with a large number of packets.
The following table summarizes the security threats we identified
above and the potential point of vulnerabilities at different layers
of the communication stack. We also include related RFCs that
include a threat model that might apply to the IoTs.
Garcia-Morchon, et al. Expires April 12, 2017 [Page 8]
Internet-Draft Security Considerations for the IoT October 2016
+------------------+------------------+------------------+
| Manufacturing | Installation/ | Operation |
| | Commissioning | |
+------------+------------------+------------------+------------------+
|Thing's | Device Cloning |Substitution |Privacy threat |
|Model | |ACE-OAuth(draft) |Extraction of |
| | | |security params |
+------------+------------------+------------------+------------------+
|Application | |RFC2818, RFC7252 |RFC2818, Firmware |
|Layer | |OSCOAP(draft) |replacement |
+------------+------------------+------------------+------------------+
|Transport | | Eavesdropping & |Eavesdropping |
|Layer | | Man-in-the-middle|Man-in-the-middle |
+------------+------------------| attack, RFC7925 |------------------+
|Network | | RFC4919, RFC5713 |RFC4919,DoS attack|
|Layer | | RFC3833, RFC3756 |Routing attack |
| | | |RFC3833 |
+------------+------------------+------------------+------------------+
|Physical | | |DoS attack |
|Layer | | | |
+-------------------------------+------------------+------------------+
Figure 2: The security threat analysis
3.2. Security Aspects
The term security subsumes a wide range of different concepts. In
the first place, it refers to the basic provision of security
services including confidentiality, authentication, integrity,
authorization, non-repudiation, and availability, and some augmented
services, such as duplicate detection and detection of stale packets
(timeliness). These security services can be implemented by a
combination of cryptographic mechanisms, such as block ciphers, hash
functions, or signature algorithms, and non-cryptographic mechanisms,
which implement authorization and other security policy enforcement
aspects. For each of the cryptographic mechanisms, a solid key
management infrastructure is fundamental to handling the required
cryptographic keys, whereas for security policy enforcement, one
needs to properly codify authorizations as a function of device roles
and a security policy engine that implements these authorization
checks and that can implement changes hereto throughout the system's
lifecycle.
In the context of the IoT, however, the security must not only focus
on the required security services, but also how these are realized in
the overall system and how the security functionalities are executed.
To this end, we use the following terminology to analyze and classify
security aspects in the IoT:
Garcia-Morchon, et al. Expires April 12, 2017 [Page 9]
Internet-Draft Security Considerations for the IoT October 2016
1. The security architecture refers to the system elements involved
in the management of the security relationships between things
and the way these security interactions are handled (e.g.,
centralized or distributed) during the lifecycle of a thing.
2. The security model of a node describes how the security
parameters, processes, and applications are managed in a thing.
This includes aspects such as process separation, secure storage
of keying materials, etc.
3. Security bootstrapping denotes the process by which a thing
securely joins the IoT at a given location and point in time.
Bootstrapping includes the authentication and authorization of a
device as well as the transfer of security parameters allowing
for its trusted operation in a given network.
4. Network security describes the mechanisms applied within a
network to ensure trusted operation of the IoT. Specifically, it
prevents attackers from endangering or modifying the expected
operation of networked things. Network security can include a
number of mechanisms ranging from secure routing to data link
layer and network layer security.
5. Object security describes mechanisms to allow transfer of secured
blocks of data with end-to-end assurances independent of
communication pattern, for e.g through proxies or other store-
and-forward mechanisms.
6. Application security guarantees that only trusted instances of an
application running in the IoT can communicate with each other,
while illegitimate instances cannot interfere.
Garcia-Morchon, et al. Expires April 12, 2017 [Page 10]
Internet-Draft Security Considerations for the IoT October 2016
..........................
: +-----------+:
: *+*>|Application|*****
: *| +-----------+: *
: *| +-----------+: *
: *|->| Transport |: *
: * _*| +-----------+: *
: *| | +-----------+: *
: *| |->| Network |: *
: *| | +-----------+: *
: *| | +-----------+: * *** Bootstrapping
: *| +->| L2 |: * ~~~ Transport Security
: *| +-----------+: * ''' Object Security
:+--------+ : *
:|Security| Configuration: *
:|Service | Entity : *
:+--------+ : *
:........................: *
*
......................... * .........................
:+--------+ : * : +--------+:
:|Security| Node B : * : Node A |Security|:
:|Service | : * : |Service |:
:+--------+ : * : +--------+:
: | +-----------+: * :+-----------+ |* :
: | +->|Application|: ****|Application|<*+* |* :
: | | +-----------+:''''''''''''''''''''+-----------+ |* |* :
: | | +-----------+: :+-----------+ |* |* :
: | |->| Transport |~~~~~~~~~~~~~~~~~~~~~| Transport |<-|* |* :
: |__| +-----------+: ................. :+-----------+ |*_|* :
: | +-----------+: : +-----------+ : :+-----------+ | * :
: |->| Network |: : | Network | : :| Network |<-| :
: | +-----------+: : +-----------+ : :+-----------+ | :
: | +-----------+: : +-----------+ : :+-----------+ | :
: +->| L2 |: : | L2 | : :| L2 |<-+ :
: +-----------+: : +-----------+ : :+-----------+ :
:.......................: :...............: :.......................:
Overview of Security Mechanisms.
Figure 3
We now discuss an exemplary security architecture relying on a
configuration entity for the management of the system with regard to
the introduced security aspects (see Figure 2). Inspired by the
security framework for routing over low power and lossy network
[ID-Tsao], we show an example of security model and illustrates how
different security concepts and the lifecycle phases map to the
Internet communication stack. Assume a centralized architecture in
Garcia-Morchon, et al. Expires April 12, 2017 [Page 11]
Internet-Draft Security Considerations for the IoT October 2016
which a configuration entity stores and manages the identities of the
things associated with the system along with their cryptographic
keys. During the bootstrapping phase, each thing executes the
bootstrapping protocol with the configuration entity, thus obtaining
the required device identities and the keying material. The security
service on a thing in turn stores the received keying material for
the network layer and application security mechanisms for secure
communication. Things can then securely communicate with each other
during their operational phase by means of the employed network and
application security mechanisms.
4. State of the Art
Nowadays, there exists a multitude of control protocols for the IoT.
For BAC systems, the ZigBee standard [ZB], BACNet [BACNET], or DALI
[DALI] play key roles. Recent trends, however, focus on an all-IP
approach for system control.
In this setting, a number of IETF working groups are designing new
protocols for resource constrained networks of smart things. The
6LoWPAN working group [WG-6LoWPAN] concentrates on the definition of
methods and protocols for the efficient transmission and adaptation
of IPv6 packets over IEEE 802.15.4 networks [RFC4944]. The CoRE
working group [WG-CoRE] provides a framework for resource-oriented
applications intended to run on constrained IP network (6LoWPAN).
One of its main tasks is the definition of a lightweight version of
the HTTP protocol, the Constrained Application Protocol (CoAP)
[RFC7252], that runs over UDP and enables efficient application-level
communication for things. Also IRTF groups are actively contributing
to improve IoT security.
Additionally industry alliances like Thread [Thread] are creating
constrained IP protocol stacks based on the IETF work.
4.1. IP-based Security Solutions
In the context of the IP-based IoT solutions, consideration of TCP/IP
security protocols is important as these protocols are designed to
fit the IP network ideology and technology. There are a wide range
of specialized as well as general-purpose key exchange and security
solutions exist for the Internet domain such as IKEv2/IPsec
[RFC7296], TLS/SSL [RFC5246], DTLS [RFC5238], HIP [RFC7401], PANA
[RFC5191], and EAP [RFC3748]. Some of these solutions are also been
investigated now, such as, e.g., OSCOAP. Figure 3 depicts the
relationships between the discussed protocols in the context of the
security terminology introduced in Section 3.1.
Garcia-Morchon, et al. Expires April 12, 2017 [Page 12]
Internet-Draft Security Considerations for the IoT October 2016
..........................
: +-----------+:
: *+*>|Application|***** *** Bootstrapping
: *| +-----------+: * ### Transport Security
: *| +-----------+: * === Network security
: *|->| Transport |: * ... Object security
: * _*| +-----------+: *
: *| | +-----------+: *
: *| |->| Network |: *--> -PANA/EAP
: *| | +-----------+: * -HIP
: *| | +-----------+: *
: *| +->| L2 |: * ## DTLS
: *| +-----------+: * .. OSCOAP
:+--------+ : *
:|Security| Configuration: * [] HIP,IKEv2
:|Service | Entity : * [] ESP/AH
:+--------+ : *
:........................: *
*
......................... * .........................
:+--------+ : * : +--------+:
:|Security| Node B : Secure * : Node A |Security|:
:|Service | : routing * : |Service |:
:+--------+ : framework * : +--------+:
: | +-----------+: | **** :+-----------+ |* :
: | +->|Application|:........|............:|Application|<*+* |* :
: | | +----##-----+: | :+----##-----+ |* |* :
: | | +----##-----+: | :+----##-----+ |* |* :
: | |->| Transport |#########|#############| Transport |<-|* |* :
: |__| +----[]-----+: ......|.......... :+----[]-----+ |*_|* :
: | +====[]=====+=====+===========+=====+====[]=====+ | * :
: |->|| Network |: : | Network | : :| Network ||<-| :
: | +|----------+: : +-----------+ : :+----------|+ | :
: | +|----------+: : +-----------+ : :+----------|+ | :
: +->|| L2 |: : | L2 | : :| L2 ||<-+ :
: +===========+=====+===========+=====+===========+ :
:.......................: :...............: :.......................:
Relationships between IP-based security protocols.
Figure 4
The Internet Key Exchange (IKEv2)/IPsec and the Host Identity
protocol (HIP) reside at or above the network layer in the OSI model.
Both protocols are able to perform an authenticated key exchange and
set up the IPsec transforms for secure payload delivery. Currently,
there are also ongoing efforts to create a HIP variant coined Diet
HIP [ID-HIP] that takes lossy low-power networks into account at the
authentication and key exchange level.
Garcia-Morchon, et al. Expires April 12, 2017 [Page 13]
Internet-Draft Security Considerations for the IoT October 2016
Transport Layer Security (TLS) and its datagram-oriented variant DTLS
secure transport-layer connections. TLS provides security for TCP
and requires a reliable transport, while DTLS secures and uses
datagram-oriented protocols such as UDP. Both protocols are
intentionally kept similar and share the same ideology and cipher
suites.
The Extensible Authentication Protocol (EAP) is an authentication
framework supporting multiple authentication methods. EAP runs
directly over the data link layer and, thus, does not require the
deployment of IP. It supports duplicate detection and
retransmission, but does not allow for packet fragmentation. The
Protocol for Carrying Authentication for Network Access (PANA) is a
network-layer transport for EAP that enables network access
authentication between clients and the network infrastructure. In
EAP terms, PANA is a UDP-based EAP lower layer that runs between the
EAP peer and the EAP authenticator.
In addition, there is also new activities in IETF and W3C to define
security protocols better tailored to IoT or for specific deployment
situations. The ACE WG is designing an authorization mechanism based
on OAuth for constrained devices. There is work on Object Security
based CoAP protection mechanism being defined in OSCOAP. <<similar
work in W3C - Oliver?>>
5. Security Levels for the IP-based Internet of Things
Different applications have different security requirements and needs
and, depending on various factors, such as device capability,
availability of network infrastructure, security services needed,
usage, etc., the required security protection may vary from "simple
security" to "full-blown security". For example, applications may
have different needs regarding authentication and confidentiality.
While some application might not require any authentication at all,
others might require strong end-to-end authentication. In terms of
secure bootstrapping of keys, some applications might assume the
existence and online availability of a central key-distribution-
center (KDC) within the 6LoWPAN network to distribute and manage
keys; while other applications cannot rely on such a central party or
their availability.
Thus, it is essential to define security profiles to better tailor
security solutions for different applications with the same
characteristics and requirements. This provides a means of grouping
applications into profiles and then defines the minimal required
security primitives to enable and support the security needs of the
profile. The security elements in a security profile can be
classified according to Section 3.1, namely:
Garcia-Morchon, et al. Expires April 12, 2017 [Page 14]
Internet-Draft Security Considerations for the IoT October 2016
1 Security architecture,
2 Security model,
3 Security bootstrapping,
4 Network security, and
5 Application security.
In order to (i) guide the design process by identifying open gaps;
(ii) allow for later interoperability; and (iii) prevent possible
security misconfigurations, this section defines a number of generic
security profiles with different security needs. Each security
profile is identified by:
1. a short description,
2. an exemplary application that might use/require such a security
policy,
3. the security requirements for each of the above security aspects
according to our classification in Section 3.1.
These security profiles can serve to guide the standardization
process, since these explicitly describe the basic functionalities
and protocols required to get different use cases up and running. It
can allow for later interoperability since different manufacturers
can describe the implemented security profile in their products.
Finally, the security profiles can avoid possible security
misconfigurations, since each security profile can be bound to a
different application area so that it can be clearly defined which
security protocols and approaches can be applied where and under
which circumstances.
Note that each of these security profiles aim at summarizing the
required security requirements for different applications and at
providing a set of initial security features. In other words, these
profiles reflect the need for different security configurations,
depending on the threat and trust models of the underlying
applications. In this sense, this section does not provide an
overview of existing protocols as done in previous sections of the
Internet Draft, but it rather explicitly describes what should be in
place to ensure secure system operation. Observe also that this list
of security profiles is not exhaustive and that it should be
considered just as an example not related to existing legal
regulations for any existing application. These security profiles
are summarized in the table below:
Garcia-Morchon, et al. Expires April 12, 2017 [Page 15]
Internet-Draft Security Considerations for the IoT October 2016
+---------------------------------------------------------+
| Exemnplary | |
| Application | Description |
+----------+---------------------------------------------------------+
|SecProf_1 |Home usage |Enables operation between home things |
| | |without interaction with central device|
+----------+-----------------+---------------------------------------+
|SecProf_2 |Managed Home |Enables operation between home things. |
| | usage |Interaction with a central and local |
| | |device is possible |
+----------+-----------------+---------------------------------------+
|SecProf_3 |Industrial usage |Enables operation between things. |
| | |Relies on central (local or backend) |
| | |device for security |
+----------+-----------------+---------------------------------------+
|SecProf_4 |Advanced |Enables ad-hoc operation between things|
| |Industrial usage |and relies on central device or |
| | |on a collection of control devices |
+----------+-----------------+---------------------------------------+
Figure 5: Security profiles and application areas.
The classification in the table considers different potential
applications and situations in which their security needs change due
to different operational features (network size, existence of a
central device, connectivity to the Internet, importance of the
exchanged information, etc) or threat model (what are the assets that
an attacker looks for). As already pointed out, this set of
scenarios is exemplary and they should be further discussed based on
a broader consensus.
The security suite (SecProf_1) is catered for environments in which
IP protocols (e.g., 6LoWPAN/CoAP) can be used to enable communication
between things in an ad-hoc manner and the security requirements are
minimal. An example, is a home application in which two devices
should exchange information and no further connection with other
devices (local or with a backend) is required. In this scenario,
value of the exchanged information is low and that it usually happen
in a confined room, thus, it is possible to have a short period of
time during which initial secrets can be exchanged in the clear. Due
to this fact, there is no requirement to enable devices from
different manufacturers to interoperate in a secure way (keys are
just exchanged). The expected network size of applications using
this profile is expected to be small such that the provision of
network security, e.g., secure routing, is of low importance.
The next security suite (SecProf_2) represents an evolution of
SecProf_1 in which, e.g., home devices, can be managed locally. A
Garcia-Morchon, et al. Expires April 12, 2017 [Page 16]
Internet-Draft Security Considerations for the IoT October 2016
first possibility for the securing domain management refers to the
creation of a centrally managed security domain without any
connectivity to the Internet. The central device used for management
can serve as, e.g., a key distribution center including policies for
key update, storage, etc. The presence of a central device can help
in the management of larger networks. Network security becomes more
relevant in this scenario since the IP network (e.g., 6LoWPAN/CoAP
network) can be prone to Denial of Service attacks (e.g., flooding if
L2 is not protected) or routing attacks.
SecProf_3 considers that a central device is always required for
network management. Example applications of this profile include
building control and automation, sensor networks for industrial use,
environmental monitoring, etc. As before, the network manager can be
located in the IP network (e.g., 6LoWPAN/CoAP network) and handle key
management. In this case, the first association of devices to the
network is required to be done in a secure way. In other words, the
threat model requires measurements to protect against any vulnerable
period of time. This step can involve the secure transmission of
keying materials used for network security at different layers. The
information exchanged in the network is considered to be valuable and
it should be protected in the sense of pairwise links. Commands
should be secured and broadcast should be secured with entity
authentication [RFC7390]. Network should be protected from attacks.
A further extension to this use case is to allow for remote
management. A "backend manager" is in charge of managing SW or
information exchanged or collected within the IP network, e.g., a
6LoWPAN/CoAP network. This requires connection of devices to the
Internet over a 6LBR involving a number of new threats that were not
present before. A list of potential attacks include: resource-
exhaustion attacks from the Internet; amplification attacks; trust
issues related a HTTP-CoAP proxy [ID-proHTTPCoAP], etc. This use
case requires protecting the communication from a device in the
backend to a device in the IP network, e.g., a 6LoWPAN/CoAP network,
end-to-end. This use case also requires measures to provide the 6LBR
with the capability of dropping fake requests coming from the
Internet. This becomes especially challenging when the 6LBR is not
trusted and access to the exchanged information is limited; and even
more in the case of a HTTP-CoAP proxy since protocol translation is
required. This use case should take care of protecting information
accessed from the backend due to privacy issues (e.g., information
such as type of devices, location, usage, type and amount of
exchanged information, or mobility patterns can be gathered at the
backend threatening the privacy sphere of users) so that only
required information is disclosed.
The last security suite (SecProf_4) essentially represents
interoperability of all the security profiles defined previously. It
Garcia-Morchon, et al. Expires April 12, 2017 [Page 17]
Internet-Draft Security Considerations for the IoT October 2016
considers applications with some additional requirements regarding
operation such as: (i) ad-hoc establishment of security relationships
between things (potentially from different manufacturers) in non-
secure environments or (ii) dynamic roaming of things between
different IP network security domains. Such operational requirements
pose additional security requirements, e.g., in addition to secure
bootstrapping of a device within an IP, e.g., 6LowPan/CoAP, security
domain and the secure transfer of network operational key, there is a
need to enable inter-domains secure communication to facilitate data
sharing.
The above description illustrates how different applications of IP
networks, e.g., 6LoWPAN/CoAP networks, involve different security
needs. In the following sections, we summarize the expected security
features or capabilities for each the security profile with regards
to "Security Architecture", "Security Model", "Security
Bootstrapping", "Network Security", and "Application Security".
5.1. Security Architecture
Most things might be required to support both centralized and
distributed operation patterns. Distributed thing-to-thing
communication might happen on demand, for instance, when two things
form an ad-hoc security domain to cooperatively fulfill a certain
task. Likewise, nodes may communicate with a backend service located
in the Internet without a central security manager. The same nodes
may also be part of a centralized architecture with a dedicated node
being responsible for the security management for group communication
between things in the IoT domain. In today's IoT, most common
architectures are fully centralized in the sense that all the
security relationships within a segment are handled by a central
party. In the ZigBee standard, this entity is the trust center.
Current proposals for 6LoWPAN/CoRE identify the 6LoWPAN Border Router
(6LBR) as such a device.
A centralized architecture allows for central management of devices
and keying materials as well as for the backup of cryptographic keys.
However, it also imposes some limitations. First, it represents a
single point of failure. This is a major drawback, e.g., when key
agreement between two devices requires online connectivity to the
central node. Second, it limits the possibility to create ad-hoc
security domains without dedicated security infrastructure. Third,
it codifies a more static world view, where device roles are cast in
stone, rather than a more dynamic world view that recognizes that
networks and devices, and their roles and ownership, may change over
time (e.g., due to device replacement and hand-over of control).
Garcia-Morchon, et al. Expires April 12, 2017 [Page 18]
Internet-Draft Security Considerations for the IoT October 2016
Decentralized architectures, on the other hand, allow creating ad-hoc
security domains that might not require a single online management
entity and are operative in a much more stand-alone manner. The ad-
hoc security domains can be added to a centralized architecture at a
later point in time, allowing for central or remote management.
The choice of security architecture has many implications regarding
key management, access control, or security scope. A distributed (or
ad-hoc) architecture means that security relationships between things
are setup on the fly between a number of objects and kept in a
decentralized fashion. A locally centralized security architecture
means that a central device, e.g., the 6LBR, handles the keys for all
the devices in the security domain. Alternatively, a central
security architecture could also refer to the fact that smart objects
are managed from the backend. The security architecture for the
different security profiles is classified as follows.
+---------------------------------------------------------+
| Description |
+----------+---------------------------------------------------------+
|SecProf_1 | Distributed |
+----------+---------------------------------------------------------+
|SecProf_2 | Distributed able to move centralized (local) |
+----------+---------------------------------------------------------+
|SecProf_3 | Centralized (local &/or backend) |
+----------+---------------------------------------------------------+
|SecProf_4 | Distributed & centralized (local &/or backend) |
+----------+---------------------------------------------------------+
Figure 6: Security architectures in different security profiles.
In "SecProf_1", management mechanisms for the distributed assignment
and management of keying materials is required. Since this is a very
simple use case, access control to the security domain can be enabled
by means of a common secret known to all devices. In the next
security suite (SecProf_2), a central device can assume key
management responsibilities and handle the access to the network.
The last two security suites (SecProf_3 and SecProf_4) further allow
for the management of devices or some keying materials from the
backend.
5.2. Security Model
While some applications might involve very resource-constrained
things such as, e.g., a humidity, pollution sensor, other
applications might target more powerful devices aimed at more exposed
applications. Security parameters such as keying materials,
certificates, etc must be protected in the thing, for example by
Garcia-Morchon, et al. Expires April 12, 2017 [Page 19]
Internet-Draft Security Considerations for the IoT October 2016
means of tamper-resistant hardware. Keys may be shared across a
thing's networking stack to provide authenticity and confidentiality
in each networking layer. This would minimize the number of key
establishment/agreement handshake and incurs less overhead for
constrained thing. While more advance applications may require key
separation at different networking layers, and possibly process
separation and sandboxing to isolate one application from another.
In this sense, this section reflects the fact that different
applications require different sets of security mechanisms.
+---------------------------------------------------------+
|Description |
+----------+---------------------------------------------------------+
|SecProf_1 |No tamper resistant |
| |Sharing keys between layers |
+----------+---------------------------------------------------------+
|SecProf_2 |No tamper resistant |
| |Sharing keys between layers |
+----------+---------------------------------------------------------+
|SecProf_3 |Tamper resistant |
| |Key and process separation |
+----------+---------------------------------------------------------+
|SecProf_4 |(no) Tamper resistant |
| |Sharing keys between layers/Key and process separation |
| |Sandbox |
+----------+---------------------------------------------------------+
Figure 7: Thing security models in different security profiles.
5.3. Security Bootstrapping and Management
Bootstrapping refers to the process by which a thing initiates its
life within a security domain and includes the initialization of
secure and/or authentic parameters bound to the thing and at least
one other device in the network. Here, different mechanisms may be
used to achieve confidentiality and/or authenticity of these
parameters, depending on deployment scenario assumptions and the
communication channel(s) used for passing these parameters. The
simplest mechanism for initial set-up of secure and authentic
parameters is via communication in the clear using a physical
interface (USB, wire, chip contact, etc.). Here, one commonly
assumes this communication channel is secure, since eavesdropping
and/or manipulation of this interface would generally require access
to the physical medium and, thereby, to one or both of the devices
themselves. This mechanism was used with the so-called original
"resurrecting duckling" model, as introduced in [PROC-Stajano-99].
This technique may also be used securely in wireless, rather than
wired, set-ups, if the prospect of eavesdropping and/or manipulating
Garcia-Morchon, et al. Expires April 12, 2017 [Page 20]
Internet-Draft Security Considerations for the IoT October 2016
this channel are dim (a so-called "location-limited" channel
[PROC-Smetters-04][PROC-Smetters-02]). Examples hereof include the
communication of secret keys in the clear using near field
communication (NFC) - where the physical channel is purported to have
very limited range (roughly 10cm), thereby thwarting eavesdropping by
far-away adversarial devices, and in-the-clear communication during a
small time window (triggered by, e.g., a button-push) - where
eavesdropping is presumed absent during this small time window. With
the use of public-key based techniques, assumptions on the
communication channel can be relaxed even further, since then the
cryptographic technique itself provides for confidentiality of the
channel set-up and the location-limited channel - or use of
certificates - rules out man-in-the-middle attacks, thereby providing
authenticity [PROC-Smetters-02]. The same result can be obtained
using password-based public-key protocols [SPEKE], where authenticity
depends on the (weak) password not being guessed during execution of
the protocol.
It should be noted that while most of these techniques realize a
secure and authentic channel for passing parameters, these generally
do not provide for explicit authorization. As an example, with use
of certificate-based public-key based techniques, one may obtain hard
evidence on whom one shares secret and/or authentic parameters with,
but this does not answer the question as to whether one wishes to
share this information at all with this specifically identified
device (the latter usually involves a human-decision element). Thus,
the bootstrapping mechanisms above should generally be complemented
by mechanisms that regulate (security policies for) authorization.
Furthermore, the type of bootstrapping is very related to the
required type of security architecture. Distributed bootstrapping
means that a pair of devices can setup a security relationship on the
fly, without interaction with a central device elsewhere within the
system. In many cases, it is handy to have a distributed
bootstrapping protocol based on existing security protocols (e.g.,
DTLS in CoAP) required for other purposes: this reduces the amount of
required software. A centralized bootstrapping protocol is one in
which a central device manages the security relationships within a
network. This can happen locally, e.g., handled by the 6LBR, or
remotely, e.g., from a server connected via the Internet. The
security bootstrapping for the different security profiles is as
follows.
Garcia-Morchon, et al. Expires April 12, 2017 [Page 21]
Internet-Draft Security Considerations for the IoT October 2016
+---------------------------------------------------------+
|Description |
+----------+---------------------------------------------------------+
|SecProf_1 |* Distributed, (e.g., Resurrecting duckling) |
| |* First key distribution happens in the clear |
+----------+---------------------------------------------------------+
|SecProf_2 |* Distributed, (e.g., Resurrecting duckling ) |
| |* Centralized (local), 6LBR acts as KDC |
| |* First key distribution occurs in the clear, if the KDC |
| | is available, the KDC can manage network access |
+----------+---------------------------------------------------------+
|SecProf_3 |* 6LBR acts as KDC. It handles node joining, provides |
| | them with keying material from L2 to application layers|
| |* Bootstrapping occurs in a secure way - either in secure|
| | environment or the security mechanisms ensure that |
| | eavesdropping is not possible. |
| |* KDC and backend can implement secure methods for |
| | network access |
+----------+---------------------------------------------------------+
|SecProf_4 |* As in SecProf_3. |
+----------+---------------------------------------------------------+
Figure 8: Security bootstrapping methods in different security
profiles
5.4. Network Security
Network security refers to the mechanisms used to ensure the secure
transport of 6LoWPAN frames. This involves a multitude of issues
ranging from secure discovery, frame authentication, routing
security, detection of replay, secure group communication, etc.
Network security is important to thwart potential attacks such as
denial-of-service (e.g., through message flooding) or routing
attacks.
The Internet Draft [ID-Tsao] presents a very good overview of attacks
and security needs classified according to the confidentiality,
integrity, and availability needs. A potential limitation is that
there exist no differentiation in security between different use
cases and the framework is limited to L3. The security suites
gathered in the present ID aim at solving this by allowing for a more
flexible selection of security needs at L2 and L3.
Garcia-Morchon, et al. Expires April 12, 2017 [Page 22]
Internet-Draft Security Considerations for the IoT October 2016
+---------------------------------------------------------+
|Description |
+----------+---------------------------------------------------------+
|SecProf_1 |* Network key creating a home security domain at L2 |
| | ensuring authentication and freshness of exchanged data|
| |* Secure multicast does not ensure origin authentication |
| |* No need for secure routing at L3 |
+----------+---------------------------------------------------------+
|SecProf_2 |* Network key creating a home security domain at L2 |
| | ensuring authentication and freshness of exchanged data|
| |* Secure multicast does not ensure origin authentication |
| |* No need for secure routing at L3 |
+----------+---------------------------------------------------------+
|SecProf_3 |* Network key creating an industry security domain at L2 |
| | ensuring authentication and freshness of exchanged data|
| |* Secure routing needed (integrity & availability) at L3 |
| | within 6LoWPAN/CoAP |
| |* Secure multicast requires origin authentication |
+----------+---------------------------------------------------------+
|SecProf_4 |* Network key creating an industry security domain at L2 |
| | ensuring authentication and freshness of exchanged data|
| |* Inter-domain authentication/secure handoff |
| |* Secure routing needed at L3 |
| |* Secure multicast requires origin authentication |
| |* 6LBR (HTTP-CoAP proxy) requires verification of |
| | forwarded messages and messages leaving or entering the|
| | 6LoWPAN/CoAP network. |
+----------+---------------------------------------------------------+
Figure 9: Network security needs in different security profiles
5.5. Application Security
In the context of 6LoWPAN/CoAP networks, application security refers
firstly to the configuration of DTLS used to protect the exchanged
information. It further refers to the measures required in potential
translation points (e.g., a (HTTP-CoAP) proxy) where information can
be collected and the privacy sphere of users in a given security
domain is endangered. Application security for the different
security profiles is as follows.
Garcia-Morchon, et al. Expires April 12, 2017 [Page 23]
Internet-Draft Security Considerations for the IoT October 2016
+---------------------------------------------------------+
|Description |
+----------+---------------------------------------------------------+
|SecProf_1 | - |
+----------+---------------------------------------------------------+
|SecProf_2 |* DTLS is used for end-to-end application security |
| | between management device and things and between things|
| |* DTLS ciphersuites configurable to provide |
| | confidentiality and/or authentication and/or freshness |
| |* Key transport and policies for generation of session |
| | keys are required |
+----------+---------------------------------------------------------+
|SecProf_3 |* Requirements as in SecProf_2 and |
| |* DTLS is used for end-to-end application security |
| | between management device and things and between things|
| |* Communication between KDC and each thing secured by |
| | pairwise keys |
| |* Group keys for communication in a group distributed |
| | by KDC |
| |* Privacy protection should be provided in translation |
| | points |
+----------+---------------------------------------------------------+
|SecProf_4 |* Requirements as in SecProf_3 and |
| |* TLS or DTLS can be used to send commands from the |
| | backend to the 6LBR or things in a 6LoWPAN/CoAP network|
| |* End-to-end secure connectivity from backend required |
| |* Secure broadcast in a network from backend required |
+----------+---------------------------------------------------------+
Figure 10: Application security methods in different security
profiles
The first two security profiles do not include any security at the
application layer. The reason is that, in the first case, security
is not provided and, in the second case, it seems reasonable to
provide basic security at L2. In the third security profile
(SecProf_2), DTLS becomes the way of protecting messages at
application layer between things and with the KDC running on a 6LBR.
A key option refers to the capability of easily configuring DTLS to
provide a subset of security services (e.g., some applications do not
require confidentiality) to reduce the impact of security in the
system operation of resource-constrained things. In addition to
basic key management mechanisms running within the KDC, communication
protocols for key transport or key update are required. These
protocols could be based on DTLS. The next security suite
(SecProf_3) requires pairwise keys for communication between things
within the security domain. Furthermore, it can involve the usage of
group keys for group communication. If secure multicast is
Garcia-Morchon, et al. Expires April 12, 2017 [Page 24]
Internet-Draft Security Considerations for the IoT October 2016
implemented, it should provide origin authentication. Finally,
privacy protection should be taken into account to limit access to
valuable information -- such as identifiers, type of collected data,
traffic patterns -- in potential translation points (proxies) or in
the backend. The last security suite (SecProf_4) further extends the
previous set of requirements considering security mechanisms to deal
with translations between TLS and DTLS or for the provision of secure
multicast within a 6LoWPAN/CoAP network from the backend.
6. Challenges and Security Considerations for a Secure Internet of
Things
<<Oliver and Mohit add stuff in this section>>
In this section, we take a closer look at the various security
challenges in the operational and technical features of the IoT and
then discuss how existing Internet security protocols cope with these
technical and conceptual challenges through the lifecycle of a thing.
Figure 2 summarizes which requirements need to be met in the
lifecycle phases as well as some of the considered protocols. This
discussion should neither be understood as a comprehensive evaluation
of all protocols, nor can it cover all possible aspects of IoT
security. Yet, it aims at showing concrete limitations of existing
Internet security protocols in some areas rather than giving an
abstract discussion about general properties of the protocols. In
this regard, the discussion handles issues that are most important
from the authors' perspectives.
6.1. Constraints and Heterogeneous Communication
Coupling resource constrained networks and the powerful Internet is a
challenge because the resulting heterogeneity of both networks
complicates protocol design and system operation. In the following
we briefly discuss the resource constraints of IoT devices and the
consequences for the use of Internet Protocols in the IoT domain.
6.1.1. Tight Resource Constraints
The IoT is a resource-constrained network that relies on lossy and
low-bandwidth channels for communication between small nodes,
regarding CPU, memory, and energy budget. These characteristics
directly impact the threats to and the design of security protocols
for the IoT domain. First, the use of small packets, e.g., IEEE
802.15.4 supports 127-byte sized packets at the physical layer, may
result in fragmentation of larger packets of security protocols.
This may open new attack vectors for state exhaustion DoS attacks,
which is especially tragic, e.g., if the fragmentation is caused by
large key exchange messages of security protocols. Moreover, packet
Garcia-Morchon, et al. Expires April 12, 2017 [Page 25]
Internet-Draft Security Considerations for the IoT October 2016
fragmentation commonly downgrades the overall system performance due
to fragment losses and the need for retransmissions. For instance,
fate-sharing packet flight as implemented by DTLS might aggravate the
resulting performance loss.
The size and number of messages should be minimized to reduce memory
requirements and optimize bandwidth usage. In this context, layered
approaches involving a number of protocols might lead to worse
performance in resource-constrained devices since they combine the
headers of the different protocols. In some settings, protocol
negotiation can increase the number of exchanged messages. To
improve performance during basic procedures such as, e.g.,
bootstrapping, it might be a good strategy to perform those
procedures at a lower layer.
Small CPUs and scarce memory limit the usage of resource-expensive
cryptoprimitives such as public-key cryptography as used in most
Internet security standards. This is especially true, if the basic
cryptoblocks need to be frequently used or the underlying application
demands a low delay.
Independently from the development in the IoT domain, all discussed
security protocols show efforts to reduce the cryptographic cost of
the required public-key-based key exchanges and signatures with
ECC[RFC5246][RFC5903][RFC7401][ID-HIP]. Moreover, all protocols have
been revised in the last years to enable crypto agility, making
cryptographic primitives interchangeable. However, these
improvements are only a first step in reducing the computation and
communication overhead of Internet protocols. The question remains
if other approaches can be applied to leverage key agreement in these
heavily resource-constrained environments.
A further fundamental need refers to the limited energy budget
available to IoT nodes. Careful protocol (re)design and usage is
required to reduce not only the energy consumption during normal
operation, but also under DoS attacks. Since the energy consumption
of IoT devices differs from other device classes, judgments on the
energy consumption of a particular protocol cannot be made without
tailor-made IoT implementations.
6.1.2. Denial-of-Service Resistance
The tight memory and processing constraints of things naturally
alleviate resource exhaustion attacks. Especially in unattended T2T
communication, such attacks are difficult to notice before the
service becomes unavailable (e.g., because of battery or memory
exhaustion). As a DoS countermeasure, DTLS, IKEv2, HIP, and Diet HIP
implement return routability checks based on a cookie mechanism to
Garcia-Morchon, et al. Expires April 12, 2017 [Page 26]
Internet-Draft Security Considerations for the IoT October 2016
delay the establishment of state at the responding host until the
address of the initiating host is verified. The effectiveness of
these defenses strongly depends on the routing topology of the
network. Return routability checks are particularly effective if
hosts cannot receive packets addressed to other hosts and if IP
addresses present meaningful information as is the case in today's
Internet. However, they are less effective in broadcast media or
when attackers can influence the routing and addressing of hosts
(e.g., if hosts contribute to the routing infrastructure in ad-hoc
networks and meshes).
In addition, HIP implements a puzzle mechanism that can force the
initiator of a connection (and potential attacker) to solve
cryptographic puzzles with variable difficulties. Puzzle-based
defense mechanisms are less dependent on the network topology but
perform poorly if CPU resources in the network are heterogeneous
(e.g., if a powerful Internet host attacks a thing). Increasing the
puzzle difficulty under attack conditions can easily lead to
situations, where a powerful attacker can still solve the puzzle
while weak IoT clients cannot and are excluded from communicating
with the victim. Still, puzzle-based approaches are a viable option
for sheltering IoT devices against unintended overload caused by
misconfigured or malfunctioning things.
6.1.3. Protocol Translation and End-to-End Security
Even though 6LoWPAN and CoAP progress towards reducing the gap
between Internet protocols and the IoT, they do not target protocol
specifications that are identical to their Internet counterparts due
to performance reasons. Hence, more or less subtle differences
between IoT protocols and Internet protocols will remain. While
these differences can easily be bridged with protocol translators at
gateways, they become major obstacles if end-to-end security measures
between IoT devices and Internet hosts are used.
Cryptographic payload processing applies message authentication codes
or encryption to packets. These protection methods render the
protected parts of the packets immutable as rewriting is either not
possible because a) the relevant information is encrypted and
inaccessible to the gateway or b) rewriting integrity-protected parts
of the packet would invalidate the end-to-end integrity protection.
There are essentially four solutions for this problem:
1. Sharing credentials with gateways enables gateways to transform
(e.g., de-compress, convert, etc.) packets and re-apply the
security measures after transformation. This method abandons
Garcia-Morchon, et al. Expires April 12, 2017 [Page 27]
Internet-Draft Security Considerations for the IoT October 2016
end-to-end security and is only applicable to simple scenarios
with a rudimentary security model.
2. Reusing the Internet wire format in the IoT makes conversion
between IoT and Internet protocols unnecessary. However, it
leads to poor performance because IoT specific optimizations
(e.g., stateful or stateless compression) are not possible.
3. Selectively protecting vital and immutable packet parts with a
MAC or with encryption requires a careful balance between
performance and security. Otherwise, this approach will either
result in poor performance (protect as much as possible) or poor
security (compress and transform as much as possible).
4. Message authentication codes that sustain transformation can be
realized by considering the order of transformation and
protection (e.g., by creating a signature before compression so
that the gateway can decompress the packet without recalculating
the signature). This enables IoT specific optimizations but is
more complex and may require application-specific transformations
before security is applied. Moreover, it cannot be used with
encrypted data because the lack of cleartext prevents gateways
from transforming packets.
5. Object security based mechanisms can bridge the protocol worlds,
but still requires that the two worlds use the same object
security formats. Currently the IoT based object security format
based on COSE is different from the Internet based JOSE or CMS.
Legacy devices on the Internet side will need to update to the
newer IoT protocols to enable real end-to-end security.
To the best of our knowledge, none of the mentioned security
protocols provides a fully customizable solution in this problem
space.
6.2. Bootstrapping of a Security Domain
Creating a security domain from a set of previously unassociated IoT
devices is a key operation in the lifecycle of a thing and in the IoT
network. This aspect is further elaborated and discussed in the
T2TRG draft on bootstrapping [ID-bootstrap].
6.3. Operation
After the bootstrapping phase, the system enters the operational
phase. During the operational phase, things can relate to the state
information created during the bootstrapping phase in order to
exchange information securely and in an authenticated fashion. In
Garcia-Morchon, et al. Expires April 12, 2017 [Page 28]
Internet-Draft Security Considerations for the IoT October 2016
this section, we discuss aspects of communication patterns and
network dynamics during this phase.
6.3.1. End-to-End Security
Providing end-to-end security is of great importance to address and
secure individual T2T or H2T communication within one IoT domain.
Moreover, end-to-end security associations are an important measure
to bridge the gap between the IoT and the Internet. IKEv2 and HIP,
TLS and DTLS provide end-to-end security services including peer
entity authentication, end-to-end encryption and integrity protection
above the network layer and the transport layer respectively. Once
bootstrapped, these functions can be carried out without online
connections to third parties, making the protocols applicable for
decentralized use in the IoT. However, protocol translation by
intermediary nodes may invalidate end-to-end protection measures (see
Section 5.1). Also these protocols require end-to-end connectivity
between the devices and do not support store-and-forward scenarios.
Object security is an option for such scenarios and the work on
OSCOAP [ID-OSCOAP] is a potential solution in this space, in
particular, in the context of forwarding proxies.
6.3.2. Group Membership and Security
In addition to end-to-end security, group key negotiation is an
important security service for the T2Ts and Ts2T communication
patterns in the IoT as efficient local broadcast and multicast relies
on symmetric group keys.
All discussed protocols only cover unicast communication and
therefore do not focus on group-key establishment. However, the
Diffie-Hellman keys that are used in IKEv2 and HIP could be used for
group Diffie-Hellman key-negotiations. Conceptually, solutions that
provide secure group communication at the network layer (IPsec/IKEv2,
HIP/Diet HIP) may have an advantage regarding the cryptographic
overhead compared to application-focused security solutions (TLS/
DTLS or OSCOAP). This is due to the fact that application-focused
solutions require cryptographic operations per group application,
whereas network layer approaches may allow to share secure group
associations between multiple applications (e.g., for neighbor
discovery and routing or service discovery). Hence, implementing
shared features lower in the communication stack can avoid redundant
security measures.
A number of group key solutions have been developed in the context of
the IETF working group MSEC in the context of the MIKEY architecture
[WG-MSEC][RFC4738]. These are specifically tailored for multicast
and group broadcast applications in the Internet and should also be
Garcia-Morchon, et al. Expires April 12, 2017 [Page 29]
Internet-Draft Security Considerations for the IoT October 2016
considered as candidate solutions for group key agreement in the IoT.
The MIKEY architecture describes a coordinator entity that
disseminates symmetric keys over pair-wise end-to-end secured
channels. However, such a centralized approach may not be applicable
in a distributed environment, where the choice of one or several
coordinators and the management of the group key is not trivial.
6.3.3. Mobility and IP Network Dynamics
It is expected that many things (e.g., wearable sensors, and user
devices) will be mobile in the sense that they are attached to
different networks during the lifetime of a security association.
Built-in mobility signaling can greatly reduce the overhead of the
cryptographic protocols because unnecessary and costly re-
establishments of the session (possibly including handshake and key
agreement) can be avoided. IKEv2 supports host mobility with the
MOBIKE [RFC4555][RFC4621] extension. MOBIKE refrains from applying
heavyweight cryptographic extensions for mobility. However, MOBIKE
mandates the use of IPsec tunnel mode which requires to transmit an
additional IP header in each packet. This additional overhead could
be alleviated by using header compression methods or the Bound End-
to-End Tunnel (BEET) mode [ID-Nikander], a hybrid of tunnel and
transport mode with smaller packet headers.
HIP offers a simple yet effective mobility management by allowing
hosts to signal changes to their associations [RFC5206]. However,
slight adjustments might be necessary to reduce the cryptographic
costs, for example, by making the public-key signatures in the
mobility messages optional. Diet HIP does not define mobility yet
but it is sufficiently similar to HIP to employ the same mechanisms.
TLS and DTLS do not have standards for mobility support, however,
work on DTLS mobility exists in the form of an Internet draft
[ID-Williams]. The specific need for IP-layer mobility mainly
depends on the scenario in which nodes operate. In many cases,
mobility support by means of a mobile gateway may suffice to enable
mobile IoT networks, such as body sensor networks. However, if
individual things change their point of network attachment while
communicating, mobility support may gain importance.
6.4. Software update
IoT devices have a reputation for being insecure at the time of
manufacture. Yet they are often expected to stay functional in live
deployments for years and even decades. Additionally, these devices
typically operate unattended with direct Internet connectivity.
Therefore, a remote software update mechanism to fix vulnerabilities,
to update configuration settings, and for adding new functionality is
needed.
Garcia-Morchon, et al. Expires April 12, 2017 [Page 30]
Internet-Draft Security Considerations for the IoT October 2016
Schneier [SchneierSecurity] in his essay expresses concerns about the
status of software and firmware update mechanisms for Internet of
Things (IoT) devices. He highlights several challenges that hinder
mechanisms for secure software update of IoT devices. First, there
is a lack of incentives for manufactures, vendors and others on the
supply chain to issue updates for their devices. Second, parts of
the software running on the IoT devices is simply a binary blob
without any source code available. Since the complete source code
isn't available, no patches can be written for that piece of code.
Third, even when updates are available, users generally have to
manually download and install those updates. However, users are
never alerted about security updates and many times don't have the
necessary expertise to manually administer the required updates.
The FTC staff report on Internet of Things - Privacy & Security in a
Connected World [FTCreport] and the Article 29 Working Party Opinion
8/2014 on the on Recent Developments on the Internet of Things
[Article29] also document the challenges for secure remote software
update of IoT devices. They note that even providing such a software
update capability may add new vulnerabilities for constrained
devices. For example, a buffer overflow vulnerability in the
implementation of a software update protocol (TR69) [TR69] and an
expired certificate in a hub device [wink] demonstrate how the
software update process itself can introduce vulnerabilities.
While powerful IoT devices that run general purpose operating systems
can make use of sophisticated software update mechanisms known from
the desktop world, a more considerate effort is needed for resource-
constrained devices that don't have any operating system and are
typically not equipped with a memory management unit or similar
tools. The IAB also organized a workshop to understand the
challenges for secure software update of IoT devices. A summary of
the workshop and the proposed next steps have been documented
[iotsu].
6.5. Verifying device behavior
Users often have a false sense of privacy when using new Internet of
Things (IoT) appliances such as Internet-connected smart televisions,
speakers and cameras. Recent revelations have shown that this user
belief is often unfounded. Many IoT device vendors have been caught
collecting sensitive private data through these connected appliances
with or without appropriate user warnings [cctv].
An IoT device user/owner would like to monitor and know if the device
is calling home (i.e. verify its operational behavior). The calling
home feature may be necessary in some scenarios, such as during the
initial configuration of the device. However, the user should be
Garcia-Morchon, et al. Expires April 12, 2017 [Page 31]
Internet-Draft Security Considerations for the IoT October 2016
kept aware of the data that the device is sending back to the vendor.
For example, the user should be ensured that his/her TV is not
sending data when he/she inserts a new USB stick.
Providing such information to the users in an understandable fashion
is challenging. This is because the IoT device are not only
resource-constrained in terms of their computational capability, but
also in terms of the user interface available. Also, the network
infrastructure where these devices are deployed will vary
significantly from one user environment to another. Therefore, where
and how this monitoring feature is implemented still remains an open
question.
6.6. End-of-life
Like all commercial devices, most IoT devices will be end-of-lifed by
vendors. This may be planned or unplanned (for example when the
vendor or manufacturer goes bankrupt). A user should still be able
to use and perhaps even update the device. This requires for some
form of authorization handover.
Although this may seem far fetched given the commercial interests and
market dynamics, we have examples from the mobile world where the
devices have been functional and up-to-date long after the original
vendor stopped supporting the device. CyanogenMod for Android
devices and OpenWrt for home routers are two such instances where
users have been able to use and update their devices even after they
were end-of-lifed. Admittedly these are not easy for an average
users to install and configure on their devices. With the deployment
of millions of IoT devices, simpler mechanisms are needed to allow
users to add new root-of-trusts and install software and firmware
from other sources once the device has been end-of-lifed.
6.7. Penetration testing
Given that the IoT devices often have inadvertent vulnerabilities,
both users and developers would want to perform penetration testing
on their IoT devices. Nonetheless, since the devices are resource-
constrained they often barf of crash even when minimal tests are
performed. It remains to be seen how the software testing and
quality assurance mechanisms used from the desktop and mobile world
will be applied to IoT devices.
6.8. Quantum-resistance
Many IoT systems that are being deployed today will remain
operational for many years. With the advancements made in the field
of quantum computers, it is possible that large-scale quantum
Garcia-Morchon, et al. Expires April 12, 2017 [Page 32]
Internet-Draft Security Considerations for the IoT October 2016
computers are available in the future for performing cryptanalysis on
existing cryptographic algorithms and cipher suites. If this
happened, it would have two consequences. First, functionalities
enabled by means of RSA/ECC - namely key exchange, public-key
encryption and signature - would not be secure anymore due to Shor's
algorithm. Second, the security level of symmetric algorithms will
decrease, e.g., the security of a block cipher with a key size of b
bits will only offer b/2 bits of security due to Grover's algorithm.
This would require to update to quantum-resistant alternatives, in
particular, for those functionalities involving key exchange, public-
key encryption and signatures. While such future planning is hard,
it may be a necessity in certain critical IoT deployments which are
expected to last decades or more. Although increasing the key-size
of the different algorithms is definitely an option, it would also
incur additional computation overhead and network traffic. This
would be undesirable in most scenarios. There have been recent
advancements in quantum-resistant cryptography.
We refer to [ETSI_GR_QSC_001] for an extensive overview of existing
quantum-resistant cryptography. RFC7696 provides guidelines for
cryptographic algorithm agility.
7. Next Steps towards a Flexible and Secure Internet of Things
This Internet Draft included an overview of both operational and
security requirements of things in the Internet of Things, discussed
a general threat model and security issues, and introduced a number
of potential security suites fitting different types of IoT
deployments.
We conclude this document by giving our assessment of the current
status of IoT security with respect to addressing the IP security
challenges. <<TBD>>
8. Security Considerations
This document reflects upon the requirements and challenges of the
security architectural framework for Internet of Things.
9. IANA Considerations
This document contains no request to IANA.
Garcia-Morchon, et al. Expires April 12, 2017 [Page 33]
Internet-Draft Security Considerations for the IoT October 2016
10. Acknowledgements
We gratefully acknowledge feedback and fruitful discussion with
Tobias Heer and Robert Moskowitz. Acknowledge the additional authors
of the previous version of this document Sye Loong Keoh, Rene Hummen
and Rene Struik.
11. Informative References
[Article29]
"Opinion 8/2014 on the on Recent Developments on the
Internet of Things", Web http://ec.europa.eu/justice/data-
protection/article-29/documentation/opinion-
recommendation/files/2014/wp223_en.pdf, n.d..
[AUTO-ID] "AUTO-ID LABS", Web http://www.autoidlabs.org/, September
2010.
[BACNET] "BACnet", Web http://www.bacnet.org/, February 2011.
[cctv] "Backdoor In MVPower DVR Firmware Sends CCTV Stills To an
Email Address In China", Web
https://hardware.slashdot.org/story/16/02/17/0422259/
backdoor-in-mvpower-dvr-firmware-sends-cctv-stills-to-an-
email-address-in-china, n.d..
[DALI] "DALI", Web http://www.dalibydesign.us/dali.html, February
2011.
[ETSI_GR_QSC_001]
"Quantum-Safe Cryptography (QSC);Quantum-safe algorithmic
framework", European Telecommunications Standards
Institute (ETSI) , June 2016.
[FTCreport]
"FTC Report on Internet of Things Urges Companies to Adopt
Best Practices to Address Consumer Privacy and Security
Risks", Web https://www.ftc.gov/news-events/press-
releases/2015/01/ftc-report-internet-things-urges-
companies-adopt-best-practices, n.d..
[ID-bootstrap]
Sarikaya, B. and M. Sethi, "Secure IoT Bootstrapping : A
Survey", draft-sarikaya-t2trg-sbootstrapping-01 , July
2016.
Garcia-Morchon, et al. Expires April 12, 2017 [Page 34]
Internet-Draft Security Considerations for the IoT October 2016
[ID-Daniel]
Park, S., Kim, K., Haddad, W., Chakrabarti, S., and J.
Laganier, "IPv6 over Low Power WPAN Security Analysis",
Internet Draft draft-daniel-6lowpan-security-analysis-05,
March 2011.
[ID-Hartke]
Hartke, K. and O. Bergmann, "Datagram Transport Layer
Security in Constrained Environments", draft-hartke-core-
codtls-02 (work in progress), July 2012.
[ID-HIP] Moskowitz, R., "HIP Diet EXchange (DEX)", draft-moskowitz-
hip-rg-dex-06 (work in progress), May 2012.
[ID-Nikander]
Nikander, P. and J. Melen, "A Bound End-to-End
Tunnel(BEET) mode for ESP", draft-nikander-esp-beet-
mode-09 , August 2008.
[ID-OFlynn]
O'Flynn, C., Sarikaya, B., Ohba, Y., Cao, Z., and R.
Cragie, "Security Bootstrapping of Resource-Constrained
Devices", draft-oflynn-core-bootstrapping-03 (work in
progress), November 2010.
[ID-OSCOAP]
Selander, G., Mattsson, J., Palombini, F., and L. Seitz,
"Object Security of CoAP (OSCOAP)", draft-selander-ace-
object-security-05 , July 2016.
[ID-proHTTPCoAP]
Castellani, A., Loreto, S., Rahman, A., Fossati, T., and
E. Dijk, "Best practices for HTTP-CoAP mapping
implementation", draft-castellani-core-http-mapping-
07(work in progress), February 2013.
[ID-Tsao] Tsao, T., Alexander, R., Dohler, M., Daza, V., and A.
Lozano, "A Security Framework for Routing over Low Power
and Lossy Networks", draft-ietf-roll-security-
framework-07 , January 2012.
[ID-Williams]
Williams, M. and J. Barrett, "Mobile DTLS", draft-barrett-
mobile-dtls-00 , March 2009.
Garcia-Morchon, et al. Expires April 12, 2017 [Page 35]
Internet-Draft Security Considerations for the IoT October 2016
[iotsu] "Patching the Internet of Things: IoT Software Update
Workshop 2016", Web
https://www.ietf.org/blog/2016/07/patching-the-internet-
of-things-iot-software-update-workshop-2016/, n.d..
[JOURNAL-Perrig]
Perrig, A., Szewczyk, R., Wen, V., Culler, D., and J.
Tygar, "SPINS: Security protocols for Sensor Networks",
Journal Wireless Networks, September 2002.
[NIST] Dworkin, M., "NIST Specification Publication 800-38B",
2005.
[PROC-Chan]
Chan, H., Perrig, A., and D. Song, "Random Key
Predistribution Schemes for Sensor Networks",
Proceedings IEEE Symposium on Security and Privacy, 2003.
[PROC-Gupta]
Gupta, V., Wurm, M., Zhu, Y., Millard, M., Fung, S., Gura,
N., Eberle, H., and S. Shantz, "Sizzle: A Standards-based
End-to-End Security Architecture for the Embedded
Internet", Proceedings Pervasive Computing and
Communications (PerCom), 2005.
[PROC-Smetters-02]
Balfanz, D., Smetters, D., Steward, P., and H. Chi Wong,,
"Talking To Strangers: Authentication in Ad-Hoc Wireless
Networks", Paper NDSS, 2002.
[PROC-Smetters-04]
Balfanz, D., Durfee, G., Grinter, R., Smetters, D., and P.
Steward, "Network-in-a-Box: How to Set Up a Secure
Wireless Network in Under a Minute", Paper USENIX, 2004.
[PROC-Stajano-99]
Stajano, F. and R. Anderson, "Resurrecting Duckling -
Security Issues for Adhoc Wireless Networks",
7th International Workshop Proceedings, November 1999.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818,
DOI 10.17487/RFC2818, May 2000,
<http://www.rfc-editor.org/info/rfc2818>.
Garcia-Morchon, et al. Expires April 12, 2017 [Page 36]
Internet-Draft Security Considerations for the IoT October 2016
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
DOI 10.17487/RFC3261, June 2002,
<http://www.rfc-editor.org/info/rfc3261>.
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
Levkowetz, Ed., "Extensible Authentication Protocol
(EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004,
<http://www.rfc-editor.org/info/rfc3748>.
[RFC3756] Nikander, P., Ed., Kempf, J., and E. Nordmark, "IPv6
Neighbor Discovery (ND) Trust Models and Threats",
RFC 3756, DOI 10.17487/RFC3756, May 2004,
<http://www.rfc-editor.org/info/rfc3756>.
[RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the Domain
Name System (DNS)", RFC 3833, DOI 10.17487/RFC3833, August
2004, <http://www.rfc-editor.org/info/rfc3833>.
[RFC4016] Parthasarathy, M., "Protocol for Carrying Authentication
and Network Access (PANA) Threat Analysis and Security
Requirements", RFC 4016, DOI 10.17487/RFC4016, March 2005,
<http://www.rfc-editor.org/info/rfc4016>.
[RFC4251] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
Protocol Architecture", RFC 4251, DOI 10.17487/RFC4251,
January 2006, <http://www.rfc-editor.org/info/rfc4251>.
[RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol
(MOBIKE)", RFC 4555, DOI 10.17487/RFC4555, June 2006,
<http://www.rfc-editor.org/info/rfc4555>.
[RFC4621] Kivinen, T. and H. Tschofenig, "Design of the IKEv2
Mobility and Multihoming (MOBIKE) Protocol", RFC 4621,
DOI 10.17487/RFC4621, August 2006,
<http://www.rfc-editor.org/info/rfc4621>.
[RFC4738] Ignjatic, D., Dondeti, L., Audet, F., and P. Lin, "MIKEY-
RSA-R: An Additional Mode of Key Distribution in
Multimedia Internet KEYing (MIKEY)", RFC 4738,
DOI 10.17487/RFC4738, November 2006,
<http://www.rfc-editor.org/info/rfc4738>.
Garcia-Morchon, et al. Expires April 12, 2017 [Page 37]
Internet-Draft Security Considerations for the IoT October 2016
[RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6
over Low-Power Wireless Personal Area Networks (6LoWPANs):
Overview, Assumptions, Problem Statement, and Goals",
RFC 4919, DOI 10.17487/RFC4919, August 2007,
<http://www.rfc-editor.org/info/rfc4919>.
[RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler,
"Transmission of IPv6 Packets over IEEE 802.15.4
Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007,
<http://www.rfc-editor.org/info/rfc4944>.
[RFC5191] Forsberg, D., Ohba, Y., Ed., Patil, B., Tschofenig, H.,
and A. Yegin, "Protocol for Carrying Authentication for
Network Access (PANA)", RFC 5191, DOI 10.17487/RFC5191,
May 2008, <http://www.rfc-editor.org/info/rfc5191>.
[RFC5206] Nikander, P., Henderson, T., Ed., Vogt, C., and J. Arkko,
"End-Host Mobility and Multihoming with the Host Identity
Protocol", RFC 5206, DOI 10.17487/RFC5206, April 2008,
<http://www.rfc-editor.org/info/rfc5206>.
[RFC5238] Phelan, T., "Datagram Transport Layer Security (DTLS) over
the Datagram Congestion Control Protocol (DCCP)",
RFC 5238, DOI 10.17487/RFC5238, May 2008,
<http://www.rfc-editor.org/info/rfc5238>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008,
<http://www.rfc-editor.org/info/rfc5246>.
[RFC5713] Moustafa, H., Tschofenig, H., and S. De Cnodder, "Security
Threats and Security Requirements for the Access Node
Control Protocol (ANCP)", RFC 5713, DOI 10.17487/RFC5713,
January 2010, <http://www.rfc-editor.org/info/rfc5713>.
[RFC5903] Fu, D. and J. Solinas, "Elliptic Curve Groups modulo a
Prime (ECP Groups) for IKE and IKEv2", RFC 5903,
DOI 10.17487/RFC5903, June 2010,
<http://www.rfc-editor.org/info/rfc5903>.
[RFC6345] Duffy, P., Chakrabarti, S., Cragie, R., Ohba, Y., Ed., and
A. Yegin, "Protocol for Carrying Authentication for
Network Access (PANA) Relay Element", RFC 6345,
DOI 10.17487/RFC6345, August 2011,
<http://www.rfc-editor.org/info/rfc6345>.
Garcia-Morchon, et al. Expires April 12, 2017 [Page 38]
Internet-Draft Security Considerations for the IoT October 2016
[RFC6568] Kim, E., Kaspar, D., and JP. Vasseur, "Design and
Application Spaces for IPv6 over Low-Power Wireless
Personal Area Networks (6LoWPANs)", RFC 6568,
DOI 10.17487/RFC6568, April 2012,
<http://www.rfc-editor.org/info/rfc6568>.
[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
Application Protocol (CoAP)", RFC 7252,
DOI 10.17487/RFC7252, June 2014,
<http://www.rfc-editor.org/info/rfc7252>.
[RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T.
Kivinen, "Internet Key Exchange Protocol Version 2
(IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October
2014, <http://www.rfc-editor.org/info/rfc7296>.
[RFC7390] Rahman, A., Ed. and E. Dijk, Ed., "Group Communication for
the Constrained Application Protocol (CoAP)", RFC 7390,
DOI 10.17487/RFC7390, October 2014,
<http://www.rfc-editor.org/info/rfc7390>.
[RFC7401] Moskowitz, R., Ed., Heer, T., Jokela, P., and T.
Henderson, "Host Identity Protocol Version 2 (HIPv2)",
RFC 7401, DOI 10.17487/RFC7401, April 2015,
<http://www.rfc-editor.org/info/rfc7401>.
[RFC7696] Housley, R., "Guidelines for Cryptographic Algorithm
Agility and Selecting Mandatory-to-Implement Algorithms",
BCP 201, RFC 7696, DOI 10.17487/RFC7696, November 2015,
<http://www.rfc-editor.org/info/rfc7696>.
[SchneierSecurity]
"The Internet of Things Is Wildly Insecure--And Often
Unpatchable", Web
https://www.schneier.com/essays/archives/2014/01/
the_internet_of_thin.html, n.d..
[THESIS-Langheinrich]
Langheinrich, M., "Personal Privacy in Ubiquitous
Computing", PhD Thesis ETH Zurich, 2005.
[Thread] "Thread Alliance", Web http://threadgroup.org/, n.d..
[TinyDTLS]
"TinyDTLS", Web http://tinydtls.sourceforge.net/, February
2012.
Garcia-Morchon, et al. Expires April 12, 2017 [Page 39]
Internet-Draft Security Considerations for the IoT October 2016
[TR69] "Too Many Cooks - Exploiting the Internet-of-TR-
069-Things", Web https://media.ccc.de/v/31c3_-_6166_-_en_-
_saal_6_-_201412282145_-_too_many_cooks_-
_exploiting_the_internet-of-tr-069-things_-
_lior_oppenheim_-_shahar_tal, n.d..
[WG-6LoWPAN]
"IETF 6LoWPAN Working Group",
Web http://tools.ietf.org/wg/6lowpan/, February 2011.
[WG-CoRE] "IETF Constrained RESTful Environment (CoRE) Working
Group", Web https://datatracker.ietf.org/wg/core/charter/,
February 2011.
[WG-MSEC] "MSEC Working Group",
Web http://datatracker.ietf.org/wg/msec/, n.d..
[wink] "Wink's Outage Shows Us How Frustrating Smart Homes Could
Be",
Web http://www.wired.com/2015/04/smart-home-headaches/,
n.d..
[ZB] "ZigBee Alliance", Web http://www.zigbee.org/, February
2011.
Authors' Addresses
Oscar Garcia-Morchon
Philips Research
Canal Park 2
Cambridge, 02141
United States
Email: oscar.garcia@philips.com
Sandeep S. Kumar
Philips Research
High Tech Campus
Eindhoven, 5656 AE
The Netherlands
Email: sandeep.kumar@philips.com
Garcia-Morchon, et al. Expires April 12, 2017 [Page 40]
Internet-Draft Security Considerations for the IoT October 2016
Mohit Sethi
Ericsson
Hirsalantie 11
Jorvas
Finland
Email: mohit@piuha.net
Garcia-Morchon, et al. Expires April 12, 2017 [Page 41]