ACE-OAuth – A new standard for lightweight authorization and access control

Introduction

The accelerating digital transformation comes with increased adoption of Internet of Things (IoT) technologies, connecting billions of devices and enabling new applications and services in industry and society. As the number of connected devices increases, so too does the attack surface, which calls for an improved security posture for protecting the vast amount of new digital assets, as we discussed in a previous blog post.

An important area in this context relates to authorization and access control, that is, how to control what operations are performed on a particular device and by whom.

Let us share an example to illustrate how a potentially large number of devices can be involved in a complex interaction that needs to be protected using a granular access control mechanism.

In a smart agriculture setting, a large-scale greenhouse area is equipped with a system of sensor devices and actuation devices. The sensors monitor air temperature and humidity, carbon dioxide concentration, light levels, temperature, humidity, and pH value of the soil. The actuators impact the same parameters by controlling various factors, for example, the position of windows and shades, the speed of fans, applied heating and light, as well as granular components of the irrigation system, to provide the right conditions for all parts of the greenhouses. A similar system may also be in place during the transportation of the crops to the food wholesaler or grocery store to ensure optimal conditions and thereby avoid unnecessary food waste.

The environmental conditions during the growth period are registered by the sensors and used to control the settings of the actuators. The information can also be used by potential customers to predict, for example, the expected quality of the food.

The state and operations of the actuators are critical for obtaining the right environmental conditions. For example, just a short period where conditions are too dry or too cold can cause considerable damage to the crops. Note that actuator operations can be impacted in several ways, for example, by directly accessing the actuator function, by changing the control levels, or by manipulating the values of environmental parameters causing the actuators to act on the wrong input data.

The information sent to and from actuators and sensors during the crop’s lifetime represents assets that may be used by different parties to assess and control different properties of food production. The information, therefore, needs to be appropriately protected against unauthorized access. What the right granularity of information is depends on the deployment, but to provide the specific information needed to impact the local environmental conditions requires a high density of actionable data points.

In this example, and many other IoT applications, the connected devices are small, battery operated, have limited capacity, and at the same time have an expected lifespan of many years. They often operate in constrained environments on networks with limited bit rates or throughput to save power.
Deploying authorization and access control in these kinds of systems raises several challenges, in particular:

1. A large variety of technologies are used in the different access networks, which complicates an end-to-end security solution covering all parts of the system.
2. Legacy security protocols often have a large footprint and may not be sufficiently power efficient to allow sustainable IoT deployments with long lifetimes.

This blog post is about a recent contribution to the area of Authentication and Authorization for Constrained Environments (ACE-OAuth) — or just ACE for short—a new security standard for lightweight authorization. ACE-OAuth is a framework and a set of protocols developed and standardized by the Internet Engineering Task Force (IETF) with the goal to ensure that only authorized users and devices can access resources and protect against unauthorized access.

ACE-OAuth provides a secure and scalable technology for access control in IoT deployments by specifically targeting constrained devices and networks and allowing a variety of underlying technologies, thereby addressing the two challenges outlined.

The ACE Authorization Framework uses OAuth 2.0

One of the key components of the ACE-OAuth framework is OAuth 2.0, the widely used web authorization protocol. OAuth 2.0 is applicable to a large variety of settings, for example, authorization in Service Based Architecture (SBA), see 5G Core Network SBA.

ACE-OAuth is built on the OAuth 2.0 authorization architecture where a client wants to access resources on a Resource Server (RS), and the RS enforces access policy decisions mediated by a trusted third party, the Authorization Server (AS).

While re-using OAuth 2.0, the ACE-OAuth framework makes certain adaptations and optimizations specifically designed for constrained environments. In ACE-OAuth, the client and the RS may individually or both be constrained devices, but the AS is not assumed to be constrained. In a common example the client is a mobile phone, the RS is an IoT device, such as a sensor or an actuator, and the AS is hosted in the cloud or at the edge. An example message flow is outlined in Figure 1.

1. The Client authenticates to the AS and requests an Access Token.
2. The AS decides on what access rights the Client shall have on the RS and responds to the Client with an Access Token containing this authorization information and credentials for authentication.
3. The Client authenticates to the RS and provisions the Access Token for validation.
4. The Client gains access to resources on the RS, according to authorization information in the Access Token.

Figure 1.A Client retrieves an Access Token from an Authorization Server and provisions the Access Token to a Resource Server to enable authorized access to resources.

The message flow in Figure 1 supports access control also for the cases when the RS has no connectivity to reach the AS, and there is only local connectivity between client and RS, such as Bluetooth Low Energy (BLE). Other message flows are also supported by ACE-OAuth, and the detailed processing is specified in the profiles of the ACE framework as discussed below.

Lightweight building blocks

The ACE framework provides a secure and scalable solution for authentication and authorization by combining OAuth 2.0 with a set of lightweight building blocks:

