| Network Working Group | H.T. Tschofenig |
| Internet-Draft | ARM Ltd. |
| Intended status: Best Current Practice | February 14, 2014 |
| Expires: August 18, 2014 |
Authentication and Authorization for Constrained Environments (ACE): Overview of Existing Security Protocols
draft-tschofenig-ace-overview-00.txt
This document surveys existing three party authentication and authorization protocols for use with Internet of Things use cases. The discussed protocol frameworks are Kerberos, OAuth, ABFAB, and the certificate model. The aim is to understand whether any of the available standardized security protocols are re-usable for constrained environments. A future version of this document will provide a more detailed analysis against the requirements.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 18, 2014.
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
[I-D.seitz-ace-usecases] introduces a number of use cases that require device-to-device authentication whereby both devices may be constrained. [I-D.ietf-lwig-terminology] discusses the different types of constraints of these devices.
This document aims to raise the high-level question about the possible re-use of existing three party authentication and key exchange protocols for use in IoT environments. This version of the document does not aim to map requirements derived from the use cases against these protocols. Such a detailed analysis is premature at this point when use case descriptions are still in flux.
The starting assumption for the architectures in this document is that a device (a client) wants to access some resource (referred as service in this document). It unfortunately does not have any relationship with the server offering that service. Figure 1 shows the scenario graphically.
+-----------+ no prior +-----------+
| Client | relationship | Service |
| | | |
+-----------+ +-----------+
Figure 1: Two Party Scenario.
Imagine that the client is a light-switch and the service is a light-bulb.
Today, companies solve this case by using a pairing protocol (at the link layer typically) where the two devices execute a special imprinting/pairing protocol to establish an initial key by using out-of-band (OOB) channel. This OOB channel can come in many forms:
The pairing is a suitable approach where wireless communication replaces a wired communication technology previously used. For example, a headset connected to a music player using a wired connection is replaced with the wireless version. Not all use cases do, however, allow users to pair their device with other devices upfront. Consider an enterprise with electronic door locks. It is hard to imagine an employee who has to pair their digital key with every door in the building first before they use the system.
Requiring every device to pair with every other device upfront is often inconvenient or not feasible. Hence, this document does not explore pairing solutions further. To offer an improved user experience with better scalability properties a device might either share credentials with some trusted third party. There are various ways how credentials can be shared with these trusted third parties. For example, credentials may be provisioned during the manufacturing process or devices may have been paired with the trusted third party (in case the trusted third party is local to the user). In fact, today is it very common for IoT devices to have at least credentials pre-provisioned for use with the vendor / manufacturer of the device to allow software updates to be provided securely.
Thus, we move to a model where the device (client) shares some credentials with a trusted third party. This trusted third party does not need to be a server on the Internet; ideally it could also be operated locally within someones' home, within an enterprise, or within a factory.
This three party architecture is shown in Figure 2.
+-----------+
| Trusted |
+--------------------------->|Third Party|
| Key +-----------+
| ^
| |
| |
| | Key
| |
| |
| |
v v
+-----------+ no prior +-----+-----+
| | relationship | |
| Client | <..................>| Service |
+-----------+ +-----------+
Figure 2: Three Party Scenario.
This three party architecture and messaging pattern has been explored with prior IETF work and this document lists the most relevant efforts (on a high level).
The goal of the communication exchange is that the client has been authorized to access the service, and is able to secure the exchange of information. The client and the service may, optionally, possess keying material for future use of the service with the benefit of better performance for future interactions.
Note: This document does not aim to cover the use cases in their entirety. First, we assume that the security protocol interaction for link layer authentication is outside the scope. The focus of this document is on the application layer interactions when accessing services. Second, this document does not survey access control policy languages and mechanisms for managing these access control policies. These policies are important since many of the systems described below only provide an answer to the question 'Who is the holder of this key?' and standards for answering the question 'Can this key be used for this purpose?' (authorization) are often realized in a proprietary way.
While Figure 1 shows three parties the protocols described in Section 2 have been generalized to four or even multi-party scenario. The result is shown in Figure 2.
+-----------+ +-----------+
| Trusted | Agreement w/key | Trusted |
| Third |<-------------------->| Third |
| Party A | | Party B |
+-----------+ +-----------+
^ ^
| |
| Key | Key
| |
| |
| |
| |
v v
+-----------+ no prior +-----+-----+
| | relationship | |
| Client | <..................>| Service |
+-----------+ +-----------+
Figure 3: Generalization of Three Party Scenario.
This section introduces four authentication and authorization frameworks standardized in the IETF. The description is intentionally kept at a high level and a reader is encouraged to consult the referenced documents for details and various options these protocols offer. The terminology with each of these protocols is lightly different and appropriate mappings have been applied.
To demonstrate the level of maturity of these frameworks availability of products, source code, and deployment experience is mentioned for each of these frameworks. Note, however, that this experience does not imply suitability for use with the IoT environment.
This section describes the Application Bridging for Federated Access Beyond Web architecture [I-D.ietf-abfab-arch], which builds on the Authentication, Authorization and Accounting (AAA) framework. The AAA framework re-uses the Extensible Authentication Protocol (EAP) [RFC5247] and EAP methods for the authentication protocol capabilities. A detailed description of the AAA keying framework can be found in [RFC5247].
+--------------+
| Identity |
| Provider |
| (IdP) |
+-^----------^-+
* EAP o RADIUS
* o
* o
+-------------+ +-v----------v--+
| | | |
| Client | EAP/EAP Method | Relying |
| |<****************>| Party |
| | GSS-API | |
| |<---------------->| |
| | Application | |
| | Data | |
| |<================>| |
+-------------+ +---------------+
Terminology Mapping:
- The term 'Relying Party' corresponds to the 'service'.
- The term 'Identity Provider' corresponds to the
'trusted third party'.
Figure 4: ABFAB Architecture.
With the message exchange shown in Figure 4 the client wants to obtain access to a service and starts interacting with that service. Since no prior relationship between the client and the service is assumed the EAP message exchanges is relayed by the service and the EAP server component of the IdP. Between the client and the service these EAP payloads are encapsulated within the GSS-API. After a successful authentication and authorization session keys are delivered from the IdP to the service and can then be used to secure the application layer data exchange between the client and the service.
While the use of EAP and the AAA architecture has mostly found use for network access authentication the work on ABFAB applies this architecture to application layer services.
Pros:
Cons:
Kerberos [RFC4120] is authentication system for distributed environments that has enjoyed deployment for more than three decades. The security properties have been extensively studied and various implementations exist.
+----------------+
| Authentication |
| Server (AS) |
+----------------+
^ /
Request / /
Ticket / /
/ /Ticket
/ /{SK}C-KDC
/ /
/ /
/ /
/ v
+-----------+ +-----------+
| | Ticket + Authenticator | |
| Client |---------------------------->| Server |
| |<===========================>| |
+-----------+ Application Data +-----------+
Terminology Mapping:
- The term AS corresponds to the 'trusted third party.'
- The term Server corresponds to the 'service'.
Figure 5: Kerberos.
The Kerberos exchange shown in Figure 5 illustrates a client who wants to get access to a server. It first has to interact with the Authentication Server (AS) to request a ticket. In response, the AS provides a ticket, which is a data structure encrypted with a key known only between the server and the AS. This ticket includes information about the client, a session key (SK) for later use, and various other security relevant information elements. The client also obtains the session key encrypted with a key it shares with the AS.
When a service access is required then the client interacts with the server and presents the ticket along with an Authenticator. The Authenticator demonstrates that the client was able to decrypt the session key with the key it shares with the AS and that it was able to apply this key to compute a keyed message digest over several fields, including a time-stamp, when accessing the service. The time-stamp avoids replay attacks.
Pros:
Cons:
The OAuth protocol is a recent development for the Web, which re-uses the Kerberos interaction pattern with influences from the Web / mobile app space. It initially aimed to solve the problem of delegated access to protected resources where websites asked users to share their long-term password. Over time OAuth has been used in other use cases that require delegated access.
+-------------+
|Authorization|
|Server (AS) |
+-------------+
^ /
Request / /
Access / /
Token / /Access Token
/ /
/ /
/ /
/ /
O / v
/|\ +-----------+ +-----------+
| -----> | | Access Token | Resource |
/ \ <----- | Client |----------------->| Server |
Resource | |<================>| (RS) |
Owner +-----------+ Application Data +-----------+
Terminology Mapping:
- The term AS corresponds to the 'trusted third party'.
- The term RS corresponds to the 'service'.
Figure 6: Simplified OAuth Architecture.
Figure 6 shows the high-level OAuth message exchange. The canonical OAuth example allows a web user (resource owner) to grant a printing service (client) access to her private photos stored at a photo sharing service (resource server), without sharing her username and password. Instead, she authenticates directly with the authorization server which issues the printing service delegation-specific credentials.
Pros:
Cons:
Prior work on the Public Key Infrastructure, certificate formats, certificate extensions, and various certificate management protocols can be re-used in the IoT context. With respect to the use cases described in [I-D.seitz-ace-usecases] certificates may be short-lived and might need to contain attributes (which may be used for making access control decisions) rather than purely relying on the identity of users and their devices.
For the purpose of dynamic provisioning short-lived certificates, this document envisions to re-use a subset of the functionality offered by protocols like the Certificate Management over CMS (CMC) [RFC5272], the Certificate Management Protocol (CMP) [RFC4210], the Simple Certificate Enrollment Protocol [I-D.nourse-scep], Certification Request Syntax Standard - PKCS#10 [RFC2315] (with TLS or with PKCS#7 [RFC2986] ). While these protocols offer slightly different features, on a high-level the all fulfill the same function. Note that the management of trust anchors may be provided by a different protocol, such as Trust Anchor Management Protocol (TAMP) [RFC5934].
Of course, certificates do not necessarily need to be short-lived and could even be provisioned during the manufacturing process and never changed during the lifetime of the device. The drawback of such an approach is, however, that mechanisms for certificate revocation have to be provided. Furthermore, privacy concerns might be arise since the same client certificate content will be shown to every service rather than information that is only relevant for a specific purpose.
+-------------+
|Certification|
| Authority |
+-------------+
^ /
Request / /
(Short) / /
Lived / /(Short) Lived
Cert / / Certificate
/ /
/ /
/ /
/ v
+-----------+ +-----------+
| | DTLS with certificate | |
| | or app layer msg w/cert | |
| Client |---------------------------->| Service |
| |<===========================>| |
+-----------+ Application Data +-----------+
Figure 7: Certificate Model.
Pros:
Cons:
Several existing protocols can be used to meet the use cases outlined in [I-D.seitz-ace-usecases]. Each technology presented here offers a number of possibilities for profiling to make them work on for constrained devices. Despite the range of available security protocols, the use cases suggest that there is a need to profile and to extend those in order to make them fit for the constrained environment.
The right choice of authentication and authorization protocol will heavily depend on the envisioned usage environment.
It is, however, also worth noting that several aspects that are not discussed in this document although they appear as requirements in the use case document, namely
This entire document is about security.
This document does not require any actions by IANA.
The author would like to thank Stefanie Gerdes for her review comments.