Arm’s Mbed Cloud architecture is an excellent fit for connecting IoT devices to a cloud-based infrastructure or to on-premise servers. The use of lightweight communication protocols even makes it suitable for constrained devices that are connected over low power wide area networks (LPWANs). Mbed Cloud implements the LwM2M v1.0 protocol where the LwM2M client (i.e., Mbed Cloud Client) resides inside the IoT device and the LwM2M server (i.e., Mbed Cloud) is the unconstrained server infrastructure. This is a typical communication pattern in an industrial setting.
However, the current specification for LwM2M is not a good fit when the server itself is a constrained IoT device and when user authentication together with fine grained dynamic access control is demanded. As an example, consider a technician who has been sub-contracted to maintain some elevators in a building. Clearly, access control procedures will be needed to avoid unrestricted access to the building infrastructure and elevators. The technician is only allowed to gain access to the elevators when ordered to do so. The elevator itself may not be connected to cloud infrastructure (all the time, at least).
Complementing the work on LwM2M, the IETF ACE working group tackles use cases that require user identity management, user authentication and fine-grained access control. The standardized solution is referred to as OAuth-ACE since it represents a profile of the widely deployed OAuth technology.
To map the scenario described above to OAuth-ACE requires the technician to use a smartphone or tablet to log into the identity management system with user authentication (unless already logged in for other purposes), and then to request access to the building’s elevators. The building owner needs to approve the access request (unless done in advance).
Once consent has been granted, the app on the smart phone (or tablet) obtains an access token for use with the elevator from the authorization server. An authorization server is responsible for issuing access tokens, that will typically be verified by the resource server, in this case, the elevator. Policies define access token permissions, in terms of who can have access, the activities they can perform, as well as the devices that can be accessed using that token. These policies can be created on-the-fly, as part of the consent process, or may be pre-populated. The most suitable approach for a given scenario often depends on the preferences of those deploying the service.
Tokens are at the core of OAuth, and require a more detailed discussion: Access tokens are structures that encode permissions granted to a party to access a specific resource. They have to be cryptographically protected to prevent tampering. OAuth does not mandate a specific token encoding but for developer convenience, a JSON-based token format, called the JSON Web Token (JWT), has been standardized with RFC 7519 [1]. For the use in IoT environments, the Concise Binary Object Representation (CBOR) Web Token (CWT) [2] provides a more efficient encoding.
Two types of tokens are defined, namely bearer tokens and proof-of-possession (PoP) tokens. PoP tokens link a token to a key and thereby behave like a Kerberos ticket (when a PoP token is linked to a symmetric key) or a certificate (when a PoP token is linked to an asymmetric key). The presenter of a PoP token needs to demonstrate the possession of the key. This increases security because if the token gets leaked, an adversary also needs to steal the corresponding keys to be able to compromise the system. Bearer tokens are not linked to a key and therefore have to be handled with care. PoP token functionality has been added to JWTs in RFC 7800 [3] and to CWTs in [4].
The access token is used in all future interactions with the elevator unless it gets revoked or expires. To avoid keeping a human in the loop every time a new access token is requested (since these access tokens may be short-lived), a refresh token is used. It can be used by the OAuth client to request new access tokens (with the same or less permissions) without human involvement. Unlike access tokens, refresh tokens are purely used between the OAuth client and the authorization server.
When receiving a request with an access token, an elevator needs to verify the request before executing the requested action. The access token encodes the permissions in its content to help the device whether to perform the action.
Figure 1 shows how the architecture of OAuth-ACE aligns with the OMA LwM2M protocol [5]. In turn, both of these architectures align well with smart phone apps used today, allow cross domain identity management, flexible use of user authentication technologies, and offer fine-grained access control techniques.
Figure 1: OAuth-ACE Architecture with LwM2M Integration
To support constrained IoT devices, the IETF ACE working group has introduced the use of CoAP (either instead of, or in addition to the use of HTTP, as used in classical OAuth) and developed CWTs. To improve security over classical OAuth, PoP tokens are used instead of bearer tokens.
More details about the OAuth-ACE architecture can be found in [6].
OAuth-ACE complements the LwM2M-based device management solution since the elevator in our scenario still needs to be managed, provisioned with credentials and may also report events to the backend infrastructure.
Mbed Secure Device Access, a new feature of Mbed Cloud, makes it easy for enterprises, system integrators and device OEM to put OAuth-ACE into use. A preview version of Mbed Secure Device Access is available to early Mbed Cloud partners now. Stay tuned for more news about how Mbed Cloud uses OAuth-ACE technology to improve operational security of IoT networks.