Moving from Internet of Threats to a trusted Internet of Things

Written by Ludwig Seitz, OT Security Specialist @ Combitech

The Internet Engineering Task Force (IETF) was founded in 1986 by the US government and has acted as an independent non-profit standardization organization since 1993. Without the IETF, the Internet as you know it today would not exist. Think of Internet without HTTP, TCP, UDP, TLS, ARP, DNS and many more. All produced and maintained by the IETF.

The IETF produces standards drafts, which show work in progress on a standard, freely accessible through the IETF website (no paywall, no registration requirement). When a standard is deemed ready, it is published as a “Request For Comments” (RFC), which is arguably a bit confusing choice, since at this point most comments have been addressed. RFCs can be found here (freely accessible).

The IETF has a working group called ACE (for Authentication and Authorization for Constrained Environments), which (oversimplified) works on IoT security (don’t tell my co-authors I put it that way or I’m never going to hear the end of it).

It is in this group I have had the honor and pleasure to contribute, on an access control standard for constrained devices (i.e., with little memory, low-power CPU’s, lossy network connections and powered by batteries). This standard has now been published as RFCs 9200-9205. In short terms, this is an adaptation of the well-known OAuth 2.0 standard to the specific constraints of IoT.

In the OAuth flow (oversimplified), a Client (e.g. your email client) wants to access some function at a Resource Server (e.g. your exchange server), and to get the permission to do so, it contacts the Authorization Server to obtain an Access Token (1). The Authorization Server authenticates the client and checks that the Resource Owner authorizes the access the client is asking for (2) and if that checks out issues the Access Token (3). The client can then request access at the Resource Server, presenting the Access Token (4) and thus obtain access.

The advantage of this design is that it offloads the access control decision making to a third party (the Authorization Server), meaning that you don’t have to implement complex access control logic on the Resource Server. The ACE standards make use of this pattern, since the Resource Server in this case typically is a constrained IoT device and saving complexity on that end is very beneficial.

The complete ACE design is split into a generic Framework (RFC 9200) and two Profiles (RFC9202, RFC9203) adapting the framework to different transport and communication security protocols (CoAP over DTLS, CoAP over OSCORE, MQTT over TLS).

Take the following IoT-specific example of an ACE implementation - a smart lock on a remotely located electrical substation. The lock has a limited power source, and no network to ask a centralized server for access control decisions. Furthermore, programming all access permissions into a great number of such locks would be very time consuming and scale very poorly as permissions change over time.

In this scenario a maintenance technician with a mobile device comes to the substation to perform hands-on work and needs to open the lock (which is the Resource Server in this scenario). To efficiently solve this, a mobile device (acting as the Client) can communicate with the authorization server to retrieve the necessary permissions in form of an access token, and then use a short-range wireless connection to transmit the token to the lock.

Another example from building automation: consider the heating, ventilation, and air conditioning systems (HVAC) as well as lighting that are controlled through a central Building Management System (BMS) but can be overridden through wall panels in the individual rooms.

Here the HVAC elements and the lights (the Resource Servers) need to know from which panels (the Clients) to accept commands. The same message flow can be use here to enforce authorization and thus allow for both central and decentralized control of the elements.

With the help of ACE, implementers can now add fine-grained access control to the APIs their IoT devices expose, without overloading limited processing and network resources at these device’s disposal.

This is a small but important step in the shift from the current Internet of Threats to a trusted Internet of Things that perform important functions reliably and securely.