• ACE builds on the lightweight encoding of message content by utilizing the Concise Binary Object Representation (CBOR) for small overhead and efficient parsing in constrained devices.
• ACE also makes use of the lightweight and compact CBOR Web Token (CWT) format for carrying claims expressing information asserted about entities, for example access tokens with authentication and authorization information sent between different parties. CWT builds on JSON Web Token (JWT) but uses CBOR instead of JSON for encoding.
• CWTs are protected with the CBOR Object Signature and Encryption (COSE) which allows for secure transport. The server hosting the requested resources and receiving the access token CWT can verify the source and integrity of the CWT and retrieve a cryptographic key for use in authenticating the authorized client. This process is known as Proof-of-Possession (PoP) and the access tokens are called PoP tokens.

As in OAuth 2.0, the ACE-OAuth framework makes use of the representational state transfer (REST) paradigm where access requests are made using methods such as GET, PUT, and POST to resources defined by a uniform resource identifier (URI). The ACE framework supports different transport types and defines extensions for OAuth 2.0 over the lightweight RESTful Constrained Application Protocol (CoAP). The use of CoAP also provides reliability, thereby enabling support for a wide variety of underlying connectivity. Operations on physical devices can thus be mediated through exchanges of low overhead CoAP messages, and ACE provides the authorization framework which provisions the necessary authorization information to enforce that only policy compliant operations by authorized clients take place.

Profiles for ACE using CoAP with TLS, DTLS or OSCORE

For each choice of transfer and communication security protocols between the nodes in the architecture, corresponding profiles can be defined for the ACE framework. The first two specified profiles of the ACE framework targeting constrained networks are CoAP-DTLS and CoAP-OSCORE.

Datagram Transport Layer Security (DTLS) is based on the Transport Layer Security (TLS) protocol and is designed to work with the User Datagram Protocol (UDP). DTLS is used in the ACE framework to secure the transport of CoAP communication between the client and resource server or authorization server as specified in the CoAP-DTLS profile (RFC 9202). The same profile also extends to TLS based security and TCP transport as described in a recent standard (RFC 9430). The PoP token contains the cryptographic key of the authorized client and enables the resource server to establish secure CoAP communication over DTLS or TLS through which authorized access to resources is enforced. Both pre-shared secret keys and public keys of clients may be used for authentication with DTLS or TLS.

Another ACE framework profile is CoAP-OSCORE (RFC 9203) which describes the use of Object Security for Constrained RESTful Environments (OSCORE) to provide secure CoAP communication between the client and resource server or authorization server. OSCORE is a lightweight security protocol suitable for devices with limited storage and processing capabilities, which reuses CoAP functionality for low footprint and small message size. OSCORE does not depend on the underlying transport (for example, UDP, TCP, or even IP), provides end-to-end security, and works wherever CoAP works, especially in the presence of proxies. The latter is important, for example, in the common case that a device is temporarily offline for saving power. More details about OSCORE can be found in our previous blog post.

Applications and Related Activities

Additional profile specifications are being set out by the IETF to apply the ACE framework to other transport and security protocols.

For the CoAP-OSCORE profile, additional profiles with different transport types are not needed since OSCORE is independent of transport. But for the important case of keying OSCORE with a Diffie-Hellman key exchange, another ACE profile is defined, which makes use of the lightweight authenticated key exchange protocol Ephemeral Diffie-Hellman over COSE (EDHOC)—a security handshake protocol designed for good performance in constrained environments thanks to low overhead and low footprint.

The ACE-OAuth framework has been included in other standards such as 3GPP Service Enabler Architecture Layer (SEAL). 3GPP SEAL provides enablers for vertical applications over 3GPP systems such as smart manufacturing, smart agriculture, and many others. The adoption of CoAP in 3GPP led to the use of ACE-OAuth and the CoAP-OSCORE profile to ensure authorized access and secure end-to-end signaling between SEAL clients and servers.

ACE-OAuth is evaluated in Proof-of-Concept implementations by industrial partners.

Another application area for the ACE-OAuth framework is for authorization of group interactions. Applications used for managing physical sites such as facility management, industrial control, and so on, can operate more efficiently with the help of group operations such as multicast CoAP addressing multiple, often constrained devices with common tasks. These services, even more than in unicast communication, call for the need to protect communication and enforce access policies, and ACE-OAuth provides several components to achieve these objectives as will be detailed in an upcoming blog post.

Summary

ACE-OAuth (RFC 9200) is a new IETF standard for lightweight authorization of data produced or consumed by a sensor or actuator device, mediated by a trusted third party issuing access tokens that are easily handled by constrained IoT devices. Development of additional features is ongoing by the IETF but it has already been well received both in industry and other standardization such as 3GPP. The framework builds on the OAuth 2.0 architecture and lightweight building blocks including CBOR for encoding, COSE for basic security services, CBOR Web Tokens for access information, and the use of CoAP on top of the underlying transport. Two profiles of the ACE framework have been standardized so far, one for CoAP over TLS or DTLS (RFC 9202, RFC 9430) and one for CoAP with OSCORE (RFC 9203), and other profiles are in progress.