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.
At a technical level, The Extensible Authentication Protocol (EAP) [RFC 3748] is used to provide authentication between one entity, such as a smart device, and its identity provider. Only two parties are involved in this exchange; this means that the smart device need not participate in any complicated public-key infrastructure even if it is authenticating against many cloud services. Instead, the device can delegate the process of authenticating the service and even deciding whether the device should be permitted to access the service to the identity provider. This has several advantages. A wide variety of revenue sharing models are enabled. Because device authentication is only with a single identity provider, phishing of device credentials can be avoided. Authorization and decisions about what personal information to release are made by the identity provider. The device owner can use a rich interface such as a website to configure authorization and privacy policy even if the device has no user interface. This model works well with pre-provisioning of device credentials.
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.
ABFAB is designed to make it easy to set up federations or consortia of identity providers and services. Traditionally with RADIUS, a mesh of connected RADIUS proxies are used. This has been very effective in the cellular provider and wireless hotspot deployment space. Proxies can assist in billing management and authorization decisions. Alternatively, RADIUS over TLS [draft-ietf-radext-radsec] can be used. In this model, a public-key infrastructure can be used between the identity and service. The identity provider and service may be in a position to handle revocation and to decide based on the contents of certificates what information should be released to comply with privacy policy.
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 (hartmans@painless-security.com)
Margaret Wasserman (mrw@painless-security.com)
Painless Security, LLC