Many smart devices deployments involve multiple organizations that do not directly share security infrastructure. For example, in smart power deployments, devices including appliances and infrastructure such as electric car chargers will wish to connect to an energy management system. The energy management system is provided by a utility company in some deployments. The utility company may wish to grant access only to authorized devices; for example, a consortium of utility companies and device manufacturers may certify devices to connect to power networks.
In another example, consumer devices may be used to access cloud services. For example, a camera could be bound to a photo processing site. Authentication and authorization for uploading pictures or ordering prints is required. Sensors could be used to provide data to services run by organizations other than the sensor manufacturer. Authorization and authentication can become very tricky when sensors have no user interface. Cellular devices may want to access services provided by a third party regardless of whether the cellular network or wi-fi is used. This becomes difficult when authorization and billing is coordinated by the cellular provider.
The ABFAB working group of the IETF is working to extend authentication and authorization technology that is already very successful at handling network access deployments for application layer access management [draft-ietf-abfab-arch]. The ABFAB technology focuses on federated access management. A set of one or more organizations provide services that are accessed by entities from one or more identity providers.
RADIUS [RFC 2865] provides authentication and authorization between the identity provider and the service. The identity provider can disclose information about the device or device owner as consistent with privacy requirements. The service can disclose information about itself and the intended service. The credentials used between the identity provider and service are independent of the credentials used between the identity provider and device. As new relationships with services are established or as security associations are updated, no changes are required on devices. Services do not learn device-specific security information. If a device is lost and replaced or compromised, services need not be updated. If a service is compromised, devices need not be re-credentialed, although privacy sensitive information held by the service may still be exposed.
Ongoing work not currently within ABFAB's scope [draft-mrw-abfab-multihop-fed] proposes to extend the RADSEC model to provide for secure dynamic discovery of identity providers appropriate to a given service along with policy information. In this model, a distributed database of identity providers for a given Community of Interest is built. Intermediate nodes can enforce policy surrounding naming, privacy and other issues. However key exchange is end-to-end using a model similar to how SIP and DTLS are integrated: an integrity protected channel is used to run a key agreement protocol. The integrity protected channel permits intermediates. However, assuming the intermediates are trusted not to mount a man-in-the-middle attack, the key is only known by the identity provider and service.
Today, the ABFAB mechanism [draft-ietf-abfab-gss-eap] can work with most IETF protocols including HTTP and XMPP. In the future, this model could be extended to any additional IETF protocols needed by smart devices that do not support the existing mechanism.
ABFAB provides a rich set of facilities for integrating attributes about authenticated identities into an application. Facilities are also provided to allow infrastructure supporting a service or identity provider to provide and enforce policy.
Sam Hartman (email@example.com)
Margaret Wasserman (firstname.lastname@example.org)
Painless Security, LLC