Filter by topic and date
IETF 105: Internet of Things Wrapup
9 Sep 2019
Continuing the tradition of activity around the IETF on the Internet of Things (IoT), there was a great deal of work on topics related to or affecting IoT in Montreal at the latest IETF Hackathon and IETF 105 meeting.
For those interested in following or participating in IoT-related standards development, IETF working groups (WGs) are open to any interested individual. Much of the work of the IETF takes place on mailing lists. Links to details about respective WGs, including email lists, are included throughout this post.
Getting MUD-y
Update from Eliot Lear
The second largest table at the IETF Hackathon was focused on Manufacturer Usage Descriptions (MUD - RFC 8520). Within a span of four hours, a device manufacturer could implement MUD and test against four separate MUD managers. MUD atop the Wifi Alliance’s Device Provisioning Protocol (DPP) specification was also demonstrated.
The CIRA Labs team began the redesign of mudmaker.org internals, developing a python version known as muddy. The IETF Hackathon MUD team worked on a tool developed by Paul Watrobski at NIST/University of Maryland that observes packet flows and generates MUD files known as MUDPI. Finally, we worked on a means to report to manufacturers how MUD-protected devices are, in fact, being protected. This same table featured additional work by Michael Richardson on ANIMA Autonomic Control Plane (ACP).
Later in the week, several sessions at the IETF 105 meeting focused on IoT onboarding and MUD extensions. The document draft-ietf-anima-bootstrapping-key-infra, which was developed in the ANIMA working group, has subsequently been submitted to the Internet Engineering Steering Group for publication as an RFC. One of the key issues has been what alternate means would be available to onboard a device when the Manufacturer Authorized Signing Authority (MASA) is no longer available. There are a number of proposals on how to do this, some involve replacing trust anchors, others involve chains of RFC 8366 vouchers, but it is far from clear that there is any single choice that satisfies all situations.
Over in the Operations and Management Area Working Group (OPSAWG) numerous extensions to MUD were proposed, including a profile for Transport Layer Security (TLS) crypto suite identification (draft-reddy-opsawg-mud-tls). Attackers tend to use their own crypto suites, so a profile that indicates the correct crypto suite is being investigated as a means to identify those attacks. A new draft draft-richardson-opsawg-mud-iot-dns-considerations aims to provide guidance on how to use DNS from IoT devices in a way that is compatible with MUD. A separate draft, draft-lear-opsawg-mud-controller-candidates, looks at how to identify candidates to be controllers for different classes of devices.
There is now a discussion on whether to establish a separate MUD working group. To participate, you can join the opsawg@ietf.org or mud@ietf.org mailing lists. This includes the possibility of a wider scope cross-area IoT Operational Security WG that would include MUD.
Laying Foundations for IoT Security
Update from Mohit Sethi
With publication RFC 8576–Internet of Things (IoT) Security: State of the Art and Challenges–the Thing-to-Thing Research Group (T2TRG) documented the current IoT security initiatives at the IETF (and elsewhere). It also discussed some important security challenges that remain. One of the key challenges identified in the document was how the things in IoT networks can be securely configured before they are functional. This step is especially challenging as the number of these things may be large and they often have very limited user interfaces. The initial configuration of things may involve several sub-steps that must be completed before the thing is fully operational. Each of these sub-steps can be viewed in terms of authorization chains that need to be established. In the next phase of its research work, T2TRG will work on documenting the various terminology related to this initial configuration step.
For more on the T2TRG session at IETF 105, see the published minutes. You can follow the ongoing the discussion at t2trg@irtf.org.
Lightweight Implementation Guidance (LWIG)
Update from Mohit Sethi
The LWIG working group did not meet at IETF 105. However, there are active discussions on a number of topics underway in the working group. Anyone interested in participating in this important work is encouraged to do so by joining the mailing list. See the LWIG page for more information.
EMU takes flight
Update from Eliot Lear and Mohit Sethi
In many IoT scenarios, it is often not possible to rely on the existence of a trusted third party or other network infrastructure for bootstrapping, so the EAP Method Update (EMU) working group is currently considering several draft bootstrapping solution proposals for IoT devices which have no pre-configured authentication credentials and which are not yet registered on an authentication server. Nimble out-of-band (OOB) authentication for Extensible Authentication Protocol (EAP-NOOB) is a generic approach to address the bootstrapping issue. The draft specification defines an EAP method where the authentication is based on a user-assisted OOB channel between the server and peer. EAP-NOOB is more generic than most ad-hoc bootstrapping solutions in that it supports many types of OOB channels, including QR codes, NFC, sound, and blinking lights. The draft already has an open source implementation and has formal security proofs.
In addition, several drafts relating to BRSKI (Bootstrapping Remote Secure Key Infrastructures) and RFC 8366 were presented in the EMU WG session:
draft-fries-async-enroll-01 looks at what happens when a certificate authority is temporarily unavailable.
draft-lear-eap-teap-brski provides a BRSKI flow within TEAP (RFC 7170).
draft-aura-eap-noob-06 specifies a method for nimble out-of-band authentication for Extensible Authentication Protocol (EAP) (More on this in Mohit Sethi’s update below)
The EAP Method Update (EMU) working group is in the process of rechartering and to participate in these discussions, you can join the emu@ietf.org working group mailing list and the iot-onboarding@ietf.org mailing list.
Running code for IoT
In addition to the IETF Hackathon projects already mentioned, several others included IoT-related work:
- ANIMA ACP
- HOMENET/DNSSD build-out
- MUD
- Trusted Execution Environment Provisioning (TEEP)
- IP Wireless Access in Vehicular Environments (IPWAVE) Basic Protocols
- WISHI (Work on IoT Semantic / Hypermedia Interoperability)
- LPWAN CoAP/UDP/IPv6 SCHC compression and fragmentation
The IETF Hackathon wiki has additional details on all the projects worked on in Montreal. The next Hackathon in Singapore for IETF 106 (Nov. 16-17, 2019) promises to continue the trend of several IoT-related projects. For more information, see the Hackathon page.
About the author
Steve Olshansky is the Internet Technology Program Manager at the Internet Society, based in Colorado, United States.
Bibliography
-
[1]RFC 8366
A Voucher Artifact for Bootstrapping Protocols
This document defines a strategy to securely assign a pledge to an owner using an artifact signed, directly or indirectly, by the pledge's manufacturer. This artifact is known as a "voucher". This document defines an artifact format as a YANG-defined JSON document that has been signed using a Cry…
-
[2]RFC 8576
Internet of Things (IoT) Security: State of the Art and Challenges
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 for IoT systems are well recognized, and many standardization steps to provide security have been taken -- for example, the specif…
-
[3]RFC 7170
Tunnel Extensible Authentication Protocol (TEAP) Version 1
This document defines the Tunnel Extensible Authentication Protocol (TEAP) version 1. TEAP is a tunnel-based EAP method that enables secure communication between a peer and a server by using the Transport Layer Security (TLS) protocol to establish a mutually authenticated tunnel. Within the tunne…