Identity for IoT: An Authentication Framework for the IoT

transcript

AN AUTHENTICATION FRAMEWORK FOR THE IOT

John Bradley

Premise

•  The full promise of the Internet of Things (IoT) can only be realized if the many and varied interactions between users, things, cloud services and applications can be authenticated. •  User delegated consent will be necessary for any scenario

where potentially privacy sensitive data is collected and transferred (wearables, home automation, health, etc). •  OAuth 2.0 and OpenID Connect 1.0 are two authentication

and authorization standards that promise to serve as important tools for the IoT’s authentication and authorization requirements

Who are the actors

• Things/devices

• Users

• Applications

• Clouds

• Gateways

Who are the actors

• Things/devices

• Users

• Applications

• Clouds

• Gateways

All of which need to be authenticated

Authentication & Authorization Model

•  IoT Actors authenticate by presenting security tokens on their calls/messages to each other

•  Tokens represent relationship between the relevant user and the calling actor (and any consents/permissions associated with that relationship

•  Upon receiving a message, an actor validates the token to verify the request is consistent with the relationship/permissions

•  If consent is removed, token is revoked, and access disabled

•  OAuth 2.0 & OpenID Connect 1.0 are two authentication & authorization frameworks that enable this model

OAuth 2.0

•  OAuth 2.0 is an IETF standard authentication & authorization framework for securing application access to RESTful APIs

•  OAuth allows a Client (an application that desires information) to send an API query to a Resource Server (RS), the application hosting the desired information, such that the RS can authenticate that the message was indeed sent by the Client.

•  The Client authenticates to the RS through the inclusion of an access token on its API call—a token previously provided to the Client by an Authorization Server (AS).

•  In those scenarios that the API in question protects access to a User’s identity attributes, it may be the case that the access token will only be issued by the AS after the User has explicitly given consent to the Client accessing those attributes.

OpenID Connect 1.0

•  OpenID Connect 1.0 is an OIDF standard that profiles and extends OAuth 2.0 to add an identity layer—creating a single framework that promises to secure APIs, mobile native applications and browser applications in a single, cohesive architecture.

•  OpenID Connect adds two notable identity constructs to OAuth’s token issuance model.

–  An identity token—the delivery of which, from one party to another, can enable a federated SSO user experience for a user.

–  A standardized identity attribute API—at which a client can retrieve the desired identity attributes for a given user.

•  If your use case requires something more than authentication and authorization of API calls, Connect’s features that go beyond OAuth become relevant.

Representative IoT architecture

• Fitbit makes Aria smart scale

• Scale syncs through home Wifi to Fitbit cloud for display & analysis through web & native applications

• 3rd party services can access weight data to provide additional insight

Architecture requirements

• User weight data is personal and must be protected against compromise

• Additionally, weight data must only be shared by Fitbit when consistent with user policy

Architecture

FitBit Proprietary

3rd party services

REST API REST API

Architecture

FitBit Proprietary

3rd party services

REST API REST API

Lets examine how OAuth & Connect can apply here

Cloud to cloud

•  TrendWeight offers additional insight & analysis of weight data •  Pulls scale data from Fitbit cloud

REST endpoints •  TrendWeight should use OAuth to

authenticate their API calls as being on behalf of particular user •  Because user is involved in token

issuance, privacy enabling model

Cloud to Cloud

Login & consent

Weight data

Revocation of authorization

User can remove permissions assigned 3rd parties

Native Application

•  Users can view their weight data & trends from ioS & Android native applications •  Native applications pull data from

Fitbit cloud REST endpoints •  Native applications should use

OAuth to authenticate their API calls as being on behalf of particular user

Device to gateway

•  Devices communicate with each other and the gateway via the local network— sharing data, sending control messages, etc. •  These local interactions may not use HTTP, but instead a

application protocol more optimized to the constraints (CPU size, battery, etc.) of devices. •  Such application protocols include XMPP, MQTT and CoAP. • Work has begun in exploring how to bind OAuth & Connect to

such IoT optimized protocols, e.g. ACE effort in IETF

Conclusion

• Authentication & authorization of actors is fundamental to IoT security

• Mechanisms must be secure, scalable and privacy respecting

• OAuth & Connect promise to provide important pieces of authn & authz framework for IoT

Identity for IoT: An Authentication Framework for the IoT

Technology