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,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework",
RFC 6749, DOI 10.17487/RFC6749, October 2012,
<https://www.rfc-editor.org/info/rfc6749>.
[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,
<https://www.rfc-editor.org/info/rfc6920>.
[RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object
Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049,
October 2013, <https://www.rfc-editor.org/info/rfc7049>.
[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
Application Protocol (CoAP)", RFC 7252,
DOI 10.17487/RFC7252, June 2014,
<https://www.rfc-editor.org/info/rfc7252>.
[RFC7641] Hartke, K., "Observing Resources in the Constrained
Application Protocol (CoAP)", RFC 7641,
DOI 10.17487/RFC7641, September 2015,
<https://www.rfc-editor.org/info/rfc7641>.
[RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)",
RFC 8152, DOI 10.17487/RFC8152, July 2017,
<https://www.rfc-editor.org/info/rfc8152>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig,
"CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392,
May 2018, <https://www.rfc-editor.org/info/rfc8392>.
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]