< draft-irtf-t2trg-iot-seccons-15.txt   draft-irtf-t2trg-iot-seccons-16.txt >
Network Working Group O. Garcia-Morchon Network Working Group O. Garcia-Morchon
Internet-Draft Philips IP&S Internet-Draft Philips IP&S
Intended status: Informational S. Kumar Intended status: Informational S. Kumar
Expires: November 20, 2018 Philips Research Expires: June 16, 2019 Philips Research
M. Sethi M. Sethi
Ericsson Ericsson
May 19, 2018 December 13, 2018
State-of-the-Art and Challenges for the Internet of Things Security State-of-the-Art and Challenges for the Internet of Things Security
draft-irtf-t2trg-iot-seccons-15 draft-irtf-t2trg-iot-seccons-16
Abstract Abstract
The Internet of Things (IoT) concept refers to the usage of standard The Internet of Things (IoT) concept refers to the usage of standard
Internet protocols to allow for human-to-thing and thing-to-thing Internet protocols to allow for human-to-thing and thing-to-thing
communication. The security needs for IoT systems are well- communication. The security needs for IoT systems are well-
recognized and many standardization steps to provide security have recognized and many standardization steps to provide security have
been taken, for example, the specification of Constrained Application been taken, for example, the specification of Constrained Application
Protocol (CoAP) secured with Datagram Transport Layer Security Protocol (CoAP) secured with Datagram Transport Layer Security
(DTLS). However, security challenges still exist, not only because (DTLS). However, security challenges still exist, not only because
skipping to change at page 2, line 7 skipping to change at page 2, line 7
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 20, 2018. This Internet-Draft will expire on June 16, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 6, line 46 skipping to change at page 6, line 46
system since compromised IoT systems can be misused at scale. For system since compromised IoT systems can be misused at scale. For
example, they may be used to perform a Distributed Denial of Service example, they may be used to perform a Distributed Denial of Service
(DDoS) attack that limits the availability of other networks and (DDoS) attack that limits the availability of other networks and
services. The fact that many IoT systems rely on standard IP services. The fact that many IoT systems rely on standard IP
protocols allows for easier system integration, but this also makes protocols allows for easier system integration, but this also makes
attacks on standard IP protocols widely applicable in other attacks on standard IP protocols widely applicable in other
environments. This results in new requirements regarding the environments. This results in new requirements regarding the
implementation of security. implementation of security.
The term security subsumes a wide range of primitives, protocols, and The term security subsumes a wide range of primitives, protocols, and
procedures. Firstly, it includes the basic provision of security procedures. For instance, the term security includes services such
services that include confidentiality, authentication, integrity, as confidentiality, authentication, integrity, authorization, source
authorization, source authentication, and availability along with authentication, and availability. The term security often also
some augmented services, such as duplicate detection and detection of includes augmented services such as duplicate detection and detection
stale packets (timeliness). These security services can be of stale packets (timeliness). These security services can be
implemented by means of a combination of cryptographic mechanisms, implemented through a combination of cryptographic mechanisms such as
such as block ciphers, hash functions, or signature algorithms, and block ciphers, hash functions, and signature algorithms; as well as
non-cryptographic mechanisms, which implement authorization and other non-cryptographic mechanisms that implement authorization and other
security policy enforcement aspects. For ensuring security in IoT security policy enforcement aspects. For ensuring security in IoT
networks, we should not only focus on the required security services, networks, one should not only focus on the required security
but also pay special attention to how these services are realized in services, but also pay special attention to how the services are
the overall system and how the security functionalities are executed realized in the overall system.
in practice.
3. Security Threats and Managing Risk 3. Security Threats and Managing Risk
Security threats in related IP protocols have been analyzed in Security threats in related IP protocols have been analyzed in
multiple documents including Hypertext Transfer Protocol (HTTP) over multiple documents including Hypertext Transfer Protocol (HTTP) over
Transport Layer Security (TLS) (HTTPS) [RFC2818], Constrained Transport Layer Security (TLS) (HTTPS) [RFC2818], Constrained
Application Protocol (COAP) [RFC7252], IPv6 over Low-Power Wireless Application Protocol (COAP) [RFC7252], IPv6 over Low-Power Wireless
Personal Area Networks (6LoWPAN) [RFC4919], Access Node Control Personal Area Networks (6LoWPAN) [RFC4919], Access Node Control
Protocol (ANCP) [RFC5713], Domain Name System (DNS) [RFC3833], IPv6 Protocol (ANCP) [RFC5713], Domain Name System (DNS) [RFC3833], IPv6
Neighbor Discovery (ND) [RFC3756], and Protocol for Carrying Neighbor Discovery (ND) [RFC3756], and Protocol for Carrying
skipping to change at page 11, line 38 skipping to change at page 11, line 34
industry. More information can be found in NIST documents such as industry. More information can be found in NIST documents such as
[NISTSP800-34r1], [NISTSP800-30r1], and [NISTSP800-122]. [NISTSP800-34r1], [NISTSP800-30r1], and [NISTSP800-122].
4. State-of-the-Art 4. State-of-the-Art
This section is organized as follows. Section 4.1 summarizes state- This section is organized as follows. Section 4.1 summarizes state-
of-the-art on IP-based IoT systems, within IETF and in other of-the-art on IP-based IoT systems, within IETF and in other
standardization bodies. Section 4.2 summarizes state-of-the-art on standardization bodies. Section 4.2 summarizes state-of-the-art on
IP-based security protocols and their usage. Section 4.3 discusses IP-based security protocols and their usage. Section 4.3 discusses
guidelines and regulations for securing IoT as proposed by other guidelines and regulations for securing IoT as proposed by other
bodies. bodies. Note that the references included in this section are a
representative of the state-of-the-art at the point of writing and
they are by no means exhaustive. The references are also at varying
levels of maturity, and thus, it is advisable to review their
specific status.
4.1. IP-based IoT Protocols and Standards 4.1. IP-based IoT Protocols and Standards
Nowadays, there exists a multitude of control protocols for IoT. For Nowadays, there exists a multitude of control protocols for IoT. For
BAC systems, the ZigBee standard [ZB], BACNet [BACNET], and DALI BAC systems, the ZigBee standard [ZB], BACNet [BACNET], and DALI
[DALI] play key roles. Recent trends, however, focus on an all-IP [DALI] play key roles. Recent trends, however, focus on an all-IP
approach for system control. approach for system control.
In this setting, a number of IETF working groups are designing new In this setting, a number of IETF working groups are designing new
protocols for resource-constrained networks of smart things. The protocols for resource-constrained networks of smart things. The
skipping to change at page 12, line 23 skipping to change at page 12, line 23
because they sleep during their operational phase to save energy. In because they sleep during their operational phase to save energy. In
such scenarios, direct discovery of resources hosted on the such scenarios, direct discovery of resources hosted on the
constrained server might not be possible. To overcome this barrier, constrained server might not be possible. To overcome this barrier,
the CoRE working group is specifying the concept of a Resource the CoRE working group is specifying the concept of a Resource
Directory (RD) [ID-rd]. The Resource Directory hosts descriptions of Directory (RD) [ID-rd]. The Resource Directory hosts descriptions of
resources which are located on other nodes. These resource resources which are located on other nodes. These resource
descriptions are specified as CoRE link format [RFC6690]. descriptions are specified as CoRE link format [RFC6690].
While CoAP defines a standard communication protocol, a format for While CoAP defines a standard communication protocol, a format for
representing sensor measurements and parameters over CoAP is representing sensor measurements and parameters over CoAP is
required. The Sensor Measurement Lists (SenML) [ID-senml] is a required. The Sensor Measurement Lists (SenML) [RFC8428] is a
specification that defines media types for simple sensor measurements specification that defines media types for simple sensor measurements
and parameters. It has a minimalistic design so that constrained and parameters. It has a minimalistic design so that constrained
devices with limited computational capabilities can easily encode devices with limited computational capabilities can easily encode
their measurements and, at the same time, servers can efficiently their measurements and, at the same time, servers can efficiently
collect large number of measurements. collect large number of measurements.
In many IoT deployments, the resource-constrained smart objects are In many IoT deployments, the resource-constrained smart objects are
connected to the Internet via a gateway that is directly reachable. connected to the Internet via a gateway that is directly reachable.
For example, an IEEE 802.11 Access Point (AP) typically connects the For example, an IEEE 802.11 Access Point (AP) typically connects the
client devices to the Internet over just one wireless hop. However, client devices to the Internet over just one wireless hop. However,
skipping to change at page 15, line 4 skipping to change at page 14, line 52
There are three main security objectives for IoT networks: 1. There are three main security objectives for IoT networks: 1.
protecting the IoT network from attackers. 2. protecting IoT protecting the IoT network from attackers. 2. protecting IoT
applications and thus, the things and users. 3. protecting the rest applications and thus, the things and users. 3. protecting the rest
of the Internet and other things from attacks that use compromised of the Internet and other things from attacks that use compromised
things as an attack platform. things as an attack platform.
In the context of the IP-based IoT deployments, consideration of In the context of the IP-based IoT deployments, consideration of
existing Internet security protocols is important. There are a wide existing Internet security protocols is important. There are a wide
range of specialized as well as general-purpose security solutions range of specialized as well as general-purpose security solutions
for the Internet domain such as IKEv2/IPsec [RFC7296], TLS [RFC5246], for the Internet domain such as IKEv2/IPsec [RFC7296], Transport
DTLS [RFC6347], HIP [RFC7401], PANA [RFC5191], and EAP [RFC3748]. Layer Security (TLS) [RFC8446], Datagram Transport Layer Security
(DTLS) [RFC6347], Host Identity Protocol (HIP) [RFC7401], PANA
[RFC5191], Kerberos ([RFC4120]), Simple Authentication and Security
Layer (SASL) [RFC4422], and Extensible Authentication Protocol (EAP)
[RFC3748].
TLS provides security for TCP and requires a reliable transport. TLS provides security for TCP and requires a reliable transport.
DTLS secures and uses datagram-oriented protocols such as UDP. Both DTLS secures and uses datagram-oriented protocols such as UDP. Both
protocols are intentionally kept similar and share the same ideology protocols are intentionally kept similar and share the same ideology
and cipher suites. The CoAP base specification [RFC7252] provides a and cipher suites. The CoAP base specification [RFC7252] provides a
description of how DTLS can be used for securing CoAP. It proposes description of how DTLS can be used for securing CoAP. It proposes
three different modes for using DTLS: the PreSharedKey mode, where three different modes for using DTLS: the PreSharedKey mode, where
nodes have pre-provisioned keys for initiating a DTLS session with nodes have pre-provisioned keys for initiating a DTLS session with
another node, RawPublicKey mode, where nodes have asymmetric-key another node, RawPublicKey mode, where nodes have asymmetric-key
pairs but no certificates to verify the ownership, and Certificate pairs but no certificates to verify the ownership, and Certificate
skipping to change at page 15, line 32 skipping to change at page 15, line 35
framework for resource-constrained nodes. The Authentication and framework for resource-constrained nodes. The Authentication and
Authorization for Constrained Environments (ACE) [WG-ACE] working Authorization for Constrained Environments (ACE) [WG-ACE] working
group is defining a solution to allow only authorized access to group is defining a solution to allow only authorized access to
resources that are hosted on a smart object server and are identified resources that are hosted on a smart object server and are identified
by a URI. The current proposal [ID-aceoauth] is based on the OAuth by a URI. The current proposal [ID-aceoauth] is based on the OAuth
2.0 framework [RFC6749] and it comes with profiles intended for 2.0 framework [RFC6749] and it comes with profiles intended for
different communication scenarios, e.g. DTLS Profile for different communication scenarios, e.g. DTLS Profile for
Authentication and Authorization for Constrained Environments Authentication and Authorization for Constrained Environments
[ID-acedtls]. [ID-acedtls].
The CoAP base specification [RFC7252] provides a description of how
DTLS can be used for securing CoAP. It proposes three different
modes for using DTLS: the PreSharedKey mode, where nodes have pre-
provisioned keys for initiating a DTLS session with another node,
RawPublicKey mode, where nodes have asymmetric-key pairs but no
certificates to verify the ownership, and Certificate mode, where
public keys are certified by a certification authority. An IoT
implementation profile [RFC7925] is defined for TLS version 1.2 and
DTLS version 1.2 that offers communication security for resource-
constrained nodes.
OSCORE [ID-OSCORE] is a proposal that protects CoAP messages by OSCORE [ID-OSCORE] is a proposal that protects CoAP messages by
wrapping them in the CBOR Object Signing and Encryption (COSE) wrapping them in the CBOR Object Signing and Encryption (COSE)
[RFC8152] format. Thus, OSCORE falls in the category of object [RFC8152] format. Thus, OSCORE falls in the category of object
security and it can be applied wherever CoAP can be used. The security and it can be applied wherever CoAP can be used. The
advantage of OSCORE over DTLS is that it provides some more advantage of OSCORE over DTLS is that it provides some more
flexibility when dealing with end-to-end security. Section 5.1.3 flexibility when dealing with end-to-end security. Section 5.1.3
discusses this further. discusses this further.
The Automated Certificate Management Environment (ACME) [WG-ACME] The Automated Certificate Management Environment (ACME) [WG-ACME]
working group is specifying conventions for automated X.509 working group is specifying conventions for automated X.509
skipping to change at page 17, line 21 skipping to change at page 17, line 13
the factory with software that is already outdated and the factory with software that is already outdated and
vulnerable. The report also states that many devices with vulnerable. The report also states that many devices with
vulnerabilities will not be fixed either because the vulnerabilities will not be fixed either because the
manufacturer does not provide updates or because the user does manufacturer does not provide updates or because the user does
not apply them. The recommendations include that IoT devices not apply them. The recommendations include that IoT devices
should function without cloud and Internet connectivity, and should function without cloud and Internet connectivity, and
that all IoT devices should have methods for automatic secure that all IoT devices should have methods for automatic secure
software updates. software updates.
3. United Kingdom Department for Digital, Culture, Media and Sport 3. United Kingdom Department for Digital, Culture, Media and Sport
(DCMS) [DCMS]: UK DCMS has releasead a report that includes a (DCMS) [DCMS]: UK DCMS has released a report that includes a
list of 13 steps for improving IoT security. These steps, for list of 13 steps for improving IoT security. These steps, for
example, highlight the need for implementing a vulnerability example, highlight the need for implementing a vulnerability
disclosure policy and keeping software updated. The report is disclosure policy and keeping software updated. The report is
aimed at device manufacturers, IoT service providers, mobile aimed at device manufacturers, IoT service providers, mobile
application developers and retailers. application developers and retailers.
4. Cloud Security Alliance (CSA) New Security Guidance for Early 4. Cloud Security Alliance (CSA) New Security Guidance for Early
Adopters of the IoT [CSA]: CSA recommendations for early Adopters of the IoT [CSA]: CSA recommendations for early
adopters of IoT encourages enterprises to implement security at adopters of IoT encourages enterprises to implement security at
different layers of the protocol stack. It also recommends different layers of the protocol stack. It also recommends
skipping to change at page 18, line 6 skipping to change at page 17, line 44
6. National Institute of Standards and Technology (NIST) 6. National Institute of Standards and Technology (NIST)
[NIST-Guide]: The NIST special publication urges enterprise and [NIST-Guide]: The NIST special publication urges enterprise and
US federal agencies to address security throughout the systems US federal agencies to address security throughout the systems
engineering process. The publication builds upon the engineering process. The publication builds upon the
International Organization for Standardization International Organization for Standardization
(ISO)/International Electrotechnical Commission (IEC) 15288 (ISO)/International Electrotechnical Commission (IEC) 15288
standard and augments each process in the system lifecycle with standard and augments each process in the system lifecycle with
security enhancements. security enhancements.
7. National Institute of Standards and Technology (NIST) 7. National Institute of Standards and Technology (NIST)
[nist_lightweight_project]: NIST is running a project on [nist-lightweight-project]: NIST is running a project on
lightweight cryptography with the purpose of: (i) identifying lightweight cryptography with the purpose of: (i) identifying
application areas for which standard cryptographic algorithms application areas for which standard cryptographic algorithms
are too heavy, classifying them according to some application are too heavy, classifying them according to some application
profiles to be determined; (ii) determining limitations in those profiles to be determined; (ii) determining limitations in those
existing cryptographic standards; and (iii) standardizing existing cryptographic standards; and (iii) standardizing
lightweight algorithms that can be used in specific application lightweight algorithms that can be used in specific application
profiles. profiles.
8. Open Web Application Security Project (OWASP) [OWASP]: OWASP 8. Open Web Application Security Project (OWASP) [OWASP]: OWASP
provides security guidance for IoT manufactures, developers and provides security guidance for IoT manufactures, developers and
skipping to change at page 18, line 43 skipping to change at page 18, line 33
discovered. discovered.
11. Best Current Practices (BCP) for IoT devices [ID-Moore]: This 11. Best Current Practices (BCP) for IoT devices [ID-Moore]: This
document provides a list of minimum requirements that vendors of document provides a list of minimum requirements that vendors of
Internet of Things (IoT) devices should to take into account Internet of Things (IoT) devices should to take into account
while developing applications, services and firmware updates in while developing applications, services and firmware updates in
order to reduce the frequency and severity of security incidents order to reduce the frequency and severity of security incidents
that arise from compromised IoT devices. that arise from compromised IoT devices.
12. European Union Agency for Network and Information Security 12. European Union Agency for Network and Information Security
(ENISA) [ENISA_ICS]: ENISA published a document on communication (ENISA) [ENISA-ICS]: ENISA published a document on communication
network dependencies for Industrial Control Systems network dependencies for Industrial Control Systems
(ICS)/Supervisory Control And Data Acquisition (SCADA) systems (ICS)/Supervisory Control And Data Acquisition (SCADA) systems
in which security vulnerabilities, guidelines and general in which security vulnerabilities, guidelines and general
recommendations are summarized. recommendations are summarized.
13. Internet Society Online Trust Alliance [ISOC-OTA]: The Internet
Society's IoT Trust Framework identifies the core requirements
manufacturers, service providers, distributors, purchasers and
policymakers need to understand, assess and embrace for
effective security and privacy as part of the Internet of
Things.
Other guideline and recommendation documents may exist or may later Other guideline and recommendation documents may exist or may later
be published. This list should be considered non-exhaustive. be published. This list should be considered non-exhaustive.
Despite the acknowledgment that security in the Internet is needed Despite the acknowledgment that security in the Internet is needed
and the existence of multiple guidelines, the fact is that many IoT and the existence of multiple guidelines, the fact is that many IoT
devices and systems have very limited security. There are multiple devices and systems have very limited security. There are multiple
reasons for this. For instance, some manufactures focus on reasons for this. For instance, some manufactures focus on
delivering a product without paying enough attention to security. delivering a product without paying enough attention to security.
This may be because of lack of expertise or limited budget. However, This may be because of lack of expertise or limited budget. However,
the deployment of such insecure devices poses a severe threat on the the deployment of such insecure devices poses a severe threat on the
privacy and safety of users. The vast amount of devices and their privacy and safety of users. The vast amount of devices and their
inherent mobile nature also implies that an initially secure system inherent mobile nature also implies that an initially secure system
can become insecure if a compromised device gains access to the can become insecure if a compromised device gains access to the
system at some point in time. Even if all other devices in a given system at some point in time. Even if all other devices in a given
environment are secure, this does not prevent external attacks caused environment are secure, this does not prevent external attacks caused
by insecure devices. Recently the Federal Communications Commission by insecure devices. Recently the Federal Communications Commission
(FCC) [FCC] has stated the need for additional regulation of IoT (FCC) [FCC] has stated the need for additional regulation of IoT
systems. It is possible that we may see other such regional systems. It is possible that we may see other such regional
skipping to change at page 20, line 26 skipping to change at page 20, line 23
procedures at a lower layer. procedures at a lower layer.
Small CPUs and scarce memory limit the usage of resource-expensive Small CPUs and scarce memory limit the usage of resource-expensive
cryptographic primitives such as public-key cryptography as used in cryptographic primitives such as public-key cryptography as used in
most Internet security standards. This is especially true if the most Internet security standards. This is especially true if the
basic cryptographic blocks need to be frequently used or the basic cryptographic blocks need to be frequently used or the
underlying application demands low delay. underlying application demands low delay.
There are ongoing efforts to reduce the resource consumption of There are ongoing efforts to reduce the resource consumption of
security protocols by using more efficient underlying cryptographic security protocols by using more efficient underlying cryptographic
primitives such as Elliptic Curve Cryptography [RFC5246]. The primitives such as Elliptic Curve Cryptography [RFC8446]. The
specification of elliptic curve X25519 [ecc25519], stream ciphers specification of elliptic curve X25519 [ecc25519], stream ciphers
such as ChaCha [ChaCha], Diet HIP [ID-HIP-DEX], and ECC goups for such as ChaCha [ChaCha], Diet HIP [ID-HIP-DEX], and ECC goups for
IKEv2 [RFC5903] are all examples of efforts to make security IKEv2 [RFC5903] are all examples of efforts to make security
protocols more resource efficient. Additionally, most modern protocols more resource efficient. Additionally, most modern
security protocols have been revised in the last few years to enable security protocols have been revised in the last few years to enable
cryptographic agility, making cryptographic primitives cryptographic agility, making cryptographic primitives
interchangeable. However, these improvements are only a first step interchangeable. However, these improvements are only a first step
in reducing the computation and communication overhead of Internet in reducing the computation and communication overhead of Internet
protocols. The question remains if other approaches can be applied protocols. The question remains if other approaches can be applied
to leverage key agreement in these heavily resource-constrained to leverage key agreement in these heavily resource-constrained
skipping to change at page 23, line 12 skipping to change at page 23, line 9
6. Mechanisms based on object security can bridge the protocol 6. Mechanisms based on object security can bridge the protocol
worlds, but still require that the two worlds use the same object worlds, but still require that the two worlds use the same object
security formats. Currently the object security format based on security formats. Currently the object security format based on
CBOR Object Signing and Encryption (COSE) [RFC8152] is different CBOR Object Signing and Encryption (COSE) [RFC8152] is different
from JSON Object Signing and Encryption (JOSE) [RFC7520] or from JSON Object Signing and Encryption (JOSE) [RFC7520] or
Cryptographic Message Syntax (CMS) [RFC5652]. Legacy devices Cryptographic Message Syntax (CMS) [RFC5652]. Legacy devices
relying on traditional Internet protocols will need to update to relying on traditional Internet protocols will need to update to
the newer protocols for constrained environments to enable real the newer protocols for constrained environments to enable real
end-to-end security. Furthermore, middleboxes do not have any end-to-end security. Furthermore, middleboxes do not have any
access to the data and this approach does not prevent an attacker access to the data and this approach does not prevent an attacker
who is capable of modifying relevant fields in the payload. who is capable of modifying relevant message header fields that
are not protected.
To the best of our knowledge, none of the mentioned security To the best of our knowledge, none of the mentioned security
approaches that focus on the confidentiality and integrity of the approaches that focus on the confidentiality and integrity of the
communication exchange between two IP end-points provide the perfect communication exchange between two IP end-points provide the perfect
solution in this problem space. solution in this problem space.
5.1.4. New network architectures and paradigm 5.1.4. New network architectures and paradigm
There is a multitude of new link layer protocols that aim to address There is a multitude of new link layer protocols that aim to address
the resource-constrained nature of IoT devices. For example, the the resource-constrained nature of IoT devices. For example, the
IEEE 802.11 ah [IEEE802ah] has been specified for extended range and IEEE 802.11 ah [IEEE802ah] has been specified for extended range and
lower energy consumption to support Internet of Things (IoT) devices. lower energy consumption to support Internet of Things (IoT) devices.
Similarly, Low-Power Wide-Area Network (LPWAN) protocols such as LoRa Similarly, Low-Power Wide-Area Network (LPWAN) protocols such as LoRa
[lora], Sigfox [sigfox], NarrowBand IoT (NB-IoT) [nbiot] are all [lora], Sigfox [sigfox], NarrowBand IoT (NB-IoT) [nbiot] are all
designed for resource-constrained devices that require long range and designed for resource-constrained devices that require long range and
low bit rates. [ID-lpwan] provides an informational overview of the low bit rates. [RFC8376] provides an informational overview of the
set of LPWAN technologies being considered by the IETF. It also set of LPWAN technologies being considered by the IETF. It also
identifies the potential gaps that exist between the needs of those identifies the potential gaps that exist between the needs of those
technologies and the goal of running IP in such networks. While technologies and the goal of running IP in such networks. While
these protocols allow IoT devices to conserve energy and operate these protocols allow IoT devices to conserve energy and operate
efficiently, they also add additional security challenges. For efficiently, they also add additional security challenges. For
example, the relatively small MTU can make security handshakes with example, the relatively small MTU can make security handshakes with
large X509 certificates a significant overhead. At the same time, large X509 certificates a significant overhead. At the same time,
new communication paradigms also allow IoT devices to communicate new communication paradigms also allow IoT devices to communicate
directly amongst themselves with or without support from the network. directly amongst themselves with or without support from the network.
This communication paradigm is also referred to as Device-to-Device This communication paradigm is also referred to as Device-to-Device
skipping to change at page 27, line 38 skipping to change at page 27, line 38
Software updates in IoT systems are also needed to update old and Software updates in IoT systems are also needed to update old and
insecure cryptographic primitives. However, many IoT systems, some insecure cryptographic primitives. However, many IoT systems, some
of which are already deployed, are not designed with provisions for of which are already deployed, are not designed with provisions for
cryptographic agility. For example, many devices come with a cryptographic agility. For example, many devices come with a
wireless radio that has an AES128 hardware co-processor. These wireless radio that has an AES128 hardware co-processor. These
devices solely rely on the co-processor for encrypting and devices solely rely on the co-processor for encrypting and
authenticating messages. A software update adding support for new authenticating messages. A software update adding support for new
cryptographic algorithms implemented solely in software might not fit cryptographic algorithms implemented solely in software might not fit
on these devices due to limited memory, or might drastically hinder on these devices due to limited memory, or might drastically hinder
its operational performance. This can lead to the use of old and its operational performance. This can lead to the use of old and
insecure devices. Therefore, it is important to account for the fact insecure software. Therefore, it is important to account for the
that cryptographic algorithms would need to be updated and consider fact that cryptographic algorithms would need to be updated and
the following when planning for cryptographic agility: consider the following when planning for cryptographic agility:
1. Would it be safe to use the existing cryptographic algorithms 1. Would it be secure to use the existing cryptographic algorithms
available on the device for updating with new cryptographic available on the device for updating with new cryptographic
algorithms that are more secure? algorithms that are more secure?
2. Will the new software-based implementation fit on the device 2. Will the new software-based implementation fit on the device
given the limited resources? given the limited resources?
3. Would the normal operation of existing IoT applications on the 3. Would the normal operation of existing IoT applications on the
device be severely hindered by the update? device be severely hindered by the update?
Finally, we would like to highlight the previous and ongoing work in Finally, we would like to highlight the previous and ongoing work in
the area of secure software and firmware updates at the IETF. the area of secure software and firmware updates at the IETF.
[RFC4108] describes how Cryptographic Message Syntax (CMS) [RFC5652] [RFC4108] describes how Cryptographic Message Syntax (CMS) [RFC5652]
can be used to protect firmware packages. The IAB has also organized can be used to protect firmware packages. The IAB has also organized
a workshop to understand the challenges for secure software update of a workshop to understand the challenges for secure software update of
IoT devices. A summary of the recommendations to the standards IoT devices. A summary of the recommendations to the standards
community derived from the discussions during that workshop have been community derived from the discussions during that workshop have been
documented [RFC8240]. A new working group called Software Updates documented [RFC8240]. A working group called Software Updates for
for Internet of Things (suit) [WG-SUIT] is currently being chartered Internet of Things (suit) [WG-SUIT] is currently working on a new
at the IETF. The working group aims to standardize a new version version [RFC4108] to reflect the best current practices for firmware
[RFC4108] that reflects the best current practices for firmware update based on experience from IoT deployments. It is specifically
update based on experience with IoT deployments. It will working on describing an IoT firmware update architecture and
specifically work on describing an IoT firmware update architecture specifying a manifest format that contains meta-data about the
and specifying a manifest format that contains meta-data about the
firmware update package. Finally, the Trusted Execution Environment firmware update package. Finally, the Trusted Execution Environment
Provisioning working group [WG-TEEP] aims at developing a protocol Provisioning working group [WG-TEEP] aims at developing a protocol
for lifecycle management of trusted applications running on the for lifecycle management of trusted applications running on the
secure area of a processor (Trusted Execution Enviornment (TEE)). secure area of a processor (Trusted Execution Enviornment (TEE)).
5.5. End-of-Life 5.5. End-of-Life
Like all commercial devices, IoT devices have a given useful Like all commercial devices, IoT devices have a given useful
lifetime. The term end-of-life (EOL) is used by vendors or network lifetime. The term end-of-life (EOL) is used by vendors or network
operators to indicate the point of time in which they limit or end operators to indicate the point of time in which they limit or end
skipping to change at page 30, line 26 skipping to change at page 30, line 26
security of the whole system is limited by its weakest point. security of the whole system is limited by its weakest point.
5.8. Quantum-resistance 5.8. Quantum-resistance
Many IoT systems that are being deployed today will remain Many IoT systems that are being deployed today will remain
operational for many years. With the advancements made in the field operational for many years. With the advancements made in the field
of quantum computers, it is possible that large-scale quantum of quantum computers, it is possible that large-scale quantum
computers are available in the future for performing cryptanalysis on computers are available in the future for performing cryptanalysis on
existing cryptographic algorithms and cipher suites. If this existing cryptographic algorithms and cipher suites. If this
happens, it will have two consequences. First, functionalities happens, it will have two consequences. First, functionalities
enabled by means of RSA/ECC - namely key exchange, public-key enabled by means of primitives such as RSA or ECC - namely key
encryption and signature - would not be secure anymore due to Shor's exchange, public-key encryption and signature - would not be secure
algorithm. Second, the security level of symmetric algorithms will anymore due to Shor's algorithm. Second, the security level of
decrease, for example, the security of a block cipher with a key size symmetric algorithms will decrease, for example, the security of a
of b bits will only offer b/2 bits of security due to Grover's block cipher with a key size of b bits will only offer b/2 bits of
algorithm. security due to Grover's algorithm.
The above scenario becomes more urgent when we consider the so called The above scenario becomes more urgent when we consider the so called
"harvest and decrypt" attack in which an attacker can start to "harvest and decrypt" attack in which an attacker can start to
harvest (store) encrypted data today, before a quantum-computer is harvest (store) encrypted data today, before a quantum-computer is
available, and decrypt it years later, once a quantum computer is available, and decrypt it years later, once a quantum computer is
available. Such "harvest and decrypt" attacks are not new and were available. Such "harvest and decrypt" attacks are not new and were
used in the Venona project [venona-project]. Many IoT devices that used in the Venona project [venona-project]. Many IoT devices that
are being deployed today will remain operational for a decade or even are being deployed today will remain operational for a decade or even
longer. During this time, digital signatures used to sign software longer. During this time, digital signatures used to sign software
updates might become obsolete making the secure update of IoT devices updates might become obsolete making the secure update of IoT devices
skipping to change at page 31, line 7 skipping to change at page 31, line 7
exchange, public-key encryption and signatures. [ID-c2pq] describes exchange, public-key encryption and signatures. [ID-c2pq] describes
when quantum computers may become widely available and what steps are when quantum computers may become widely available and what steps are
necessary for transition to cryptographic algorithms that provide necessary for transition to cryptographic algorithms that provide
security even in presence of quantum computers. While future security even in presence of quantum computers. While future
planning is hard, it may be a necessity in certain critical IoT planning is hard, it may be a necessity in certain critical IoT
deployments which are expected to last decades or more. Although deployments which are expected to last decades or more. Although
increasing the key-size of the different algorithms is definitely an increasing the key-size of the different algorithms is definitely an
option, it would also incur additional computational overhead and option, it would also incur additional computational overhead and
network traffic. This would be undesirable in most scenarios. There network traffic. This would be undesirable in most scenarios. There
have been recent advancements in quantum-resistant cryptography. We have been recent advancements in quantum-resistant cryptography. We
refer to [ETSI_GR_QSC_001] for an extensive overview of existing refer to [ETSI-GR-QSC-001] for an extensive overview of existing
quantum-resistant cryptography and [RFC7696] provides guidelines for quantum-resistant cryptography and [RFC7696] provides guidelines for
cryptographic algorithm agility. cryptographic algorithm agility.
5.9. Privacy protection 5.9. Privacy protection
People will eventually be surrounded by hundreds of connected IoT People will eventually be surrounded by hundreds of connected IoT
devices. Even if the communication links are encrypted and devices. Even if the communication links are encrypted and
protected, information about people might still be collected or protected, information about people might still be collected or
processed for different purposes. The fact that IoT devices in the processed for different purposes. The fact that IoT devices in the
vicinity of people might enable more pervasive monitoring can vicinity of people might enable more pervasive monitoring can
skipping to change at page 36, line 29 skipping to change at page 36, line 29
october-21-attack/, n.d.. october-21-attack/, n.d..
[ecc25519] [ecc25519]
Bernstein, D., "Curve25519: new Diffie-Hellman speed Bernstein, D., "Curve25519: new Diffie-Hellman speed
records", records",
Web https://cr.yp.to/ecdh/curve25519-20060209.pdf, n.d.. Web https://cr.yp.to/ecdh/curve25519-20060209.pdf, n.d..
[ECSO] "European Cyber Security Organization", Web [ECSO] "European Cyber Security Organization", Web
https://www.ecs-org.eu/, n.d.. https://www.ecs-org.eu/, n.d..
[ENISA_ICS] [ENISA-ICS]
"Communication network dependencies for ICS/SCADA "Communication network dependencies for ICS/SCADA
Systems", European Union Agency For Network And Systems", European Union Agency For Network And
Information Security , February 2017. Information Security , February 2017.
[ETSI_GR_QSC_001] [ETSI-GR-QSC-001]
"Quantum-Safe Cryptography (QSC);Quantum-safe algorithmic "Quantum-Safe Cryptography (QSC);Quantum-safe algorithmic
framework", European Telecommunications Standards framework", European Telecommunications Standards
Institute (ETSI) , June 2016. Institute (ETSI) , June 2016.
[Fairhair] [Fairhair]
"Fairhair Alliance", Web https://www.fairhair- "Fairhair Alliance", Web https://www.fairhair-
alliance.org/, n.d.. alliance.org/, n.d..
[FCC] "Federal Communications Comssion Response 12-05-2016", [FCC] "Federal Communications Comssion Response 12-05-2016",
FCC , February 2016. FCC , February 2016.
skipping to change at page 37, line 16 skipping to change at page 37, line 16
Web https://www.eugdpr.org/, n.d.. Web https://www.eugdpr.org/, n.d..
[GSMAsecurity] [GSMAsecurity]
"GSMA IoT Security Guidelines", Web "GSMA IoT Security Guidelines", Web
http://www.gsma.com/connectedliving/future-iot- http://www.gsma.com/connectedliving/future-iot-
networks/iot-security-guidelines/, n.d.. networks/iot-security-guidelines/, n.d..
[ID-6lonfc] [ID-6lonfc]
Choi, Y., Hong, Y., Youn, J., Kim, D., and J. Choi, Choi, Y., Hong, Y., Youn, J., Kim, D., and J. Choi,
"Transmission of IPv6 Packets over Near Field "Transmission of IPv6 Packets over Near Field
Communication", draft-ietf-6lo-nfc-09 (work in progress), Communication", draft-ietf-6lo-nfc-12 (work in progress),
January 2018. November 2018.
[ID-6tisch] [ID-6tisch]
Thubert, P., "An Architecture for IPv6 over the TSCH mode Thubert, P., "An Architecture for IPv6 over the TSCH mode
of IEEE 802.15.4", draft-ietf-6tisch-architecture-14 (work of IEEE 802.15.4", draft-ietf-6tisch-architecture-18 (work
in progress), April 2018. in progress), December 2018.
[ID-acedtls] [ID-acedtls]
Gerdes, S., Bergmann, O., Bormann, C., Selander, G., and Gerdes, S., Bergmann, O., Bormann, C., Selander, G., and
L. Seitz, "Datagram Transport Layer Security (DTLS) L. Seitz, "Datagram Transport Layer Security (DTLS)
Profile for Authentication and Authorization for Profile for Authentication and Authorization for
Constrained Environments (ACE)", draft-ietf-ace-dtls- Constrained Environments (ACE)", draft-ietf-ace-dtls-
authorize-03 (work in progress), March 2018. authorize-05 (work in progress), October 2018.
[ID-aceoauth] [ID-aceoauth]
Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and
H. Tschofenig, "Authentication and Authorization for H. Tschofenig, "Authentication and Authorization for
Constrained Environments (ACE) using the OAuth 2.0 Constrained Environments (ACE) using the OAuth 2.0
Framework (ACE-OAuth)", draft-ietf-ace-oauth-authz-11 Framework (ACE-OAuth)", draft-ietf-ace-oauth-authz-17
(work in progress), March 2018. (work in progress), November 2018.
[ID-bootstrap] [ID-bootstrap]
Sarikaya, B., Sethi, M., and A. Sangi, "Secure IoT Sarikaya, B., Sethi, M., and D. Garcia-Carillo, "Secure
Bootstrapping: A Survey", draft-sarikaya-t2trg- IoT Bootstrapping: A Survey", draft-sarikaya-t2trg-
sbootstrapping-03 (work in progress), February 2017. sbootstrapping-05 (work in progress), September 2018.
[ID-c2pq] Hoffman, P., "The Transition from Classical to Post- [ID-c2pq] Hoffman, P., "The Transition from Classical to Post-
Quantum Cryptography", draft-hoffman-c2pq-03 (work in Quantum Cryptography", draft-hoffman-c2pq-04 (work in
progress), February 2018. progress), August 2018.
[ID-Daniel] [ID-Daniel]
Park, S., Kim, K., Haddad, W., Chakrabarti, S., and J. Park, S., Kim, K., Haddad, W., Chakrabarti, S., and J.
Laganier, "IPv6 over Low Power WPAN Security Analysis", Laganier, "IPv6 over Low Power WPAN Security Analysis",
draft-daniel-6lowpan-security-analysis-05 (work in draft-daniel-6lowpan-security-analysis-05 (work in
progress), March 2011. progress), March 2011.
[ID-dietesp] [ID-dietesp]
Migault, D., Guggemos, T., and C. Bormann, "Diet-ESP: a Migault, D., Guggemos, T., and C. Bormann, "Diet-ESP: a
flexible and compressed format for IPsec/ESP", draft-mglt- flexible and compressed format for IPsec/ESP", draft-mglt-
6lo-diet-esp-02 (work in progress), July 2016. 6lo-diet-esp-02 (work in progress), July 2016.
[ID-HIP-DEX] [ID-HIP-DEX]
Moskowitz, R., "HIP Diet EXchange (DEX)", draft-moskowitz- Moskowitz, R., "HIP Diet EXchange (DEX)", draft-moskowitz-
hip-rg-dex-06 (work in progress), May 2012. hip-rg-dex-06 (work in progress), May 2012.
[ID-lpwan]
Farrell, S., "LPWAN Overview", draft-ietf-lpwan-
overview-10 (work in progress), February 2018.
[ID-Moore] [ID-Moore]
Moore, K., Barnes, R., and H. Tschofenig, "Best Current Moore, K., Barnes, R., and H. Tschofenig, "Best Current
Practices for Securing Internet of Things (IoT) Devices", Practices for Securing Internet of Things (IoT) Devices",
draft-moore-iot-security-bcp-01 (work in progress), July draft-moore-iot-security-bcp-01 (work in progress), July
2017. 2017.
[ID-MUD] Lear, E., Droms, R., and D. Romascanu, "Manufacturer Usage [ID-MUD] Lear, E., Droms, R., and D. Romascanu, "Manufacturer Usage
Description Specification", draft-ietf-opsawg-mud-21 (work Description Specification", draft-ietf-opsawg-mud-25 (work
in progress), May 2018. in progress), June 2018.
[ID-multicast] [ID-multicast]
Tiloca, M., Selander, G., Palombini, F., and J. Park, Tiloca, M., Selander, G., Palombini, F., and J. Park,
"Secure group communication for CoAP", draft-ietf-core- "Group OSCORE - Secure Group Communication for CoAP",
oscore-groupcomm-01 (work in progress), March 2018. draft-ietf-core-oscore-groupcomm-03 (work in progress),
October 2018.
[ID-OSCORE] [ID-OSCORE]
Selander, G., Mattsson, J., Palombini, F., and L. Seitz, Selander, G., Mattsson, J., Palombini, F., and L. Seitz,
"Object Security for Constrained RESTful Environments "Object Security for Constrained RESTful Environments
(OSCORE)", draft-ietf-core-object-security-12 (work in (OSCORE)", draft-ietf-core-object-security-15 (work in
progress), March 2018. progress), August 2018.
[ID-rd] Shelby, Z., Koster, M., Bormann, C., Stok, P., and C. [ID-rd] Shelby, Z., Koster, M., Bormann, C., Stok, P., and C.
Amsuess, "CoRE Resource Directory", draft-ietf-core- Amsuess, "CoRE Resource Directory", draft-ietf-core-
resource-directory-13 (work in progress), March 2018. resource-directory-17 (work in progress), October 2018.
[ID-senml]
Jennings, C., Shelby, Z., Arkko, J., Keranen, A., and C.
Bormann, "Sensor Measurement Lists (SenML)", draft-ietf-
core-senml-16 (work in progress), May 2018.
[ID-Williams] [ID-Williams]
Williams, M. and J. Barrett, "Mobile DTLS", draft-barrett- Williams, M. and J. Barrett, "Mobile DTLS", draft-barrett-
mobile-dtls-00 (work in progress), March 2009. mobile-dtls-00 (work in progress), March 2009.
[IEEE802ah] [IEEE802ah]
"Status of Project IEEE 802.11ah, IEEE P802.11- Task Group "Status of Project IEEE 802.11ah, IEEE P802.11- Task Group
AH-Meeting Update.", AH-Meeting Update.",
Web http://www.ieee802.org/11/Reports/tgah_update.htm, Web http://www.ieee802.org/11/Reports/tgah_update.htm,
n.d.. n.d..
skipping to change at page 39, line 21 skipping to change at page 39, line 12
[IIoT] "Industrial Internet Consortium", [IIoT] "Industrial Internet Consortium",
Web http://www.iiconsortium.org/, n.d.. Web http://www.iiconsortium.org/, n.d..
[IoTSecFoundation] [IoTSecFoundation]
"Establishing Principles for Internet of Things Security", "Establishing Principles for Internet of Things Security",
Web https://iotsecurityfoundation.org/establishing- Web https://iotsecurityfoundation.org/establishing-
principles-for-internet-of-things-security/, n.d.. principles-for-internet-of-things-security/, n.d..
[IPSO] "IPSO Alliance", Web http://www.ipso-alliance.org, n.d.. [IPSO] "IPSO Alliance", Web http://www.ipso-alliance.org, n.d..
[ISOC-OTA]
"Internet Society's Online Trust Alliance (OTA)",
Web https://www.internetsociety.org/ota/, n.d..
[lora] "LoRa - Wide Area Networks for IoT", Web https://www.lora- [lora] "LoRa - Wide Area Networks for IoT", Web https://www.lora-
alliance.org/, n.d.. alliance.org/, n.d..
[LWM2M] "OMA LWM2M", Web [LWM2M] "OMA LWM2M", Web
http://openmobilealliance.org/iot/lightweight-m2m-lwm2m, http://openmobilealliance.org/iot/lightweight-m2m-lwm2m,
n.d.. n.d..
[mirai] Kolias, C., Kambourakis, G., Stavrou, A., and J. Voas,, [mirai] Kolias, C., Kambourakis, G., Stavrou, A., and J. Voas,,
"DDoS in the IoT: Mirai and Other Botnets", IEEE "DDoS in the IoT: Mirai and Other Botnets", IEEE
Computer , 2017. Computer , 2017.
skipping to change at page 39, line 46 skipping to change at page 39, line 41
[NHTSA] "Cybersecurity Best Practices for Modern Vehicles", Web [NHTSA] "Cybersecurity Best Practices for Modern Vehicles", Web
https://www.nhtsa.gov/staticfiles/nvs/ https://www.nhtsa.gov/staticfiles/nvs/
pdf/812333_CybersecurityForModernVehicles.pdf, n.d.. pdf/812333_CybersecurityForModernVehicles.pdf, n.d..
[NIST-Guide] [NIST-Guide]
Ross, R., McEvilley, M., and J. Oren, "Systems Security Ross, R., McEvilley, M., and J. Oren, "Systems Security
Engineering", Web Engineering", Web
http://nvlpubs.nist.gov/nistpubs/SpecialPublications/ http://nvlpubs.nist.gov/nistpubs/SpecialPublications/
NIST.SP.800-160.pdf, n.d.. NIST.SP.800-160.pdf, n.d..
[nist_lightweight_project] [nist-lightweight-project]
"NIST lightweight Project", Web www.nist.gov/programs- "NIST lightweight Project", Web www.nist.gov/programs-
projects/lightweight-cryptography, projects/lightweight-cryptography,
www.nist.gov/sites/default/files/documents/2016/10/17/ www.nist.gov/sites/default/files/documents/2016/10/17/
sonmez-turan-presentation-lwc2016.pdf, n.d.. sonmez-turan-presentation-lwc2016.pdf, n.d..
[NISTSP800-122] [NISTSP800-122]
Erika McCallister, ., Tim Grance, ., and . Karen Scarfone, Erika McCallister, ., Tim Grance, ., and . Karen Scarfone,
"NIST SP800-122 - Guide to Protecting the Confidentiality "NIST SP800-122 - Guide to Protecting the Confidentiality
of Personally Identifiable Information", Web of Personally Identifiable Information", Web
https://nvlpubs.nist.gov/nistpubs/legacy/sp/ https://nvlpubs.nist.gov/nistpubs/legacy/sp/
skipping to change at page 41, line 15 skipping to change at page 41, line 10
[RFC4016] Parthasarathy, M., "Protocol for Carrying Authentication [RFC4016] Parthasarathy, M., "Protocol for Carrying Authentication
and Network Access (PANA) Threat Analysis and Security and Network Access (PANA) Threat Analysis and Security
Requirements", RFC 4016, DOI 10.17487/RFC4016, March 2005, Requirements", RFC 4016, DOI 10.17487/RFC4016, March 2005,
<https://www.rfc-editor.org/info/rfc4016>. <https://www.rfc-editor.org/info/rfc4016>.
[RFC4108] Housley, R., "Using Cryptographic Message Syntax (CMS) to [RFC4108] Housley, R., "Using Cryptographic Message Syntax (CMS) to
Protect Firmware Packages", RFC 4108, Protect Firmware Packages", RFC 4108,
DOI 10.17487/RFC4108, August 2005, DOI 10.17487/RFC4108, August 2005,
<https://www.rfc-editor.org/info/rfc4108>. <https://www.rfc-editor.org/info/rfc4108>.
[RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
Kerberos Network Authentication Service (V5)", RFC 4120,
DOI 10.17487/RFC4120, July 2005,
<https://www.rfc-editor.org/info/rfc4120>.
[RFC4422] Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple
Authentication and Security Layer (SASL)", RFC 4422,
DOI 10.17487/RFC4422, June 2006,
<https://www.rfc-editor.org/info/rfc4422>.
[RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol [RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol
(MOBIKE)", RFC 4555, DOI 10.17487/RFC4555, June 2006, (MOBIKE)", RFC 4555, DOI 10.17487/RFC4555, June 2006,
<https://www.rfc-editor.org/info/rfc4555>. <https://www.rfc-editor.org/info/rfc4555>.
[RFC4621] Kivinen, T. and H. Tschofenig, "Design of the IKEv2 [RFC4621] Kivinen, T. and H. Tschofenig, "Design of the IKEv2
Mobility and Multihoming (MOBIKE) Protocol", RFC 4621, Mobility and Multihoming (MOBIKE) Protocol", RFC 4621,
DOI 10.17487/RFC4621, August 2006, DOI 10.17487/RFC4621, August 2006,
<https://www.rfc-editor.org/info/rfc4621>. <https://www.rfc-editor.org/info/rfc4621>.
[RFC4738] Ignjatic, D., Dondeti, L., Audet, F., and P. Lin, "MIKEY- [RFC4738] Ignjatic, D., Dondeti, L., Audet, F., and P. Lin, "MIKEY-
skipping to change at page 41, line 46 skipping to change at page 42, line 5
[RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler,
"Transmission of IPv6 Packets over IEEE 802.15.4 "Transmission of IPv6 Packets over IEEE 802.15.4
Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007,
<https://www.rfc-editor.org/info/rfc4944>. <https://www.rfc-editor.org/info/rfc4944>.
[RFC5191] Forsberg, D., Ohba, Y., Ed., Patil, B., Tschofenig, H., [RFC5191] Forsberg, D., Ohba, Y., Ed., Patil, B., Tschofenig, H.,
and A. Yegin, "Protocol for Carrying Authentication for and A. Yegin, "Protocol for Carrying Authentication for
Network Access (PANA)", RFC 5191, DOI 10.17487/RFC5191, Network Access (PANA)", RFC 5191, DOI 10.17487/RFC5191,
May 2008, <https://www.rfc-editor.org/info/rfc5191>. May 2008, <https://www.rfc-editor.org/info/rfc5191>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008,
<https://www.rfc-editor.org/info/rfc5246>.
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
RFC 5652, DOI 10.17487/RFC5652, September 2009, RFC 5652, DOI 10.17487/RFC5652, September 2009,
<https://www.rfc-editor.org/info/rfc5652>. <https://www.rfc-editor.org/info/rfc5652>.
[RFC5713] Moustafa, H., Tschofenig, H., and S. De Cnodder, "Security [RFC5713] Moustafa, H., Tschofenig, H., and S. De Cnodder, "Security
Threats and Security Requirements for the Access Node Threats and Security Requirements for the Access Node
Control Protocol (ANCP)", RFC 5713, DOI 10.17487/RFC5713, Control Protocol (ANCP)", RFC 5713, DOI 10.17487/RFC5713,
January 2010, <https://www.rfc-editor.org/info/rfc5713>. January 2010, <https://www.rfc-editor.org/info/rfc5713>.
[RFC5903] Fu, D. and J. Solinas, "Elliptic Curve Groups modulo a [RFC5903] Fu, D. and J. Solinas, "Elliptic Curve Groups modulo a
skipping to change at page 45, line 15 skipping to change at page 45, line 15
[RFC8240] Tschofenig, H. and S. Farrell, "Report from the Internet [RFC8240] Tschofenig, H. and S. Farrell, "Report from the Internet
of Things Software Update (IoTSU) Workshop 2016", of Things Software Update (IoTSU) Workshop 2016",
RFC 8240, DOI 10.17487/RFC8240, September 2017, RFC 8240, DOI 10.17487/RFC8240, September 2017,
<https://www.rfc-editor.org/info/rfc8240>. <https://www.rfc-editor.org/info/rfc8240>.
[RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
Interchange Format", STD 90, RFC 8259, Interchange Format", STD 90, RFC 8259,
DOI 10.17487/RFC8259, December 2017, DOI 10.17487/RFC8259, December 2017,
<https://www.rfc-editor.org/info/rfc8259>. <https://www.rfc-editor.org/info/rfc8259>.
[RFC8376] Farrell, S., Ed., "Low-Power Wide Area Network (LPWAN)
Overview", RFC 8376, DOI 10.17487/RFC8376, May 2018,
<https://www.rfc-editor.org/info/rfc8376>.
[RFC8428] Jennings, C., Shelby, Z., Arkko, J., Keranen, A., and C.
Bormann, "Sensor Measurement Lists (SenML)", RFC 8428,
DOI 10.17487/RFC8428, August 2018,
<https://www.rfc-editor.org/info/rfc8428>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>.
[RG-T2TRG] [RG-T2TRG]
"IRTF Thing-to-Thing (T2TRG) Research Group", "IRTF Thing-to-Thing (T2TRG) Research Group",
Web https://datatracker.ietf.org/rg/t2trg/charter/, n.d.. Web https://datatracker.ietf.org/rg/t2trg/charter/, n.d..
[SchneierSecurity] [SchneierSecurity]
"The Internet of Things Is Wildly Insecure--And Often "The Internet of Things Is Wildly Insecure--And Often
Unpatchable", Web Unpatchable", Web
https://www.schneier.com/essays/archives/2014/01/ https://www.schneier.com/essays/archives/2014/01/
the_internet_of_thin.html, n.d.. the_internet_of_thin.html, n.d..
 End of changes. 41 change blocks. 
91 lines changed or deleted 109 lines changed or added

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