ACE Working Group M. Tiloca Internet-Draft L. Seitz Intended status: Standards Track RISE AB Expires: May 7, 2020 F. Palombini Ericsson AB S. Echeverria G. Lewis CMU SEI November 04, 2019 Notification of Revoked Access Tokens in the Authentication and Authorization for Constrained Environments (ACE) Framework draft-tiloca-ace-revoked-token-notification-00 Abstract This document specifies a method of the Authentication and Authorization for Constrained Environments (ACE) framework, which allows an Authorization Server to notify Clients and Resource Servers (i.e., registered devices) about revoked Access Tokens. The method relies on resource observation for the Constrained Application Protocol (CoAP), with Clients and Resource Servers observing a dedicated, device-specific Token Revocation List on the Authorization Server. Resulting unsolicited notifications of revoked Access Tokens complement alternative approaches such as token introspection, while not requiring additional endpoints on Clients and Resource Servers. 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 May 7, 2020. Tiloca, et al. Expires May 7, 2020 [Page 1] Internet-Draft Notification of Revoked Tokens in ACE November 2019 Copyright Notice Copyright (c) 2019 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 . . . . . . . . . . . . . . . . . . . . . . . 3 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 4 3. Upon Device Registration . . . . . . . . . . . . . . . . . . 4 4. Notification of Revoked Tokens . . . . . . . . . . . . . . . 5 5. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 8. Normative References . . . . . . . . . . . . . . . . . . . . 8 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 1. Introduction Authentication and Authorization for Constrained Environments (ACE) [I-D.ietf-ace-oauth-authz] is a framework that enforces access control on IoT devices acting as Resource Servers. In order to use ACE, both Clients and Resource Servers have to register with an Authorization Server (AS) and become a registered device. Once registered, a Client can send a request to the AS for an Access Token for a Resource Server (RS). For a Client to access the RS, the Client must present the issued Access Token at the RS, which then validates and stores it. Even though Access Tokens have expiration times, there are circumstances by which an Access Token may need to be revoked before its expiration time, such as: (1) a registered device has been compromised, or is suspected of being compromised; (2) a registered device is decommissioned; (3) there has been a change of access policies for a registered device; and (4) there has been a change in the ACE profile for a registered device. Tiloca, et al. Expires May 7, 2020 [Page 2] Internet-Draft Notification of Revoked Tokens in ACE November 2019 This document specifies a method for allowing registered devices to access and observe a Token Revocation List (TRL) resource on the AS, in order to get an updated list of revoked, but yet not expired, Access Tokens. In particular, registered devices rely on resource observation for the Constrained Application Protocol (CoAP) [RFC7641]. The benefits of this method are that it complements introspection, and does not require any additional endpoints on the registered devices. 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 expected to be familiar with the terms and concepts described in the ACE framework for authentication and authorization [I-D.ietf-ace-oauth-authz], as well as with terms and concepts related to CBOR Web Tokens (CWTs) [RFC8392]. The terminology for entities in the considered architecture is defined in OAuth 2.0 [RFC6749]. In particular, this includes Client (C), Resource Server (RS), and Authorization Server (AS). Readers are also expected to be familiar with the terms and concepts related to CBOR [RFC7049] and COSE [RFC8152], the CoAP protocol [RFC7252], CoAP Observe [RFC7641], and the use of hash functions to name objects as defined in [RFC6920]. Note that, unless otherwise indicated, the term "endpoint" is used here following its OAuth definition, aimed at denoting resources such as /token and /introspect at the AS, and /authz-info at the RS. This document does not use the CoAP definition of "endpoint", which is "An entity participating in the CoAP protocol". This specification also refers to the following terminology. o Registered device: a device registered at the AS, as Client or RS. o Token name: name of an Access Token, in binary format encoding. The Token Name has no relation to other possibly used token identifiers, such as the "cti" (CWT ID) claim of CBOR Web Tokens (CWTs) [RFC8392]. o Token Revocation List (TRL): a collection of Token names, in which the corresponding Access Tokens have been revoked but are not expired yet. Tiloca, et al. Expires May 7, 2020 [Page 3] Internet-Draft Notification of Revoked Tokens in ACE November 2019 o TRL resource: a resource on the AS, with a TRL as its representation. o TRL endpoint: an endpoint at the AS associated to a TRL resource. 2. Protocol Overview This protocol defines how a CoAP-based AS informs Clients and Resource Servers, i.e. registered devices, about revoked tokens. How the relationship between the registered device and the AS is established is out of scope for this work. At a high level, the steps of this protocol are as follows: o When a device is registered at the AS, the AS generates a new TRL resource associated to that device. At any point in time, the TRL resource represents a list of all revoked Access Tokens referring to that registered device that are yet not expired. If the registered device is a Client, the associated TRL resource represents the revoked non-expired Access Tokens issued by the AS to that Client. If the registered device is a Resource Server, the associated TRL resource represents the revoked non-expired Access Tokens issued by the AS and to be consumed by that Resource Server. The TRL resource is communicated to the device in the course of the registration process. o After the device registration is concluded, the device sends an observation request to that TRL resource as described in [RFC7641], i.e. a GET request with an Observe option set to 0 (register). Upon receiving the request, the AS adds the device to the list of observers of that TRL resource. o When an Access Token is revoked, the AS adds the corresponding token name to the representation of the TRL resource. Also, when a revoked Access Token eventually expires, the AS removes the corresponding token name from the representation of the TRL resource. In either case, after updating the representation of the TRL resource, the AS sends the updated corresponding list of token names to the registered device as an Observe Notification, as described in [RFC7641]. 3. Upon Device Registration When a device is registered at an AS, the AS creates a TRL resource under the resource path "/trl". It is RECOMMENDED for the AS to use the device identifier for this resource's name, e.g. "coap://example.as.org/trl/rs1807". Tiloca, et al. Expires May 7, 2020 [Page 4] Internet-Draft Notification of Revoked Tokens in ACE November 2019 The initial content of this resource SHALL be an empty CBOR array. The AS SHALL implement measures to prevent access to this resource by devices other than the registered device. After the registration procedure is finished, the registered device performs a GET request to that resource, including the CoAP Observe option set to 0 (register), in order to register an observation of the TRL resource at the AS, as per Section 3.1 of [RFC7641]. The AS SHALL respond with the initial value of the TRL resource, i.e. an empty CBOR array, using the CoAP response code 2.05 (Content) and the CoAP Observe option with value 1. From that point on, the device can send GET requests to the TRL resource at any time, in order to query the current list of revoked Access Tokens related to the device. Unsolicited notifications are provided through the CoAP observation mechanism, as described in Section 4. 4. Notification of Revoked Tokens When a non-expired Access Token is revoked, the AS checks to which Client the Access Token was issued to, and which audience the Access Token addresses. Note that the audience could resolve to a list of Resource Servers. The AS then updates the TRL resources of these registered devices, to include an identifier of the Access Token, namely the corresponding token name. Token names are generated as follows. The AS takes the binary representation of the Access Token and generates a hash value as per Section 6 of [RFC6920]. The resulting binary format name is used as the token name. The specifically used hash-function MUST be collision-resistant on byte-strings, and MUST be selected from the "Named Information Hash Algorithm" Registry defined in Section 9.4 of [RFC6920]. The AS then sends Observe notifications to all the registered devices affected by the revocation of that Access Token, as per Section 4.2 of [RFC7641]. When a revoked Access Token expires, the AS removes the corresponding token name from the TRLs related to the affected registered devices. This will also trigger an Observe notification to those registered devices, as per Section 4.2 of [RFC7641]. Tiloca, et al. Expires May 7, 2020 [Page 5] Internet-Draft Notification of Revoked Tokens in ACE November 2019 5. Example Figure 1 shows an example interaction between a Resource Server RS1 and an Authorization Server AS. The details of the registration process are omitted, but it is assumed that RS1 sends an unspecified payload to the AS, and then the AS replies with a 2.01 (Created) response. The response contains a CBOR map, which includes a "trl" parameter, specifying the path of the just created TRL resource. The function 'h(x)' refers to the hash function used to compute the token names according to [RFC6920] (see Section 4). In addition, 'bstr.t1' and 'bstr.t2' denote the byte-string representations of the token names for the Access Tokens t1 and t2, respectively. RS1 AS | | | Registration: POST | +----------------------------------->| | | |<-----------------------------------+ | 2.01 CREATED | | Payload: { | | ... | | "trl" = "/trl/RS1" | | } | | | | GET Observe: 0 | | coap://example.as.com/trl/RS1 | +----------------------------------->| Access control | | |<-----------------------------------+ | 2.05 CONTENT Observe: 1 | | . | | . | | . | | | | (Access Tokens t1 and t2 issued | | and successfully submitted to RS1) | | . | | . | | . | | | | (Access Token t1 is revoked) | |<-----------------------------------+ | 2.05 CONTENT Observe: 2 | | Payload: | | [h(bstr.t1)] | | . | Tiloca, et al. Expires May 7, 2020 [Page 6] Internet-Draft Notification of Revoked Tokens in ACE November 2019 | . | | . | | | | (Access Token t2 is revoked) | |<-----------------------------------+ | 2.05 CONTENT Observe: 3 | | Payload: | | [h(bstr.t1), | | h(bstr.t2)] | | . | | . | | . | | (Access Token t1 expires) | |<-----------------------------------+ | 2.05 CONTENT Observe: 4 | | Payload: | | [h(bstr.t2)] | | | Figure 1: Example of the communication between a RS and AS 6. Security Considerations Security considerations are inherited from the ACE framework for Authentication and Authorization [I-D.ietf-ace-oauth-authz], from [RFC8392] as to the usage of CWTs, from [RFC7641] as to the usage of CoAP Observe, and from [RFC6920] with regards to resource naming through hashes. The AS SHOULD ensure that only registered devices associated with a TRL resource can access that specific TRL. The AS can have an access control list or similar to prevent registered devices from getting TRLs associated to other registered devices. If a registered device has many non-expired tokens associated to it that are revoked, the TRL could grow to a size bigger than what the registered device is prepared to handle. This could be exploited by attackers to negatively affect the behaviour of a registered device. Short expiration times could help reduce the size of a TRL, but an AS SHOULD take measures to limit this size. 7. IANA Considerations This document has no actions for IANA. Tiloca, et al. Expires May 7, 2020 [Page 7] Internet-Draft Notification of Revoked Tokens in ACE November 2019 8. 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-25 (work in progress), October 2019. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", RFC 6749, DOI 10.17487/RFC6749, October 2012, . [RFC6920] Farrell, S., Kutscher, D., Dannewitz, C., Ohlman, B., Keranen, A., and P. Hallam-Baker, "Naming Things with Hashes", RFC 6920, DOI 10.17487/RFC6920, April 2013, . [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, October 2013, . [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained Application Protocol (CoAP)", RFC 7252, DOI 10.17487/RFC7252, June 2014, . [RFC7641] Hartke, K., "Observing Resources in the Constrained Application Protocol (CoAP)", RFC 7641, DOI 10.17487/RFC7641, September 2015, . [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", RFC 8152, DOI 10.17487/RFC8152, July 2017, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig, "CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392, May 2018, . Tiloca, et al. Expires May 7, 2020 [Page 8] Internet-Draft Notification of Revoked Tokens in ACE November 2019 Acknowledgments The authors sincerely thank Jim Schaad for his comments and feedback. The work on this document has been partly supported by VINNOVA and the Celtic-Next project CRITISEC. Authors' Addresses Marco Tiloca RISE AB Isafjordsgatan 22 Kista SE-16440 Stockholm Sweden Email: marco.tiloca@ri.se Ludwig Seitz RISE AB Scheelevagen 17 Lund SE-22370 Lund Sweden Email: ludwig.seitz@ri.se Francesca Palombini Ericsson AB Torshamnsgatan 23 Kista SE-16440 Stockholm Sweden Email: francesca.palombini@ericsson.com Sebastian Echeverria CMU SEI 4500 Fifth Avenue Pittsburgh, PA 15213-2612 United States of America Email: secheverria@sei.cmu.edu Tiloca, et al. Expires May 7, 2020 [Page 9] Internet-Draft Notification of Revoked Tokens in ACE November 2019 Grace Lewis CMU SEI 4500 Fifth Avenue Pittsburgh, PA 15213-2612 United States of America Email: glewis@sei.cmu.edu Tiloca, et al. Expires May 7, 2020 [Page 10]