ACE Working Group S. Gerdes Internet-Draft O. Bergmann Intended status: Standards Track C. Bormann Expires: April 26, 2019 Universitaet Bremen TZI October 23, 2018 C3DC -- Constrained Client/Cross-Domain Capable Authorization Profile for Authentication and Authorization for Constrained Environments (ACE) draft-gerdes-ace-c3dc-00 Abstract Resource-constrained nodes come in various sizes and shapes and often have constraints on code size, state memory, processing capabilities, user interface, power and communication bandwidth (RFC 7228). This document specifies a profile that describes how two autonomous resource-constrained devices, a client and a server, obtain the required keying material and authorization information to securely communicate with each other. Each of the devices is coupled with a less-constrained device, the authorization manager, that helps with difficult authentication and authorization tasks. The constrained devices do not need to register with authorization managers from other security domains. The profile specifically targets constrained clients and servers. It is designed to consider the security objectives of the owners on the server and the client side. 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 https://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 April 26, 2019. Gerdes, et al. Expires April 26, 2019 [Page 1] Internet-Draft C3DC October 2018 Copyright Notice Copyright (c) 2018 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 (https://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 . . . . . . . . . . . . . . . . . . . . . . . 5 2. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 5 2.2. Details for the C3DC profile as an instance of the DTLS profile . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.3. Details for the C3DC profile as an instance of the OSCORE profile . . . . . . . . . . . . . . . . . . . . . . . . . 7 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 4. Security Considerations . . . . . . . . . . . . . . . . . . . 7 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 6.1. Normative References . . . . . . . . . . . . . . . . . . 7 6.2. Informative References . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 1. Introduction The ACE framework [I-D.ietf-ace-oauth-authz] describes how a client obtains authorization to access a (probably constrained [RFC7228]) server from the server's authorization manager. Without additional support, constrained clients will have difficulties to communicate with authorization managers from other security domains. They need to be configured with the necessary keying material to securely communicate with the AS. Manual configuration is not a feasible solution for the Internet of Things where the large number of nodes makes scalability a special concern. Also, constrained devices often lack user interfaces and displays and have slow response times, which make their configuration tedious. Therefore, the configuration of the client is best done using a less-constrained device that mediates between the constrained device and its overseeing principal, i.e., Gerdes, et al. Expires April 26, 2019 [Page 2] Internet-Draft C3DC October 2018 the human being that is configuring the device (such as its owner or user). In the Constrained Client Cross-Domain Authorization Profile (C3DC), each constrained device initially only requires a security association with its own authorization manager; it does not need to register with authorization managers from other security domains. The constrained device and its authorization manager belong to the same security domain, which makes their security association easier to maintain. As the managers are less-constrained, they can perform more difficult authentication and authorization tasks such as storing large numbers of keys, using less-constrained-level protocols such as HTTP or TLS, processing TLS certificates, etc. In this way, the authorization managers authenticate each other and validate each other's authorization. They vouch for their own constrained devices' attributes and keying material and negotiate the details of the secure communication between client and server. If the overseeing principals of both security domains approve of the communication, the managers provide the necessary keying material and authorization information to their respective constrained devices: The client is provided with a claim set from its authorization manager (CAS) that contains the necessary keying material, and, if necessary, the resources and actions it may perform on the server. The server is provided with a claim set from its manager (AS) that contains the keying material and the client's access permissions. The effort for clients and servers is thereby minimized. Summarizing, the role that is termed "Client" in [I-D.ietf-ace-oauth-authz] is split into the actual constrained client, "C", and its authorization manager, "CAS". This is summarized in Figure 1. Gerdes, et al. Expires April 26, 2019 [Page 3] Internet-Draft C3DC October 2018 ------- ------- | RqP | | RO | Principal Level ------- ------- | | controls controls | | V V -------- ------- | CAS | <- AuthN and AuthZ -> | AS | Less-Constrained Level -------- ------- | | controls and supports controls and supports authentication authentication and authorization and authorization | | V V ------- ------- | C | -- requests resource --> | RS | Constrained Level ------- <-- provides resource-- ------- Figure 1: Overall architecture Authorization Managers may be responsible for large numbers of devices. The overseeing principals only need to configure the authorization manager which will then provide the respective authentication and authorization information to the constrained devices it manages. The management of constrained devices thereby becomes much more comfortable. The benefits of the C3DC profile include: o Constrained devices only require a security association with their own authorization manager. o Constrained clients are not required to authenticate authorization servers from other security domains. o Authentication and authorization on the client side can be dynamic. o Both RqP's and RO's interests are considered. o Constrained devices without a real-time clock that are not time- synchronized can be supported. Gerdes, et al. Expires April 26, 2019 [Page 4] Internet-Draft C3DC October 2018 1.1. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. Readers are assumed to be familiar with the terms and concepts defined in [I-D.ietf-ace-actors]. The official pronunciation of "C3DC" rhymes with "curtsy". 2. Protocol The C3DC profile comprises three parts: 1. transfer of authentication and, if necessary, authorization information between AS and RS; 2. transfer of authentication and, if necessary, authorization information between CAS and C; 3. establishment of a security association between C and RS. 2.1. Overview Figure 2 depicts the C3DC protocol flow (messages in square brackets are optional): Gerdes, et al. Expires April 26, 2019 [Page 5] Internet-Draft C3DC October 2018 CAS C RS AS | <== DTLS chan. ==> | | <== DTLS chan. ==> | | | [Resource Req.-->] | | | | | | | | [<-- AS Info.] | | | | | | | <-- Access Req. | | | | | | | | <==== TLS/DTLS channel (CAS/AS Mutual Authn+Authz) ====> | | | | | | Token Request ------------------------------------------> | | | | | | <------------------------------------------ Token Grant | | | | | | Token Transf. --> | | | | | | | | | <== DTLS chan. ==> | | | | Auth. Res. Req. -> | | Figure 2: Protocol Overview As in the ACE framework, the client (C) may send an unauthorized resource request to the resource server (RS) to obtain the address of the authorization server (AS) that is responsible for the server. The client then contacts its own authorization manager (CAS) with which it already has a security association. As described in [I-D.ietf-ace-actors], C and CAS are expected to belong to the same security domain. The requesting party (RqP), i.e., the human being that is responsible for C and CAS, provisions CAS with authorization information. This enables CAS to decide which resource servers the client is allowed to communicate with, and which authorization servers are allowed to provide information about the RS. If CAS has information that RqP approves of the communication, CAS and AS authenticate each other. As they are less-constrained devices, they may use less-constrained level protocols such as TLS to authenticate each other. AS obtains from its overseeing principal, the resource owner (RO) if CAS is authorized to provide information (e.g., keying material) about C and if CAS's client is authorized to communicate with RS. After AS and CAS thus validated each others' authorization, AS generates an access token for RS. In the response to CAS, the AS may also specify access information that contains the keying material meant for C. The access token and access information must securely be provided to CAS. Gerdes, et al. Expires April 26, 2019 [Page 6] Internet-Draft C3DC October 2018 RqP may further specify the resources and actions that C may perform on RS. In this case, CAS adds this information to the access information. It then securely provides the access token and access information to C. Since C has a security association with CAS, it can authenticate the message. Also, CAS can provide C with validity information that even a constrained C is able to interpret. As in the usual ACE framework protocol flow, the client keeps the access information and provides the access token to the resource server. The resource server already has a security association with its AS and thus can validate that the token actually stems from an authorization server that is authorized by its overseeing principal RO. The client and the server then use the obtained information to communicate securely. 2.2. Details for the C3DC profile as an instance of the DTLS profile 2.3. Details for the C3DC profile as an instance of the OSCORE profile 3. IANA Considerations TBD 4. Security Considerations TBD 5. Acknowledgements 6. References 6.1. Normative References [I-D.ietf-ace-oauth-authz] Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and H. Tschofenig, "Authentication and Authorization for Constrained Environments (ACE) using the OAuth 2.0 Framework (ACE-OAuth)", draft-ietf-ace-oauth-authz-16 (work in progress), October 2018. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . Gerdes, et al. Expires April 26, 2019 [Page 7] Internet-Draft C3DC October 2018 6.2. Informative References [I-D.ietf-ace-actors] Gerdes, S., Seitz, L., Selander, G., and C. Bormann, "An architecture for authorization in constrained environments", draft-ietf-ace-actors-07 (work in progress), October 2018. [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for Constrained-Node Networks", RFC 7228, DOI 10.17487/RFC7228, May 2014, . Authors' Addresses Stefanie Gerdes Universitaet Bremen TZI Postfach 330440 Bremen D-28359 Germany Phone: +49-421-218-63906 Email: gerdes@tzi.org Olaf Bergmann Universitaet Bremen TZI Postfach 330440 Bremen D-28359 Germany Phone: +49-421-218-63904 Email: bergmann@tzi.org Carsten Bormann Universitaet Bremen TZI Postfach 330440 Bremen D-28359 Germany Phone: +49-421-218-63921 Email: cabo@tzi.org Gerdes, et al. Expires April 26, 2019 [Page 8]