The buzz around the Internet of Things (IoT) is only increasing, to the surprise of, well, no one. We are often asked what is happening in the IETF in relation to IoT and in this short post I’d like to highlight some of the relevant activities and sessions scheduled during the upcoming IETF 102 meeting in Montreal. Also check out the IETF Journal IoT Category, the IETF IoT page, the IETF IoT Directorate, the Internet Society’s IoT page, or the Online Trust Alliance (OTA, which became an Internet Society Initiative in April 2017) IoT page for more details about many of these topics.
The IETF Hackathon, held on the weekend preceding the main IETF meeting (July 14-15), includes projects directly related to IoT, with the possibility of more being added. More information is on the Hackathon wiki. Projects of interest include those relating to:
- Software Updates for Internet of Things (suit)
- Authentication and Authorization for Constrained Environments (ace)
- IPv6 over Low Power Wide-Area Networks (lpwan)
- Work on IoT Semantic / Hypermedia Interoperability (WISHI)
The Thing-to-Thing Research Group (T2TRG) investigates open research issues towards turning the IoT into reality. The research group will be meeting on Thursday afternoon in Montreal to report out on their recent activities. Their summary meeting agenda can be found here. As in the past, full details and latest info on their activities can be found in GitHub. Of particular note is the recent update of a key draft document: State-of-the-Art and Challenges for the Internet of Things Security.
Two recently chartered IoT-related working groups met for the first time as working groups at the last IETF meeting in March, and are tackling very serious problems. I am very pleased to see these moving forward:
- Trusted Execution Environment Provisioning (TEEP) is working on standardizing protocols for provisioning applications into secure areas of computer processors.
- Software Updates for Internet of Things (SUIT) is working on mechanisms for securely updating the firmware in IoT devices.
I would like to draw your attention to two recently initiated activities:
- Application Transport LAyer Security (ATLAS) – relating to the re-use of TLS handshaking protocols at the application layer for establishing keying material to protect application data. At the time of this writing, this is the latest version of the proposed charter. Although there will not be a BoF at this IETF meeting, there may be a side meeting convened. If you are interested, keep an eye on the mailing list by either subscribing or reviewing the archive.
- Entity Attestation Token (EAT) – working on an attestation token to prove provenance and characteristics about an end client device, node or entity to a server or service. See this draft outlining the initial proposal. As with ATLAS, there is no BoF scheduled, but there may be a side meeting. If you are interested, keep an eye on the mailing list by either subscribing or reviewing the archive.
In this edition of the Rough Guide I would like to highlight some recent work in SUIT, addressing hash-based signatures. (Description courtesy Russ Housley)
Today, RSA is often used to digitally sign software updates. In preparation for a day when RSA, DSA, and ECDSA cannot be depended upon, a digital signature algorithm is needed that will remain secure even if there are significant cryptoanalytic advances or a large-scale quantum computer is invented. The hash-based digital signature algorithm specified in [HASHSIG] is one such algorithm. The use of hash-based signatures to protect software update distribution will allow the deployment of software that implements new cryptosystems even if such advances break current digital signature mechanisms.
[HASHSIG] specifies the conventions for using the Leighton-Micali Signature (LMS) algorithm, and it is in the final stages of approval in the IRTF CFRG. [HASHSIG-COSE] specifies the conventions for these digital signatures with the CBOR Object Signing and Encryption (COSE) [RFC8152] syntax. The LMS algorithm is one form of hash-based digital signature; it can only be used for a fixed number of signatures. The LMS algorithm uses small private and public keys, and it has low computational cost; however, the signatures are quite large. The mechanism has broader applicability than SUIT, so a home that supports the broader perspective is desirable.
Ongoing work includes:
- The Constrained RESTful Environments (core) WG aims to extend the Web architecture to most constrained networks and embedded devices. This is one of the most active IoT working groups.
- The IPv6 over Networks of Resource-constrained Nodes (6lo) WG will be meeting on Tuesday afternoon, and focuses on the work that facilitates IPv6 connectivity over constrained node networks.
- The IPv6 over the TSCH mode of IEEE 802.15.4e (6tisch) WG was chartered in 2014 to enable IPv6 for the Time-Slotted Channel Hopping (TSCH) mode that was recently added to IEEE 802.15.4 networks.
- The Home Networking (homenet) WG focuses on the evolving networking technology within and among relatively small “residential home” networks. For example, an obvious trend in home networking is the proliferation of networking technology in an increasingly broad range and number of devices.
- The IPv6 over Low Power Wide-Area Networks (lpwan) WG – typical LPWANs provide low-rate connectivity to vast numbers of battery-powered devices over distances that may span tens of miles, using license-exempt bands.
- The IP Wireless Access in Vehicular Environments (ipwave) WG has as its primary deliverable a specification for mechanisms to transmit IPv6 datagrams over IEEE 802.11-OCB mode.
- The Authentication and Authorization for Constrained Environments (ace) WG, as its name suggests, is concerned with authentication and authorization mechanisms in constrained environments, where network nodes are limited in CPU, memory and power. This is a critical issue for IoT.
- Routing for IoT is tackled by the Routing Over Low power and Lossy networks (roll) WG which focuses on routing protocols for constrained-node networks.
- In addition to the new protocols and other mechanisms developed by IETF working groups, IoT developers often benefit from additional guidance for efficient implementation techniques and other considerations. The Lightweight Implementation Guidance (lwig) WG is developing such documents.
I also want to (again) point you to “Manufacturer Usage Description Specification” (MUD) which was developed in the Operations and Management Area Working Group (opsawg). MUD holds significant promise, and I am pleased to see that it is gaining some serious traction: The Internet Engineering Steering Group (IESG) recently approved it as a proposed standard.
From the abstract: This memo specifies a component-based architecture for manufacturer usage descriptions (MUD). The goal of MUD is to provide a means for Things to signal to the network what sort of access and network functionality they require to properly function. The initial focus is on access control. Later work can delve into other aspects.
Eliot Lear, one of the MUD authors, has written a great article about it for the IETF Journal: Managing the Internet of Things – It’s All About Scaling.
As I have noted in previous IoT Rough Guides, MUD also plays a significant role in the project – Mitigating IoT-Based Automated Distributed Threats – being developed by the US National Institute of Standards and Technology (NIST) National Cybersecurity Center of Excellence (NCCoE).
If you have an interest in how the IoT is developing and being standardized in the IETF, I hope to see you in person or online at some of these meetings during IETF 102. (Note that If you know you will be unable to travel to the meeting and would like to participate remotely, you must register as a remote participant. There is currently no fee to be a remote participant at an IETF meeting but registration is required. If you do not want to register, you may opt to listen to the live audio stream of the sessions instead.)
It will be a busy week in Montreal, and whether you plan to be there or join remotely, there’s much to monitor. Read the full series of Rough Guide to IETF 102 posts, and follow us on the Internet Society blog, Twitter, or Facebook using #IETF102 to keep up with the latest news.