ACE Working Group L. Seitz Internet-Draft SICS Swedish ICT Intended Status: Informational G. Selander Expires: November 17, 2014 Ericsson May 16, 2014 Problem Description for Authorization in Constrained Environments draft-seitz-ace-problem-description-00 Abstract We present a problem description for authentication and authorization in constrained-node networks, i.e. networks which contain some devices with severe constraints on power, memory, and processing resources. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. 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". The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Copyright and License 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 Seitz & Selander Expires November 17, 2014 [Page 1] INTERNET DRAFT Problem description for ACE May 16, 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Problem Description . . . . . . . . . . . . . . . . . . . . . . 6 3.1. Authorization . . . . . . . . . . . . . . . . . . . . . . . 7 3.2. Authentication . . . . . . . . . . . . . . . . . . . . . . 8 3.3. Communication Security . . . . . . . . . . . . . . . . . . 8 3.4. Key Management . . . . . . . . . . . . . . . . . . . . . . 9 4. Assumptions and Requirements . . . . . . . . . . . . . . . . . 10 4.1 Architecture . . . . . . . . . . . . . . . . . . . . . . . . 10 4.2 Constrained Devices . . . . . . . . . . . . . . . . . . . . 10 4.3 Authorization . . . . . . . . . . . . . . . . . . . . . . . 11 4.4 Authorization information . . . . . . . . . . . . . . . . . 11 4.5 Access to authorization information . . . . . . . . . . . . 11 4.6 Resource access . . . . . . . . . . . . . . . . . . . . . . 12 4.7 Keys and cipher suites . . . . . . . . . . . . . . . . . . . 12 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 8.1 Normative References . . . . . . . . . . . . . . . . . . . 13 8.2 Informative References . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 Seitz & Selander Expires November 17, 2014 [Page 2] INTERNET DRAFT Problem description for ACE May 16, 2014 1. Introduction Authorization is the process of deciding what an entity ought to be allowed to do. This memo is about properties of security protocols to enable explicit and dynamic authorization of clients to access a resource at a server, in particular in constrained environments when the client and/or server are constrained nodes. See section 1.1 for terminology. Relevant use cases are presented in [I-D.seitz-ace-usecases], which also lists requirements derived from the use cases. That draft provides a good setting for the scope of the problem area, but does not present a detailed problem statement. We present in this memo a problem description for authentication and authorization in constrained environments with some more detailed candidate assumptions and requirements (section 4). 1.1 Terminology Certain security-related terms are to be understood in the sense defined in [RFC4949]. These terms include, but are not limited to, "authentication", "authorization", "confidentiality", "encryption", "data integrity", "message authentication code", and "verify". RESTful terms including "resource", "representation", etc. are to be understood as used in RFC2616 and CoAP [I-D.ietf-core-coap]. Terminology for constrained environments including "constrained device", "constrained-node network", "class 1", etc. are defined in [RFC7228]. "Explicit" authorization is used here to describe the ability to specify in some detail which entity has access to what and under what conditions, as opposed to "implicit" authorization where an entity is either allowed to access everything or nothing. "Dynamic" authorization means that the access control polices and the parameters on which they are evaluated may change during normal operations, as opposed to "static" authorization meaning that access control policies cannot be changed during normal operations and may require some special procedure such as out-of-band provision. 2. Background We assume a client-server setting, where a client wishes to access some resource hosted by a server. Such resources may e.g. be sensor data, configuration data, or actuator settings. Thus access to a Seitz & Selander Expires November 17, 2014 [Page 3] INTERNET DRAFT Problem description for ACE May 16, 2014 resource could be by different methods, some of which change the state of the resource. In this memo, we consider the REST setting i.e. GET, POST, PUT and DELETE, and application protocols in scope are HTTP and CoAP [I-D.ietf-core-coap]. We assume that the roles of client and server are not fixed, i.e. a node which is client could very well be server in some other context and vice-versa. Further we assume that in some cases, clients are not previously known to servers, thus we cannot assume that the server has access control policies specific to that client when the client initiates communication. Finally we also assume that in a significant number of cases, the server and/or the client are too constrained to handle the authorization decision procedure and related configuration on their own. Many authorization solutions involve a centralized, trusted third party, supporting the client and/or resource server. A trusted third party provides a more scalable way to centrally manage authorization policies, in order to ensure consistent authorization decisions. Instead of having the client-server interaction performing authentication, authorization, key establishment, etc. the third party can be involved to offer support with one or several of these tasks: o One example of support is that the client is authenticated to the third party instead of the server. To provide confidence to the server that a certain client has indeed been authenticated, some information identifying the authenticated client (in a protected form) needs to be communicated from the third party to the server, e.g. a secret key of the client. o A second example is that the third party provides a shared secret key to enable authentication and secure communication between the client and server, instead of client and server establishing this autonomously. The shared key needs to be communicated (in a protected form) from the third party to client and server, respectively. o A third example is that the authorization decision is performed by the third party instead of by the server. To provide confidence to the server about a specific authorization decision, some authorization information (in a protected form) needs to be communicated from the third party to the server. In addition, the server needs some information identifying the client to verify that the requesting party is indeed the authorized client, e.g. a secret key with which the server can verify a message authentication code generated by the client. Seitz & Selander Expires November 17, 2014 [Page 4] INTERNET DRAFT Problem description for ACE May 16, 2014 Protecting information carried between third party and server, requires some a priori established keys. How those keys are established is out of scope for this problem. However, keys that are used to protect information between third party and client are in scope: The reason being that dynamic access control is one of the use cases to be supported, and this may involve granting access to a client previously unknown to the server. Borrowing from OAuth 2.0 [RFC6749] terminology we have a client (C), a resource server (RS), an authorization server (AS - the third party), and a resource owner (RO). The RO does not need to be active in an M2M access control setting, so interactions with the RO are out of scope for this memo. In the target setting the RS is typically constrained, C may be constrained, whereas the AS is not assumed to be constrained. We also assume that keys are established between RS and AS (potentially via the RO) before the protocol begins. Since the RS is constrained, we assume that it needs to offload authorization policy management and authorization decision making to the AS. (NOTE: The physical separation of policy decision and policy enforcement is an established principle in policy based management, e.g. [RFC2748].) This means that authorization information needs to be transferred from AS to RS. This information may be specific access control decisions such as "client C has the right to access this URI with this RESTful method, this payload value, under these local conditions", "client C has the right to access these URIs" or more indirect information "client C is in this access group". In the latter it is assumed that the RS knows what rights are associated to a particular access group. The AS may for example be implemented as a cloud service, in a home server, or in a smart phone. The client and the RS may or may not have connectivity to AS (e.g. because the AS is switched off), or may only have intermittent connectivity, where a connection at the time of access request cannot be guaranteed. Another reason for intermittent connectivity may be that constant connectivity is not affordable (e.g. due to limited battery power, or a sensor mobility business case for which cellular connectivity cost too much or is not available). Obviously, in order for a client request to reach the RS there must be connectivity between C and RS, but that could be a short range technology such as NFC, ZigBee, Bluetooth etc. Furthermore, if there is no previous authorization information in the RS about the client, and neither can access the AS, access requests will be denied. Therefore we assume that either the client or the RS can access the AS at some point in time, prior to the client's request. As a summary, there are potentially a number of information flows Seitz & Selander Expires November 17, 2014 [Page 5] INTERNET DRAFT Problem description for ACE May 16, 2014 that needs to be secured: a. The transfer of authorization information from AS to RS b. The transfer of keys or credentials from AS to RS and C, respectively c. The access request/response procedure between C and RS 3. Problem Description From the background described in the previous section, we see the following problems that need to be solved in order to achieve explicit and dynamic authorization: o Authorization The RS must have access to authorization information and client information. Given that the relevant information has been provided to the RS, it must be able to handle an access request (match request against the authorization information, grant or deny the request, and in the case of grant perform what is requested). We call this process authorization decision enforcement. o Authentication Some property of the client needs to be authenticated to bind authorization information to it. The RS needs to establish the authenticity of authorization information, and that is comes for a trusted AS. Finally some property of the RS needs to be authenticated to the client, so that the client can verify that it is communicating with the intended RS. o Communication Security Communication security is needed to protect the integrity, and sometimes the secrecy of information flows between the parties. This includes the flow of authentication and authorization information, but also the actual request and response upon which access control is performed. o Key establishment Seitz & Selander Expires November 17, 2014 [Page 6] INTERNET DRAFT Problem description for ACE May 16, 2014 The client and the RS need to establish keys in order to set up secure communications These problems are interconnected. For example when authorization information flows from the AS to the RS, this can be solved either by a pull or push directly from AS to RS or via the client by using some protected data object. The authorization information must be integrity protected by the keys established between AS and RS, and the RS must be able to authenticate the AS as the source of this information. Most importantly, all the above needs to take into account potential constrained devices. 3.1. Authorization The core problem we are trying to solve is authorization: o The AS needs to transfer authorization information to the RS. This can be done through three different message sequences: Agent, Pull or Push [RFC2904]. - In the agent sequence, the client submits its request to the AS and the AS contacts the RS to execute the request on the client's behalf. - When using the pull sequence, the client contacts the RS and the RS pulls authorization information directly from the AS as a reaction to the client's request (as e.g. in RADIUS [RFC2865]). - In the push sequence, the client is used as intermediary between the AS and the RS, and authorization information is transferred in the form of some token (as e.g. in OAuth [RFC6749]). Each of these approaches has it's drawbacks and advantages in constrained environments, which needs to be weighed against each other. o What does the transferred authorization information contain and how should it be formatted/encoded? Again this must be efficient for constrained devices, considering size of authorization information and parser complexity. o How does the RS verify the authenticity of the authorization information? This strongly depends on the solution chosen for Seitz & Selander Expires November 17, 2014 [Page 7] INTERNET DRAFT Problem description for ACE May 16, 2014 the first bullet. o How does the RS enforce authorization decisions of the AS? Does the authorization information it obtained from the AS require additional policy evaluation (e.g. matching against local access control lists, evaluating local conditions)? What kind of policy evaluation can we assume a constrained device to be capable of? 3.2. Authentication The following problems need to be addressed, when considering authentication: o The RS needs to authenticate some property of the client, in order to bind it to the authorization information. This could e.g. be a digital signature or a message authentication codes performed by the client where a corresponding key is contained in the authorization information. o In many use cases the client wants to authenticate the RS, in order to ensure that it is interacting with the right resources. o The AS needs to authenticate its communication partner (either client or RS) in order to avoid leaking access control policy information. o Since the AS has a trust relation to both client and RS, it could also provide them with the means of mutual authentication (similar to a Kerberos [RFC4120] server). This would make it possible for the RS to authenticate previously unknown clients. 3.3. Communication Security For communication security there are different alternatives that offer various trade-offs, e.g. between performance and security. o One is session-based security at transport layer such as DTLS [RFC6347], which offers security, including integrity and confidentiality protection, for the whole application layer exchange. One cost of DTLS is the handshake protocol, which may be expensive for constrained devices especially in terms of wireless network communication. o An alternative is data object security at application layer, e.g. using JWE [I-D.ietf-jose-json-web-encryption]. Secure objects can be stored in network nodes to handle security for a more flexible communication model such as publish/subscribe Seitz & Selander Expires November 17, 2014 [Page 8] INTERNET DRAFT Problem description for ACE May 16, 2014 (compare e.g. CoRE Mirror Server [I-D.vial-core-mirror-proxy]). However, data object security only would not provide confidentiality for the message headers. For example, information such as the RESTful method, the host address, and the resource URI could be revealed. There are other differences in security properties between session based security and data object security, a detailed comparison is beyond the scope of this memo. A solution to the overall authorization problem may be based on session-based security only, data object security only or a hybrid. An example of a hybrid is where authorization information and keys are provided by the AS in the format of secure objects, but where the resource access is protected by session-based security. (For secure objects containing authorization information, compare e.g. OAuth 2.0 MAC Tokens [I-D.ietf-oauth-v2-http-mac].) A hybrid solution may also be useful to support a flexible trust model, e.g. a resource representation wrapped in JWE sent over DTLS hop-by-hop in a case where an intermediary is allowed to read the header but not the payload. There are no assumptions or requirements on communication security in this version of the draft as there are ongoing discussions on this topic. 3.4. Key Management With respect to key management, we see the following problems that need to be addressed: o Symmetric vs Asymmetric Do we want to support asymmetric or symmetric key solutions, or both? The question applies both to protection of resource access and transport of authentication and authorization information. There are classes of devices that can easily perform symmetric cryptography, but consume considerably more time/battery for asymmetric operations. On the other hand asymmetric cryptography has benefits e.g. in terms of deployment. o Key establishment How are the corresponding keys established? Considering section 3.1 there must be a binding between these keys and the Seitz & Selander Expires November 17, 2014 [Page 9] INTERNET DRAFT Problem description for ACE May 16, 2014 authorization information, at least in the sense that the AS must be able to specify a unique client identifier which the RS can verify (using an associated key). One of the use cases of [I-D.seitz-ace-usecases] describes spontaneous change of access policies - e.g. giving a hitherto unknown client the right to temporarily unlock your house door. In this case the client key is not previously known to the RS and must be provisioned by the AS. o Revocation and Expiration How are the keys renewed and how is a key that has been compromised revoked in a manner that reaches all relying parties, also keeping in mind scenarios with intermittent connectivity? 4. Assumptions and Requirements In this section we list a set of candidate assumptions and requirements to make the problem description in the previous sections more concise and precise. The purpose of making this list is not to stipulate "the unique problem description", but to stimulate an aligned discussion on what assumptions and requirements the solution to the authorization problem should be based on. 4.1 Architecture The architecture consists of at least the following nodes: o RS hosting resources, and responding to access requests o C requesting access to resources o AS supporting the access request/response procedure by providing authorization information to RS. The AS may also provide other services such as authenticating C on behalf of the RS or providing keys or credentials to C and/or RS to secure the request/response procedure. o The architecture may contain intermediary nodes between any pair of C, RS and AS, such as e.g. translation/reverse proxies. 4.2 Constrained Devices Seitz & Selander Expires November 17, 2014 [Page 10] INTERNET DRAFT Problem description for ACE May 16, 2014 o C and RS are class 1 or less constrained devices o AS is not a constrained device o All devices can process symmetric cryptography without incurring an excessive performance penalty o The performance penalty for asymmetric cryptography is high for a significant set of constrained devices o The performance penalty for handling public key certificates and especially public key certificate chains is high for a significant set of constrained devices. o The performance penalty for handling revocation lists is high for a significant set of constrained devices. o Wireless communication has high performance penalty for a significant set of constrained devices o The RS may not be able to reliably measure time 4.3 Authorization o The authorization decision may be taken either by AS or RS o The authorization decision are enforced by RS o There may be mechanisms for a client to look-up the corresponding AS for an RS 4.4 Authorization information o The authorization information shall contain either client capability lists, client attributes or authorization decisions o The authorization information shall contain information to allow the RS to verify that a requesting client is authorized 4.5 Access to authorization information o The RS shall authenticate the authorization information coming from the AS. The authorization information may be communicated via the client. o The authorization information shall be integrity protected and may be encrypted end-to-end between the AS and the RS Seitz & Selander Expires November 17, 2014 [Page 11] INTERNET DRAFT Problem description for ACE May 16, 2014 o The RS may not be able to communicate with the AS at the time of the request from a client o The RS may store authorization information o Authorization information stored in RS shall be possible to change. The change of such information shall be authorized 4.6 Resource access o Resources are accessed in a RESTful manner using GET, PUT, POST, DELETE o By default, the resource request shall be integrity protected and may be encrypted end-to-end from the client to the RS. It shall be possible for the RS to detect a replayed request. o By default, the response to a request shall be integrity protected and may be encrypted end-to-end from the RS to the client. o By default, the client shall be able to verify that the response to a request comes from the intended RS o There may be resources whose access need not be protected 4.7 Keys and cipher suites o The protection of access request/response between client and RS shall support the use of symmetric and/or asymmetric keys o The protection of authorization information shall support the use of symmetric and asymmetric keys o There may be a mechanism for the client to look-up the supported cipher suites of a RS 5. Security Considerations The entire document is about security considerations. 6. IANA Considerations This document has no actions for IANA. Seitz & Selander Expires November 17, 2014 [Page 12] INTERNET DRAFT Problem description for ACE May 16, 2014 7. Acknowledgements The authors would like to thank Vlasios Tsiatsis and John Mattson for contributing to the discussion and giving helpful comments. 8. References 8.1 Normative References [I-D.ietf-core-coap] Shelby, Z., Hartke, K., Bormann, C., and B. Frank, "Constrained Application Protocol (CoAP)", draft-ietf- core-coap-18 (work in progress), June 2013. [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", RFC 4949, August 2007. [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, January 2012. 8.2 Informative References [I-D.seitz-ace-usecases] Seitz, L., Gerdes, S., and Selander, G., "ACE use cases", draft-seitz-ace-usecases (work in progress), February 2014. [I-D.ietf-jose-json-web-encryption] Jones, M., Hildebrand, J., "JSON Web Encryption (JWE)", draft-ietf-jose-json-web-encryption (work in progress), April 2014. [I-D.vial-core-mirror-proxy] Vial, M., "CoRE Mirror Server", draft-vial-core-mirror- proxy (expired), July 2012. [I-D.ietf-oauth-v2-http-mac] Richter, J., Mills, W., Tschofenig, H. (Ed.), Hunt, P., "OAuth 2.0 Message Authentication Code (MAC) Tokens", draft-ietf-oauth-v2-http-mac (work in progress), January 2014. [RFC2748] Durham, D., Ed., Boyle, J., Cohen, R., Herzog, S., Rajan, R., and A. Sastry, "The COPS (Common Open Policy Service) Protocol", RFC 2748, January 2000. Seitz & Selander Expires November 17, 2014 [Page 13] INTERNET DRAFT Problem description for ACE May 16, 2014 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. [RFC2904] Vollbrecht, J., Calhoun, P., Farrell, S., Gommans, L., Gross, G., de Bruijn, B., de Laat, C., Holdrege, M., and D. Spence, "AAA Authorization Framework", RFC 2904, August 2000. [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The Kerberos Network Authentication Service (V5)", RFC 4120, July 2005. [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, January 2012. [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", RFC 6749, October 2012. [RFC7228] Bormann, C., Ersue, M., and Keranen, A., "Terminology for Constrained-Node Networks", RFC 7228, May 2014. Authors' Addresses Ludwig Seitz SICS Swedish ICT AB Scheelevagen 17 22370 Lund SWEDEN EMail: ludwig@sics.se Goeran Selander Ericsson Farogatan 6 16480 Kista SWEDEN EMail: goran.selander@ericsson.com Seitz & Selander Expires November 17, 2014 [Page 14]