Network Working Group H. 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 Abstract 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. Status of This Memo 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 Notice 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 Tschofenig Expires August 18, 2014 [Page 1]
Internet-Draft ACE Overview February 2014 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. 1. Introduction [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: o Using an alternative communication channel, such as a USB stick, Ethernet cable o Human involvement by comparing hashed keys, entering passkeys, scanning QR codes o Second wireless connectivity (e.g., infrared) Tschofenig Expires August 18, 2014 [Page 2]
Internet-Draft ACE Overview February 2014 o Proximity-based information 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. Tschofenig Expires August 18, 2014 [Page 3]
Internet-Draft ACE Overview February 2014 +-----------+ | 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. Tschofenig Expires August 18, 2014 [Page 4]
Internet-Draft ACE Overview February 2014 +-----------+ +-----------+ | 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. 2. Three Party Security Frameworks 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. 2.1. Application Bridging for Federated Access Beyond Web Architecture 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]. Tschofenig Expires August 18, 2014 [Page 5]
Internet-Draft ACE Overview February 2014 +--------------+ | 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: o Re-uses existing protocols: RADIUS, GSS-API, EAP, EAP methods. Tschofenig Expires August 18, 2014 [Page 6]
Internet-Draft ACE Overview February 2014 o Security properties of the AAA / EAP framework well studied and large deployments of the AAA framework exist. o Products and open source code exists for EAP, EAP methods, RADIUS, and the GSS-API. The extensions needed for ABFAB also have been implemented but they are less mature compared to the EAP/AAA deployment. o Large range of EAP methods available offering all possible authentication and key exchange protocols for authentication between the client and the AAA server. These mechanisms have been deployed and are in widespread use today. While many EAP methods have been standardized only a few are in widespread use in non-IoT environments. However, there are many (open source) implementations available such that further experience concerning IoT suitability can be gathered. o IoT devices might use the AAA/EAP architecture for network access authentication (e.g., WLAN-based, IEEE 802.15.4-based ZigBee-IP deployments). o The AAA framework also supports authentication in a federated environment. o Authorization information is conveyed within RADIUS (and potentially in SAML assertions, as envisioned by ABFAB). Cons: o The initial authentication and authorization exchange requires real-time interaction between the AAA server and the service. o Deployments have so far used this architecture mainly for network access and for specific applications (VoIP) only. Experience with other applications, as ABFAB envisions, is rather limited. o ABFAB architecture uses layering of EAP within the GSS-API, which adds additional overhead. A binding for the transport of EAP payloads in CoAP, for example, does not exist. o No unified authorization policy language has been defined for the AAA/EAP architecture. Instead, RADIUS attributes carry information about access control decisions. Tschofenig Expires August 18, 2014 [Page 7]
Internet-Draft ACE Overview February 2014 2.2. Kerberos 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 Tschofenig Expires August 18, 2014 [Page 8]
Internet-Draft ACE Overview February 2014 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: o Re-uses existing protocol: Kerberos o Security properties well studied and large deployments exist. o Products and open source service exist. o Most parts of Kerberos, particularly the ticket concept, are designed with symmetric key cryptography, which improves performance. The Kerberos ticket is consequently fairly small and uses a binary encoding. o Kerberos also supports cross-realm authentication for scalable deployments. o Kerberos also specifies a UDP-based transport. o The message exchanges between the client and the service can be tailored to the need of the application. Cons: o Each ticket is only usable for a single service (intentionally). As such, new tickets have to be requested whenever the client wants to access a new service or when the ticket expired. o For the authentication between the client and the KDC a limited number of authentication protocols have been specified. o Kerberos uses ASN.1 for encoding of the ticket and various messages. This may increase implementation complexity but the binary encoding is more efficient than other encodings, like XML or JSON. o No standardized access control policy has been standardized for inclusion inside a ticket. Proprietary policies are, however, used in real-world deployments. o A CoAP binding for the KRB_PRIV and the KRB_SAFE message exchanges used to secure application data between the client and the service have not been defined. Tschofenig Expires August 18, 2014 [Page 9]
Internet-Draft ACE Overview February 2014 2.3. OAuth 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: Tschofenig Expires August 18, 2014 [Page 10]
Internet-Draft ACE Overview February 2014 o Re-uses existing protocols: OAuth Core [RFC6749], OAuth Bearer Token [RFC6750] OAuth MAC Token [I-D.ietf-oauth-v2-http-mac]/ HOTK [I-D.tschofenig-oauth-hotk], JWT [I-D.ietf-oauth-json-web-token]. o Large deployments in the Web environment exist, which use the OAuth Bearer Token. o Products and open source service exist. o OAuth is flexible with regard to the used cryptography. A standardized format for the access token has been described with the JSON Web Token (JWT). For security protection of the JWT various specifications from the JOSE working group are available. o The message exchanges between the client and the service can be tailored to the need of the application. Bindings are available for HTTPS and SASL [I-D.ietf-kitten-sasl-oauth]. o With regard to the offered security mechanism the interaction between the client and the resource server gives several choices: The OAuth Bearer Token requires a TLS exchange between the client and the resource server. The MAC Token specification is conceptually similar to Kerberos; a version based on asymmetric cryptography exists as well (see HOTK). Cons: o For an environment with more than one authorization server or where the authorization server is located in a different domain than the resource server the standardization work is still in progress. Efforts have mostly be done in Kantara with the User- Managed-Access (UMA) working group. o A binding for CoAP does not exist for the client to authorization server nor for the client to resource server. o The OAuth architecture does not standardize the authentication procedure of the resource owner to the authorization server itself. This is a common approach for the Web environment where a number of different authentication protocols are in use in the browser. As such, the protocol works with any authentication mechanism. 2.4. Certificate Model 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 Tschofenig Expires August 18, 2014 [Page 11]
Internet-Draft ACE Overview February 2014 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. Tschofenig Expires August 18, 2014 [Page 12]
Internet-Draft ACE Overview February 2014 Pros: o Re-uses existing protocols: DTLS (or application protocol), CMP/ CMC/PKCS#10/SCEP, specifications (certificate format - RFC 6818 [RFC6818]), and concepts (PKI). o Large deployments on the Web and with enterprise system exist. o Products and open source code exists. o The certificate format offers flexibility in terms of content. New extensions have been defined over time. o Certificates can be used with DTLS without any additional modifications. Certificates can also used with application security mechanisms. o Authorization information may be placed in an extension of a public key certificate or in a separate attribute certificate [RFC3281]. Earlier work on KeyNote [RFC2704]could be re-used as it provides a more flexible authorization policy language. o A single certificate can be used with a number of different services. o Various PKI management protocols have been defined and they offer some flexibility. The properties vary on the specific use cases. Cons: o The certificate format and the PKI management protocols use ASN.1. o No UDP or CoAP transport is defined for CMC/CMP/SCEP. For PKCS#10 no transport is defined at all. o The public key infrastructure only focuses on asymmetric cryptography. A separate body of work is available for provisioning symmetric keys (like one-time-keys), such as the Portable Symmetric Key Container (PSKC) [RFC6030] and Dynamic Symmetric Key Provisioning Protocol (DSKPP) ([RFC6063]). o Protocols for certificate enrollment are in use but many deployments use their own strategy for distributing certificates (typically long-lived) to their users. o Asymmetric cryptography is computationally more expensive than symmetric cryptography but offers additional security benefits. Tschofenig Expires August 18, 2014 [Page 13]
Internet-Draft ACE Overview February 2014 3. Conclusion 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 o a language for describing access control policies, o the encoding of these policies, and o the container for associating these policies with keying material. 4. Security Considerations This entire document is about security. 5. IANA Considerations This document does not require any actions by IANA. 6. Acknowledgements The author would like to thank Stefanie Gerdes for her review comments. 7. Informative References [I-D.ietf-abfab-arch] Howlett, J., Hartman, S., Tschofenig, H., Lear, E., and J. Schaad, "Application Bridging for Federated Access Beyond Web (ABFAB) Architecture", draft-ietf-abfab-arch-10 (work in progress), December 2013. [I-D.ietf-kitten-sasl-oauth] Mills, W., Showalter, T., and H. Tschofenig, "A set of SASL Mechanisms for OAuth", draft-ietf-kitten-sasl- oauth-12 (work in progress), December 2013. Tschofenig Expires August 18, 2014 [Page 14]
Internet-Draft ACE Overview February 2014 [I-D.ietf-lwig-terminology] Bormann, C., Ersue, M., and A. Keranen, "Terminology for Constrained Node Networks", draft-ietf-lwig-terminology-06 (work in progress), December 2013. [I-D.ietf-oauth-json-web-token] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", draft-ietf-oauth-json-web-token-15 (work in progress), January 2014. [I-D.ietf-oauth-v2-http-mac] Richer, J., Mills, W., Tschofenig, H., and P. Hunt, "OAuth 2.0 Message Authentication Code (MAC) Tokens", draft-ietf- oauth-v2-http-mac-05 (work in progress), January 2014. [I-D.nourse-scep] Pritikin, M., Nourse, A., and J. Vilhuber, "Simple Certificate Enrollment Protocol", draft-nourse-scep-23 (work in progress), September 2011. [I-D.seitz-ace-usecases] Seitz, L., Gerdes, S., and G. Selander, "ACE use cases", draft-seitz-ace-usecases-00 (work in progress), February 2014. [I-D.tschofenig-oauth-hotk] Bradley, J., Hunt, P., Nadalin, A., and H. Tschofenig, "The OAuth 2.0 Authorization Framework: Holder-of-the-Key Token Usage", draft-tschofenig-oauth-hotk-03 (work in progress), January 2014. [RFC2315] Kaliski, B., "PKCS #7: Cryptographic Message Syntax Version 1.5", RFC 2315, March 1998. [RFC2704] Blaze, M., Feigenbaum, J., Ioannidis, J., and A. Keromytis, "The KeyNote Trust-Management System Version 2", RFC 2704, September 1999. [RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification Request Syntax Specification Version 1.7", RFC 2986, November 2000. [RFC3281] Farrell, S. and R. Housley, "An Internet Attribute Certificate Profile for Authorization", RFC 3281, April 2002. Tschofenig Expires August 18, 2014 [Page 15]
Internet-Draft ACE Overview February 2014 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The Kerberos Network Authentication Service (V5)", RFC 4120, July 2005. [RFC4210] Adams, C., Farrell, S., Kause, T., and T. Mononen, "Internet X.509 Public Key Infrastructure Certificate Management Protocol (CMP)", RFC 4210, September 2005. [RFC5247] Aboba, B., Simon, D., and P. Eronen, "Extensible Authentication Protocol (EAP) Key Management Framework", RFC 5247, August 2008. [RFC5272] Schaad, J. and M. Myers, "Certificate Management over CMS (CMC)", RFC 5272, June 2008. [RFC5934] Housley, R., Ashmore, S., and C. Wallace, "Trust Anchor Management Protocol (TAMP)", RFC 5934, August 2010. [RFC6030] Hoyer, P., Pei, M., and S. Machani, "Portable Symmetric Key Container (PSKC)", RFC 6030, October 2010. [RFC6063] Doherty, A., Pei, M., Machani, S., and M. Nystrom, "Dynamic Symmetric Key Provisioning Protocol (DSKPP)", RFC 6063, December 2010. [RFC6749] Hardt, D., "The OAuth 2.0 Authorization Framework", RFC 6749, October 2012. [RFC6750] Jones, M. and D. Hardt, "The OAuth 2.0 Authorization Framework: Bearer Token Usage", RFC 6750, October 2012. [RFC6818] Yee, P., "Updates to the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 6818, January 2013. Author's Address Hannes Tschofenig ARM Ltd. 110 Fulbourn Rd Cambridge CB1 9NJ Great Britain Email: Hannes.tschofenig@gmx.net URI: http://www.tschofenig.priv.at Tschofenig Expires August 18, 2014 [Page 16]