Today, consumers have no way to centrally manage access to all their Web stuff and IOT devices are threatening to create a whole new silo of security problems. This is one of the reasons I’ve been participating in the Open InterConnect Consortium Security Task Group.
People can’t individually manage every IOT device in their house. So it seems likely that some kind of centralized management tools will be necessary. Last week, I proposed the use of OAuth2 profiles OpenID Connect and UMA as the “two legs” of IOT security. Since then, a discussion has been active on the feasibility of OAuth2 for IOT?
One challenge for this design is that OAuth2 relies on HTTPS for transport security. While many devices will be powerful enough to handle an HTTPS connection, some devices are too small. Says Justin Richer from Mitre, “Basically replacing HTTP with CoAP and TLS with DTLS, you get a lot of functional equivalence.” In fact this effort is already in progress at the IETF, and research projects are in progress to build this out in simulation. For more info see the following links:
- OAuth 2.0 Bearer Token Usage over the Constrained Application
- OAuth 2.0 Internet of Things (IoT) Client Credentials Grant
- Ace Working Group’s draft standard for Object Security for CoAP
- Another interesting CoAP / DTLS standard is OMA Lightweight M2M (LWM2M). View a cogent overview and background in these slides by Julien Vermillard and a video by Zach Shelby. Perhaps the authorizations in LWM2M could be mapped to UMA OAuth2 scopes?
Assuming the transport layer security gets solved, another sticking point is the idea of central control. Here is the case against central control paraphrased by one of my comrades:
If you buy a light switch and a light bulb, they need to magically work together. When we state this as almost impossible, they will accept that the user needs a smartphone for the initial setup but not that he needs some extra dedicated authorization server. (Nor do I think that running this in the cloud will be acceptable either.)
The idea of central control has already been embraced by Apple and ARM. Homekit is Apple’s “smart home hub, providing an overview of all your connected smart devices.” The mBed platform describes a central “mbed Server”, a Java application that includes “a Device Server [that] handles the connections from IoT devices.”
Let’s consider the use case against OAuth2: How could an IOT light bulb connect to an IOT light switch?
Lets say the light bulb publishes three APIs:
For central control, using the UMA profile of OAuth2, a client must present a valid RPT token from an Authorization Server to the light bulb. All the light bulb has to do is validate this token. This should be the default configuration for most IOT devices–they should quickly hook into the existing home security infrastructure with very little effort from IOT developers. There is no need for the light bulb to store or evaluate policies with this solution. I disagree that the cloud won’t be a likely place to manage your digital resources (what don’t we use Google for these days). The home router might also be a handy place to have your home policy decision point.
But what if there is no central UMA authorization server? Is there a need for an alternate method of local authorization? Yes! The light bulb is the resource server, and it can always have some backup policies, for example, a USB connection or button, could bypass UMA authorization.
For the light switch to make this call to the APIs, it would need a client credential. The light bulb itself could have a tiny OAuth2 chip that would provide the bare minimum server APIs for client discovery, client authentication, and dynamic client registration.
The light bulb can offer a few different ways for the light switch to “authenticate” depending on how fancy it is:
1) None (sometimes you’re on a trusted network)
2) API key / secret
3) JSON Web Key
In cases where the light bulb was not configured to use central authentication, it could check the access token against its cache of tokens issued to local clients.
OpenID Connect offers lots of features for client registration. For example, you could correlate client registrations with “request_uris.” (Think entityID if you are familiar with SAML). See the registration request section of the OpenID Connect Dynamic Client Registration Spec
Why write a new OAuth2 based client authentication protocol when we already have OpenID Connect? Connect has been shown to be usable by developers, was designed to make simple things simple, and scales to complex requirements. Wouldn’t it make sense to just create a mapping for a new transport layer? Won’t there be even more transport layers in the future? What about secure-Bluetooth, secure-NFC, or secure-ESP? Will we have to re-invent client registration every time there is a new secure transport layer?
If the Open Interconnect Consortium Core Framework TG decides to mandate support for CoAP, then it may not be possible to use OpenID Connect, UMA or any other existing security protocol developed for HTTP.
Says Eve Maler, VP Innovation & Emerging Technology at ForgeRock, “My suspicion has been that a CoAP binding of UMA would be an interesting and worthwhile project… it could be done through the UMA extensibility profiles now–basically replacing the HTTP parts of UMA with CoAP parts”
Nat Sakimura, Chairman of the OpenID Foundation, commented “binding to other transport protocols, definitely yes. That was our intention from the beginning. That’s why we abstracted it. Defining a binding to CoAP etc. would be a good starting point. In the ACE Working Group at the IETF, Hannes Tschofenig from ARM has already started the work.”
Feedback from John Bradly of Ping Identity, and also one of the authors of OpenID Connect, was interesting. He referenced the IETF work of GSSAPI and suggests that a binding there to OAuth2 might address the CoAP requirement.
@GluuFederation work has happened on bindings for GSSAPI to use connect\OAuth with non http resources. A OAuth binding that Connect can use
— John Bradley (@ve7jtb) November 24, 2014
Obviously we SHOULD NOT design IOT security for the lowest common denominator, but connect IOT into our current Web infrastructure, as show in this diagram.
Subscribe to Get News and Product Updates
our RSS Feed