Internet DRAFT - draft-garciamorchon-t2trg-automated-iot-security
draft-garciamorchon-t2trg-automated-iot-security
Network Working Group O. Garcia-Morchon
Internet-Draft Philips
Intended status: Informational T. Dahm
Expires: April 22, 2019 Google
October 19, 2018
Automated IoT Security
draft-garciamorchon-t2trg-automated-iot-security-01
Abstract
The Internet of Things (IoT) concept refers to the usage of standard
Internet protocols to allow for human-to-thing and thing-to-thing
communication. The security needs are well-recognized but the design
space of IoT applications and systems is complex and exposed to
multiple types of threats. In particular, threats keep evolving at a
fast pace while many IoT systems are rarely updated and still remain
operational for decades.
This document describes a comprehensive agile security framework to
integrate existing security processes such as risk assessment or
vulnerability assessment in the lifecycle of a smart object in an IoT
application. The core of our agile security approach relies on two
protocols: the Protocol for Automatic Security Configuration (PASC)
and the Protocol for Automatic Vulnerability Assessment (PAVA). PASC
is executed during the onboarding phase of a smart object in an IoT
system and is in charge of automatically performing a risk assessment
and assigning a security configuration - applicable to the device or
the system - to defeat the identified risks. The assigned security
configuration fits the specific environment and threat model of the
application in which the device has been deployed. PAVA is executed
during the operation of the IoT object and ensures that
vulnerabilities in the smart object and IoT system are discovered in
a proactive way.
These two protocols can benefit users, manufactures and operators by
automating IoT security.
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 https://datatracker.ietf.org/drafts/current/.
Garcia-Morchon & Dahm Expires April 22, 2019 [Page 1]
Internet-Draft Automated IoT Security October 2018
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 22, 2019.
Copyright Notice
Copyright (c) 2018 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
(https://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 . . . . . . 2
2. Integrating automated security processes in the IoT lifecycle 3
2.1. Automated Security Processes for Manufacturers . . . . . 3
2.2. Automated Security Processes for Users . . . . . . . . . 3
2.3. Automated Security Processes for System Integrators . . . 4
3. Integrating security workflows in the IoT lifecycle . . . . . 4
3.1. Security workflows: which ones and how they are
traditionally applied. . . . . . . . . . . . . . . . . . 4
3.2. Automating security workflows . . . . . . . . . . . . . . 6
4. Automated IoT security protocols: PASC and PAVA . . . . . . . 7
4.1. PASC: Protocol for Automatic Security Configuration . . . 8
4.2. Protocol for Automatic Vulnerability Assessment (PAVA) . 10
5. Conclusions and security considerations . . . . . . . . . . . 10
6. Next steps . . . . . . . . . . . . . . . . . . . . . . . . . 11
7. Informative References . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
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].
Garcia-Morchon & Dahm Expires April 22, 2019 [Page 2]
Internet-Draft Automated IoT Security October 2018
2. Integrating automated security processes in the IoT lifecycle
The lifecycle of many smart objects in IoT applications such as
building automation follows the design and manufacturing processes of
traditional hardware components. This means that devices go through
a number of phases in their lifecycles that are predefined and rigid,
namely design, manufacturing, installation, commissioning, or
operation, to name a few of them [IOTSec]. This implies that
security is often pre-configured, and this pre-configuration leads to
a number of security problems for manufacturers, users, and system
operators.
To deal with these problems, we propose the definition of two
protocols, PASC and PAVA. PASC aims at automating the security
configuration based on information provided by devices, users,
manufactures, and system operators. PAVA aims at automating the
discovery of new bugs, potential vulnerabilities, and security
misconfigurations by gathering information from the actual system,
analyzing it, and updating security settings.
2.1. Automated Security Processes for Manufacturers
A manufacturer cannot be aware at design place about the security
risks that might appear in the future. Also, often a manufacturer
cannot be absolutely certain how his product will be used later on
and in what function. A famous example is the newspaper which can
also be used as fly swat. Thus, it is very hard for the manufacturer
to foresee and implement all security mechanisms and policies that
would be applicable to its devices in a wide variety of use cases.
This document introduces security automation into the IoT ecosystem
by pursuing a Test Driven Development (TDD) approach as explained in
[TDD]. The benefit of TDD for the manufacturer is that products,
which pass all the tests, are ready to be shipped. Additionally,
manufacturers benefit from this automation approach since they do not
need to decide which security mitigations they require on a product.
Instead of it, they just need to describe the expected usage of the
product, e.g., via MUD files, the PASC and PAVA protocols will then
automatically configure the security settings in the system.
2.2. Automated Security Processes for Users
A user is often interested in buying, combining, and running devices
from multiple manufacturers. Uses might also have different security
and privacy needs. From this point of view, users might have issues
making sure that the security settings of his purchased devices and
subsystems work together.
Garcia-Morchon & Dahm Expires April 22, 2019 [Page 3]
Internet-Draft Automated IoT Security October 2018
Users benefit from integrating security into the full IoT lifecycle
since security configuration is transparently done in an automatic
way by means of the PASC and PAVA protocols - they need to do
nothing. Security settings are automatically configured according to
the specific deployment environment that a user only needs to
confirm.
2.3. Automated Security Processes for System Integrators
System integrators and operators have to make sure that the overall
system - including multiple devices from different manufactures and
interacting with many users - is deployed and executed in a secure
way. Sometimes, it is also necessary or desired to use products not
according to their original purpose, but to repurpose them for a more
beneficial use case. Fixed configurations hinder those tasks and
make it also difficult to rapidly act in the event of security
vulnerabilities.
System operators benefit of PASC and PAVA since they minimize
operational cost while ensuring that the system remains secure at any
moment: PASC allows them to configure security automatically; PAVA
allows for automated vulnerability detection A potential
instantiation of part of these protocols follows a Software Defined
Network methodology in which network interactions are enabled/
disabled by the network controller depending on the information
available in the collected MUD files from the devices. Operators can
also adopt the TDD approach and proof compliance with existing
security policies for any IoT device by running continuous PAVA tests
against the existing IoT installation. If events like software
updates introduce an unexpected behavior, the SDN infrastructure will
immediately catch and report it.
3. Integrating security workflows in the IoT lifecycle
This section first discusses existing security workflows and how they
are usually applied and then it explains how to integrate those
security workflows in the IoT lifecycle.
3.1. Security workflows: which ones and how they are traditionally
applied.
Dealing with security threats and finding suitable security
mitigations is challenging: there are very sophisticated threats that
a very powerful attacker could use; also, new threats and exploits
appear in a daily basis. Therefore, the existence of proper secure
product creation processes that allow managing and minimizing risks
during the lifecycle of the IoT devices is at least as important as
Garcia-Morchon & Dahm Expires April 22, 2019 [Page 4]
Internet-Draft Automated IoT Security October 2018
being aware of the threats. A non-exhaustive list of relevant
processes include:
1. A Business Impact Analysis (BIA) assesses the consequences of
loss of basic security attributes, namely, confidentiality,
integrity and availability in an IoT system. These consequences
might include impact on data lost, sales lost, increased
expenses, regulatory fines, customer dissatisfaction, etc.
Performing a business impact analysis allow determining the
business relevance of having a proper security design placing
security in the focus.
2. A Risk Assessment (RA) analyzes security threats to the IoT
system, considering their likelihood and impact, and deriving for
each of them a risk level. Risks classified as moderate or high
must be mitigated, i.e., security architecture should be able to
deal with that threat bringing the risk to a low level. Note
that threats are usually classified according to their goal:
confidentiality, integrity, and availability. For instance, a
specific threat to recover a symmetric-key used in the system
relates to confidentiality.
3. A privacy impact assessment (PIA) aims at assessing Personal
Identifiable Information (PII) that is collected, processed, or
used in the IoT system. By doing so, the goals is to fulfill
applicable legal requirements, determine risks and effects of the
manipulation of PII, and evaluate proposed protections.
4. Procedures for vulnerability assessment (VA) aim at assessing
whether the IoT system is secure or any vulnerabilities are
present. This can be due to changes in the context information
such as people involved in the IoT system or new software
vulnerabilities discovered.
5. Procedures for incident reporting (IR) and mitigation refer to
the methodologies that allow becoming aware of any security
issues that affect an IoT system.
Traditionally, BIA, RA, PIA or VA are to be realized during the
creation of a new IoT system, introduction of new technologies in the
IoT system, or deployment of significant system upgrades. In
general, it is recommended to re-assess them on a regular basis
taking into account new use cases or threats. VA is also often
realized before deployment, e.g., by performing a penetration test
before the new product release is deployed. Incident reporting is
done during operation of the IoT system, when a vulnerability is
discovered.
Garcia-Morchon & Dahm Expires April 22, 2019 [Page 5]
Internet-Draft Automated IoT Security October 2018
All these processes, namely BIA, RA, PIA, VA, and IR, are a must in
the design of any IoT system. If they are not performed, the risk of
not having a secure enough system is very high. However, even if
these procedures are in place, the IoT systems can still have an
unsatisfactory security level because of two main reasons: fixed
design decisions do not necessarily apply to all deployments due to
specific requirements of users and operators or the nature of the
final system. new vulnerabilities might appear.
_Manufactured _SW update _Decommissioned
/ / /
| _Installed | _ Application | _Removed &
| / | / reconfigured | / replaced
| | _Commissioned | | | |
| | / | | | | _Reownership &
| | | _Application | | _Application | | / recommissioned
| | | / running | | / running | | |
| | | | | | | | | | \\
+##+##+###+#############+##+##+#############+##+##+##############>>>
\ \/ \______________________________________/ / time //
\ \ \ /
BIA \ Continuous VA--->IR /
RA and PIA <__________| RA and PIA
Figure 1: Security workflows integrated in the lifecycle of a thing
in the Internet of Things.
3.2. Automating security workflows
Automating IoT security means integrating IoT security workflows in
the IoT lifecycle. Figure 1 depicts this concept: on the top part of
that figure, we see the traditional steps in the lifecycle of a
device: manufacturing, installation, commissioning, application
running, etc. Usually, the security workflows discussed in
Section 2.1 would only happen at the beginning. The goal is to move
integrate them during the lifecycle - as shown on the bottom part of
the figure. With this we aim at:
1. making sure that the security settings, methods and policies
applied to a given IoT deployment fit the requirements and
threats in that specific deployment.
2. ensuring fast reaction in case of new vulnerabilities or changes
in the security requirements.
In the figure, we observe that RA and PIA are moved from the design
phase to the installation and commissioning phases of the devices
Garcia-Morchon & Dahm Expires April 22, 2019 [Page 6]
Internet-Draft Automated IoT Security October 2018
since it is then when the actual environment in which smart objects
are deployed is really known. At this point of time, it is possible
to gather information about the security requirements of the users,
other devices in the system that my pose a threat to the new devices
or even new vulnerabilities that might have appeared since the
manufacturing of the device till the installation phase.
The VA is executed not only during implementation, but it keeps
running during the operation of the IoT system. Information gathered
during VA is fed into the RA and PIA processes to update security
settings. Similarly, security incidents found out during continuous
VA lead to IR. When smart objects are sold or the system updated,
this triggers again RA and PIA.
4. Automated IoT security protocols: PASC and PAVA
This section introduces the two protocols for automated IoT security
that this document proposes: Protocol for Automatic Security
Configuration (PASC) and Protocol for Automated Vulnerability
Assessment (PAVA).
The underlying idea of the protocols is shown at a very high level in
Figure 2. PASC is used initially when a device first joins the IoT
system to adjust the system and device security settings. Then PAVA
starts its operation monitoring potential vulnerabilities. If
changes in security settings are required, those are then applied by
means of PASC messages.
Garcia-Morchon & Dahm Expires April 22, 2019 [Page 7]
Internet-Draft Automated IoT Security October 2018
______________________________________________________________
| | |
| IoT device Controller Router Information
| | source
| | |
| ++ PASC onboarding ++> | |
| <++PASC device info +++++ |
| | |
| Risk & privacy assessment | |
| | |
| <+++++ PASC security config. +++++>| |
| | |
| | |
| | |
| | |
| | |
| +++ PAVA log ++++++> | |
| <++ PAVA active monitoring ++> | |
| <++ PAVA vulnerabilities +++++ |
| | |
| Risk & privacy assessment | |
| | |
| <+++++ PASC security config. +++++>| |
| |
| ____________________________________________________________
Figure 2: PASC and PAVA interactions.
In the event of a PAVA_VULNERABILITY being received from an
INFORMATION SOURCE which is not already patched in the IoT device,
the CONTROLLER SHOULD aim to mitigate this PAVA_VULNERABILITY by
blocking access to the vulnerable IoT device temporary until the
device can be updated.
4.1. PASC: Protocol for Automatic Security Configuration
Figure 1 depicts the main parties involved in an IoT system: an IoT
DEVICE, a device controlling the IoT domain called CONTROLLER, a
ROUTER towards the IoT domain, and an INFORMATION SOURCE such as it
might be a local user, the manufacturer of the IoT device or a cloud
IoT management system.
The protocol flow is as follows:
o The IoT DEVICE performs a PASC ONBOARDING exchange in which the
system CONTROLLER obtains information about the device from the
IoT DEVICE itself.
Garcia-Morchon & Dahm Expires April 22, 2019 [Page 8]
Internet-Draft Automated IoT Security October 2018
o The CONTROLLER can also receive PASC DEVICE INFO from other
INFORMATION SOURCES such as a local user, the manufacturer,
vulnerability cloud,
o The CONTROLLER automatically performs a RISK ASSESSMENT and
PRIVACY IMPACT ANALYSIS based on the information about the new IOT
DEVICE, system, and information
o Finally, the CONTROLLER configures the system security by means of
PASC SECURITY CONFIGURATION MESSAGE. Configuration can apply to
the new IoT DEVICES, existing IoT devices, or networking
infrastructure such as the ROUTER.
In certain IoT environments, a simple practical instantiation of PASC
can be created by extending and combining a number of protocols.
PASC ONBOARDING resemble steps of the Manufacturer Usage Descriptor
(MUD) protocol by explicitly listing any internal and external
accesses the device needs to make, and/or clearly specify if there's
an intentionally open server (e.g., HTTPS port exposed) and might be
reused after potential enhancements. Additionally the PASC
ONBOARDING needs to include the security policy of the environment
the IoT devices are deployed within, for example by verifying the
exposed HTTPS server includes a non-vulnerable TLS 1.2 implementation
with the desired cipher suites. PASC SECURITY CONFIGURATION MESSAGE
might be instantiated in a SDN fashion by means of influencing the
routing flows . PASC SECURITY CONFIGURATION MESSAGES might also apply
to end devices, and they might realized with extensions of ACE.
Another alternative consists in changing actual software
configurations in the end devices although this is a less realistic
approach for IoT use cases.
The Test Specification must therefore be a description of the
expected behavior of the IoT device that can be used to adjust tests
accordingly. For example, the specification should explicitly list
any internal and external accesses the device needs to make, and/or
clearly specify if there's an intentionally open server (e.g., HTTPS
port exposed). This Thing description SHOULD come from Manufacturer
Usage Description (MUD). Additionally the Test Specification needs
to include the security policy of the environment the IoT devices are
deployed within, for example additional tests to verify the exposed
HTTPS server includes a non-vulnerable TLS 1.2 implementation with
the desired cipher suites.
Network Services modules on the SDN Controller provide for core
network services (such as DHCP, DNS, NTP) and mediated access to
external resources (e.g., cloud services). A set of "foundational
tests" (e.g., DHCP timeouts) SHOULD be part of any Test
Specification. The system can capture a packet trace for the
Garcia-Morchon & Dahm Expires April 22, 2019 [Page 9]
Internet-Draft Automated IoT Security October 2018
individual device, which can be analyzed during the RISK ASSESSMENT
as described in point 3 of section 3.1.
4.2. Protocol for Automatic Vulnerability Assessment (PAVA)
The Protocol for Automatic Vulnerability Assessment (PAVA) aims at
assessing for vulnerability when the IoT DEVICES are operational.
PAVA is designed to be a key factor for Test Driven Development (TDD)
[TDD]. The main aspects of PAVA are as follows:
1. PAVA relies on each IoT DEVICE sending standardized reports
PAVA_LOG of potential vulnerabilities to CONTROLLER, e.g., the
SDN controller managing the IoT security domain. Such reports
would build on RFC5424 (Syslog protocol), RFC5425 (TLS for
Syslog) and RFC5426 (Syslog over UDP).
2. The CONTROLLER can also perform PAVA_ACTIVE_MONITORING that
refers to messages aiming at verifying that the IoT DEVICE does
not suffer known vulnerabilities.
3. The CONTROLLER can also receive PAVA_VULNERABILITIES messages
from any INFORMATION SOURCE.
4. Based on the above information, the CONTROLLER can update RISK
and PRIVACY ASSESSMENTS. The CONTROLLER reports and methodology
can be based on related work such as RFC6872.
5. If needed, the controller can update security settings with a
PASC_SECURITY_CONFIGURATION message. Output of this decision can
result in 4 different actions:
* incident report towards the user
* update of security profiles in IoT DEVICES of the IoT security
domain.
* automatic incident reporting towards the manufacturer
* automatic incident reporting towards the platform provider
5. Conclusions and security considerations
Security is a key factor in the acceptance and long-term success of
IoT systems. Non-smart versions of physical objects in the real
word, for example light switches or door locks, can benefit from the
modern approach to software engineering. he building and
manufacturing industry for example are relatively slowly changing
industry sectors due to high demands and regulations on safety and
Garcia-Morchon & Dahm Expires April 22, 2019 [Page 10]
Internet-Draft Automated IoT Security October 2018
security of the physical products they produce, e. g. bridges or
houses, however, the IT and Web industry are one of the most dynamic
industry sectors currently existing and can bring capabilities to
make products even safer.
Additionally, there is a fundamental difference of traditional
connected and networked devices "for people" vs. IoT devices which
are typically headless. E. g., many standard application layer
authentication mechanisms like OAuth assume a person is there to "do
something" in a challenge response sequence. Also, people have an
identity, that typically links to authorization of resources, while
an IoT device is more single-purpose and typically has no intrinsic
sense of other resources it might/should communicate with. This
distinction between devices lends itself to a number of
considerations in terms of authentication, access control,
manageability, and other challenges that will take time to properly
normalize in a modern IoT enabled world.
From a security perspective, it is important to ensure that IoT
devices can be trusted. There are simply too many of them, and due
to their constrained nature there are often compromises that weaken
security overall.
The main contribution of this document is to describe and propose
protocols to automate IoT security to deal with the complex IoT
security design space. This is done in two steps. First, the PASC
protocol allows to automatically configure devices and deploying
security profiles - sets of security configurations - to the devices
and system infrastructure. Most IoT devices are typically focused on
their physical task rather than on being general purpose computing
platforms. Therefore, the security profiles described in this
document aim to bridge the initial risk analysis gap between the
involved industry sectors and put a higher emphasis on the minimizing
risk and containing the blast radius factors. Second, the PAVA
protocol allows to automatically monitor and audit the operation of
the network and system. This ensures fast reaction to any potential
vulnerabilities and attacks.
6. Next steps
This draft proposes to automate IoT security by means of PASC & PAVA
protocols. IoT security automation would have clear benefits for
manufactures, users, and system operators.
If this direction is attractive and supported, we envision the
following IETF work:
Garcia-Morchon & Dahm Expires April 22, 2019 [Page 11]
Internet-Draft Automated IoT Security October 2018
1. Definition of IoT use cases, overall architecture for IoT
security automation, and applicable techniques(e.g., MUD, SDN,
ACE,...) to realize PASC & PAVA.
2. Define minimum viable PASC & PAVA protocols, i.e., protocols that
allow realizing the concept of automated security with the
smallest amount of work. This definition will target building
automation use cases. This work requires the following:
* specifying the information required during onboarding: (1)
general provisioning information, for example QR codes
containing information like MAC address of the IoT device for
easy ingestion of those information into hardware databases;
(2) a description of the expected behavior of the IoT device
from Manufacturer Usage Description (MUD); (3) environment
specific requirements, for example a security policy that is
machine-readable; (4) network & application specific
information including the definition of the supported
protocols, e.g., IPv4, IPv6, application specific networking
information, e.g., SSID, and authentication and authorization
methodology, e.g., using WPA2 or 802.1X.
* describing the required input for the automation part: (1)
end-users should be allowed to enter security and privacy
preferences that should be easily convertible into a machine
readable policy; (2) manufacturers provide MUD files
potentially with some extensions to support automated security
uses cases; (3) system integrators provide the environment
specific network and security specifications as listed above.
* defining the output required or desired by users, routing
infrastructure and end devices. This includes routing and
firewalling policies for routing infrastructure; security
policies and configurations for the end devices including
blocked services, whitelist of services in other devices;
security configurations and security reports for end users,
system operators, and manufacturers (see Section 3.2 point
#5).
* standardizing the PASC Messages, message fields, and
interactions between new device, controller, and routing
infrastructure including transport protocol for PASC and PAVA
messages as well as encoding of security configuration using
YANG.
* creating the RA and PIA logic to generate the (SDN) security
configuration in controller and deploy to routers. This can
include individual pre-computed flow tables per routing device
Garcia-Morchon & Dahm Expires April 22, 2019 [Page 12]
Internet-Draft Automated IoT Security October 2018
determining which end-devices can talk to each other and which
services are available to each other. Non-allowed
communication patterns are blocked.
* standardizing the PAVA policy and messages for vulnerability
assessment as well as messages/Information required from
services to perform PAVA. This involves the definition of a
policy that determines the behaviour of PAVA regarding the
monitoring capabilities (active vs passive), data collection
capabilities, and reporting capabilities.
There are several groups within IETF and IRTF working on aspects
related to the ideas presented in this group and for which this work
can be interesting:
1. IRRF Thing to Thing Research Group (T2TRG) [T2TRG] investigates
open research issues in turning a true "Internet of Things" into
reality, an Internet where llow-resource nodes ("things",
"constrained nodes") can communicate among themselves and with
the wider Internet, in order to partake in permissionless
innovation.
2. IETF Automated Networking Integrated Model and Approach (ANIMA)
[ANIMA] develops a system of autonomic functions that carry out
the intentions of the network operator without the need for
detailed low-level management of individual devices.
3. IETF Operations and Management Area Working Group
(OPSAWG)[OPSAWG] receives occasional proposals for the
development and publication of RFCs dealing with operational and
management topics that are not in scope of an existing working
group and do not justify the formation of a new working group.
4. IETF Interface to the Routing System (I2RS) [I2RS] facilitates
real-time or event driven interaction with the routing system
through a collection of protocol-based control or management
interfaces. These allow information, policies, and operational
parameters to be injected into and retrieved (as read or by
notification) from the routing system while retaining data
consistency and coherency across the routers and routing
infrastructure,
5. IETF Security Automation and Continuous Monitoring (SACM) [SACM].
In their charter, they write: "Securing information and the
systems that store, process, and transmit that information is a
challenging task for enterprises of all sizes, and many security
practitioners spend much of their time on manual processes.
Standardized protocols and models aiding collection and
Garcia-Morchon & Dahm Expires April 22, 2019 [Page 13]
Internet-Draft Automated IoT Security October 2018
evaluation of endpoint elements enable automation, thus freeing
practitioners to focus on high priority tasks. Due to the
breadth of this work, the working group will address enterprise
use cases pertaining to the assessment of endpoint posture (using
the definitions of Endpoint and Posture from RFC 5209)."
An open question for the authors is where this work could be done
best.
7. Informative References
[ACE] "IETF Authentication and Authorization for Constrained
Environments",
Web https://datatracker.ietf.org/wg/ace/charter/, n.d..
[ANIMA] "IETF Automated Networking Integrated Model and Approach",
Web https://datatracker.ietf.org/wg/anima/about/, n.d..
[I2RS] "IETF Interface to the Routing System",
Web https://datatracker.ietf.org/wg/i2rs/about/, n.d..
[ID-MUD] Lear, E., Droms, R., and D. Domascanu, "Manufacturer Usage
Description Specification", March 2017.
[IOTSec] Garcia-Morchon, O., Kumar, S., and M. Sethi, "State-of-
the-Art and Challenges for the Internet of Things
Security", draft-irtf-t2trg-iot-seccons-15 , May 2018.
[OPSAWG] "IETF Operations and Management Area Working Group",
Web https://datatracker.ietf.org/wg/opsawg/about/, n.d..
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[SACM] "IETF Security Automation and Continuous Monitoring",
Web https://datatracker.ietf.org/wg/sacm/about/, n.d..
[T2TRG] "IRTF Thing-to-Thing (T2TRG) Research Group",
Web https://datatracker.ietf.org/rg/t2trg/charter/, n.d..
[TDD] Janzen, D. and H. Saiedian, "Test-driven development
concepts, taxonomy, and future direction",
Web https://ieeexplore.ieee.org/abstract/document/1510569,
n.d..
Garcia-Morchon & Dahm Expires April 22, 2019 [Page 14]
Internet-Draft Automated IoT Security October 2018
Authors' Addresses
Oscar Garcia-Morchon
Philips
High Tech Campus 5
Eindhoven, 5656 AA
The Netherlands
Email: oscar.garcia-morchon@philips.com
Thorsten Dahm
Google
todo
Dublin
Ireland
Email: thorstendlux@google.com
Garcia-Morchon & Dahm Expires April 22, 2019 [Page 15]
