ACE Working Group S. Gerdes Internet-Draft Universitaet Bremen TZI Intended status: Informational May 30, 2014 Expires: December 1, 2014 Actors in the ACE Architecture draft-gerdes-ace-actors-00 Abstract Constrained nodes are small devices which are limited in terms of processing power, memory, non-volatile storage and transmission capacity. Due to these constraints, commonly used security protocols are not easily applicable. Nevertheless, an authentication and authorization solution is needed to ensure the security of these devices. This document defines actors in the security architecture for authentication and authorization, analyzes the relationships between them, and describes their respective tasks and characteristics. This knowledge will then be used to derive requirements for the communication between the actors. 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 December 1, 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 Gerdes Expires December 1, 2014 [Page 1] Internet-Draft ace-actors May 2014 (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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3 3. Actors . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Constrained Level Actors . . . . . . . . . . . . . . . . 4 3.2. Principal Level Actors . . . . . . . . . . . . . . . . . 5 3.3. Less-Constrained Level Actors . . . . . . . . . . . . . . 5 4. Protocol Requirements . . . . . . . . . . . . . . . . . . . . 6 4.1. Constrained Level Protocols . . . . . . . . . . . . . . . 6 4.1.1. Cross Level Support Protocols . . . . . . . . . . . . 7 4.2. Less-Constrained Level Protocols . . . . . . . . . . . . 7 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 8.1. Normative References . . . . . . . . . . . . . . . . . . 7 8.2. Informative References . . . . . . . . . . . . . . . . . 8 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 1. Introduction Constrained nodes are small devices with limited abilities which in many cases are made to fulfill a single simple task. They have limited system resources such as processing power, memory, non- volatile storage and transmission capacity and additionally in most cases do not have user interfaces and displays. Due to these constraints, commonly used security protocols are not always easily applicable. Constrained nodes are expected to be integrated in all aspects of every day live and thus will be trusted with a lot of personal data. Without appropriate security mechanisms attackers might gain control over things relevant to our lives. Authentication and authorization mechanisms are therefore prerequisites for a secure Internet of Things. Gerdes Expires December 1, 2014 [Page 2] Internet-Draft ace-actors May 2014 The Authentication and Authorization in Constrained Environments (ACE) Working Group aims at defining a solution for authenticated and authorized access to resources. To achieve this, it is necessary to develop a deep understanding about the problem to be solved. An essential part of this is to identify the various "players" in the scenario: What are the relevent actors in the archicture and which tasks do they fulfill? How can the relationships between the actors be defined? This document defines actors, their relationships and resulting security requirements for authentication and authorization in constrained environments. 1.1. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. This document uses the following terminology: Resource: an item of interest. It might contain sensor or actuator values or other information. The author had resources in the sense of RFC2616 [RFC2616] in mind, but for the considerations in this document the kind of representation of the item is not relevant. Constrained node: a constrained device in the sense of [RFC7228]. 2. Problem Statement The problem the ACE Working Group aims to solve can be summarized as follows: o A Client (C) wants to access a Resource (R) on a Resource Server (RS). o A priori, C and RS do not know each other and have no trust relationship. o C and / or RS are constrained. ------- requests resource -------- | C | ------------------> | RS | ------- -------- Gerdes Expires December 1, 2014 [Page 3] Internet-Draft ace-actors May 2014 There are some security requirements for this scenario including one or more of: o No unauthorized entity must be able to access (or otherwise gain knowledge of) R. o C must access the proper R. Therefore, RS needs to know if C is allowed to access R and if that is the case needs to make sure that it provides the resource only to C. C needs to know if R as offered by RS really is the resource it wants to access. 3. Actors This section describes the various actors in the architecture. An actor is identified by the tasks it has to fulfill. Several actors might share a single device or even be combined in a single piece of software. Interfaces between actors may be realized as protocols or be internal to such a piece of software. 3.1. Constrained Level Actors As described above, either C or RS or both of them may be located on a constrained node. Although they are not necessarily constrained they should be able to operate if they are. We therefore derive from the problem description that C and RS must be able to perform their tasks even if they are located on a constrained node. Thus, C and RS are considered to be Constrained Level Actors. RS is hosting a resource R. R is an item of interest such as a sensor or actuator value. R is considered to be part of RS and is not a separate actor. The device on which RS is located might contain several resources of different resource owners. For simplicity of exposition, these resources are described as if they had separate RS. C attempts to access a resource on RS. As C and RS do not previously know each other they might belong to different security domains. Gerdes Expires December 1, 2014 [Page 4] Internet-Draft ace-actors May 2014 3.2. Principal Level Actors Our objective is that C and RS are under control of principals in the physical world, the Client Owner (CO) and the Resource Owner (RO) respectively. The owners decide about the security policies of their respective devices and belong to the same security domain. CO is in charge of C, i.e. CO specifies security policies for C, e.g. with whom C is allowed to communicate. By definition, C and CO belong to the same security domain. RO is in charge of R and RS. RO specifies authorization policies for R and decides with whom RS is allowed to communicate. By definition, R, RS and RO belong to the same security domain. ------ ------ | CO | | RO | Principal Level ------ ------ | | in charge of in charge of | | V V ------- -------- | C | -- requests resource ---> | RS | Constrained Level ------- <-- provides resource--- -------- 3.3. Less-Constrained Level Actors Constrained level actors can only fulfill a limited number of tasks and may not have network connectivity all the time. To relieve them from having to manage keys for numerous devices and conducting computationally intensive tasks, another complexity level for actors is introduced. An actor on the less-constrained level belongs to the same security domain as its respective constrained level actor. They also have the same principal. The Authentication Manager (AM) belongs to the same security domain as C and CO. AM acts on behalf of CO. It is aiding C in the authentication of RS and determining if RS is an authorized source for R. The Authorization Server (AS) belongs to the same security domain as R, RS and RO. AS acts in behalf of RO. It supports RS by authenticating C and determining C's permissions on R. ------ ------ | CO | | RO | Principal Level Gerdes Expires December 1, 2014 [Page 5] Internet-Draft ace-actors May 2014 ------ ------ | | in charge of in charge of | | V V ---------- ----------- | AM | <-- AuthN and AuthZ -> | AS | Less-Constrained Level ---------- ----------- | | authentication authentication and authorization and authorization support support | | V V ------- -------- | C | -- requests resource ---> | RS | Constrained Level ------- <-- provides resource -- -------- For a more detailed graphic please consult the PDF version. 4. Protocol Requirements Devices on the less-constrained level are more powerful than constrained level devices. This results in different requirements for the protocols used on these levels. 4.1. Constrained Level Protocols A protocol is considered to be on the constrained level if it is used between the actors C and RS which are considered to be constrained (see Section 3.1). C and RS might not belong to the same security domain. Therefore, constrained level protocols are required to work between different security domains. Commonly used Internet protocols can not in every case be applied to constrained environments. In some cases, tweaking and profiling is required. In other cases it is beneficial to define new protocols which were designed with the special characteristics of constrained environments in mind. On the constrained level, protocols must be used which address the specific requirements of constrained environments. The Constrained Application Protocol (CoAP) [I-D.ietf-core-coap] should be used as transfer protocol if possible. CoAP defines a security binding to Datagram Transport Layer Security Protocol (DTLS) [RFC6347]. Thus, DTLS should be used for channel security. Gerdes Expires December 1, 2014 [Page 6] Internet-Draft ace-actors May 2014 Constrained devices have only limited storage space and thus cannot store large numbers of keys. This is especially important because constrained networks are expected to consist of thousands of nodes. Protocols on the constrained level should keep this limitation in mind. 4.1.1. Cross Level Support Protocols Protocols which operate between a constrained device on one side and the corresponding less constrained device on the other are considered to be (cross level) support protocols. Protocols used between C and AM or RS and AS are therefore support protocols. Support protocols must consider the limitations of their constrained endpoint and therefore belong to the constrained level protocols. 4.2. Less-Constrained Level Protocols A protocol is considered to be on the less-constrained level if it is used between the actors AM and AS. AM and AS might belong to different security domains. On the less-constrained level, HTTP [RFC2616] and Transport Layer Security (TLS) [RFC5246] can be used instead of CoAP and DTLS. Moreover, existing security solutions for authentication and authorization such as the Web Authorization Protocol (OAuth) [RFC6749] and Kerberos [RFC4120] can likely be used without modifications and there are no limitations for the use of a Public Key Infrastructure (PKI). 5. IANA Considerations None 6. Security Considerations This document discusses security requirements for the ACE architecture. 7. Acknowledgments The author would like to thank Carsten Bormann and Olaf Bergmann for their valuable input and feedback. 8. References 8.1. Normative References Gerdes Expires December 1, 2014 [Page 7] Internet-Draft ace-actors May 2014 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for Constrained-Node Networks", RFC 7228, May 2014. 8.2. Informative References [I-D.ietf-core-coap] Shelby, Z., Hartke, K., and C. Bormann, "Constrained Application Protocol (CoAP)", draft-ietf-core-coap-18 (work in progress), June 2013. [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The Kerberos Network Authentication Service (V5)", RFC 4120, July 2005. [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008. [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, January 2012. [RFC6749] Hardt, D., "The OAuth 2.0 Authorization Framework", RFC 6749, October 2012. Author's Address Stefanie Gerdes Universitaet Bremen TZI Postfach 330440 Bremen D-28359 Germany Phone: +49-421-218-63906 Email: gerdes@tzi.org Gerdes Expires December 1, 2014 [Page 8]