idnits 2.17.1 draft-tiloca-ace-revoked-token-notification-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 04, 2019) is 1635 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-46) exists of draft-ietf-ace-oauth-authz-25 ** Obsolete normative reference: RFC 7049 (Obsoleted by RFC 8949) ** Obsolete normative reference: RFC 8152 (Obsoleted by RFC 9052, RFC 9053) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ACE Working Group M. Tiloca 3 Internet-Draft L. Seitz 4 Intended status: Standards Track RISE AB 5 Expires: May 7, 2020 F. Palombini 6 Ericsson AB 7 S. Echeverria 8 G. Lewis 9 CMU SEI 10 November 04, 2019 12 Notification of Revoked Access Tokens in the Authentication and 13 Authorization for Constrained Environments (ACE) Framework 14 draft-tiloca-ace-revoked-token-notification-00 16 Abstract 18 This document specifies a method of the Authentication and 19 Authorization for Constrained Environments (ACE) framework, which 20 allows an Authorization Server to notify Clients and Resource Servers 21 (i.e., registered devices) about revoked Access Tokens. The method 22 relies on resource observation for the Constrained Application 23 Protocol (CoAP), with Clients and Resource Servers observing a 24 dedicated, device-specific Token Revocation List on the Authorization 25 Server. Resulting unsolicited notifications of revoked Access Tokens 26 complement alternative approaches such as token introspection, while 27 not requiring additional endpoints on Clients and Resource Servers. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at https://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on May 7, 2020. 46 Copyright Notice 48 Copyright (c) 2019 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (https://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 64 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 65 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 4 66 3. Upon Device Registration . . . . . . . . . . . . . . . . . . 4 67 4. Notification of Revoked Tokens . . . . . . . . . . . . . . . 5 68 5. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 69 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 70 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 71 8. Normative References . . . . . . . . . . . . . . . . . . . . 8 72 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 9 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 75 1. Introduction 77 Authentication and Authorization for Constrained Environments (ACE) 78 [I-D.ietf-ace-oauth-authz] is a framework that enforces access 79 control on IoT devices acting as Resource Servers. In order to use 80 ACE, both Clients and Resource Servers have to register with an 81 Authorization Server (AS) and become a registered device. Once 82 registered, a Client can send a request to the AS for an Access Token 83 for a Resource Server (RS). For a Client to access the RS, the 84 Client must present the issued Access Token at the RS, which then 85 validates and stores it. 87 Even though Access Tokens have expiration times, there are 88 circumstances by which an Access Token may need to be revoked before 89 its expiration time, such as: (1) a registered device has been 90 compromised, or is suspected of being compromised; (2) a registered 91 device is decommissioned; (3) there has been a change of access 92 policies for a registered device; and (4) there has been a change in 93 the ACE profile for a registered device. 95 This document specifies a method for allowing registered devices to 96 access and observe a Token Revocation List (TRL) resource on the AS, 97 in order to get an updated list of revoked, but yet not expired, 98 Access Tokens. In particular, registered devices rely on resource 99 observation for the Constrained Application Protocol (CoAP) 100 [RFC7641]. The benefits of this method are that it complements 101 introspection, and does not require any additional endpoints on the 102 registered devices. 104 1.1. Terminology 106 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 107 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 108 "OPTIONAL" in this document are to be interpreted as described in BCP 109 14 [RFC2119] [RFC8174] when, and only when, they appear in all 110 capitals, as shown here. 112 Readers are expected to be familiar with the terms and concepts 113 described in the ACE framework for authentication and authorization 114 [I-D.ietf-ace-oauth-authz], as well as with terms and concepts 115 related to CBOR Web Tokens (CWTs) [RFC8392]. The terminology for 116 entities in the considered architecture is defined in OAuth 2.0 117 [RFC6749]. In particular, this includes Client (C), Resource Server 118 (RS), and Authorization Server (AS). 120 Readers are also expected to be familiar with the terms and concepts 121 related to CBOR [RFC7049] and COSE [RFC8152], the CoAP protocol 122 [RFC7252], CoAP Observe [RFC7641], and the use of hash functions to 123 name objects as defined in [RFC6920]. 125 Note that, unless otherwise indicated, the term "endpoint" is used 126 here following its OAuth definition, aimed at denoting resources such 127 as /token and /introspect at the AS, and /authz-info at the RS. This 128 document does not use the CoAP definition of "endpoint", which is "An 129 entity participating in the CoAP protocol". 131 This specification also refers to the following terminology. 133 o Registered device: a device registered at the AS, as Client or RS. 135 o Token name: name of an Access Token, in binary format encoding. 136 The Token Name has no relation to other possibly used token 137 identifiers, such as the "cti" (CWT ID) claim of CBOR Web Tokens 138 (CWTs) [RFC8392]. 140 o Token Revocation List (TRL): a collection of Token names, in which 141 the corresponding Access Tokens have been revoked but are not 142 expired yet. 144 o TRL resource: a resource on the AS, with a TRL as its 145 representation. 147 o TRL endpoint: an endpoint at the AS associated to a TRL resource. 149 2. Protocol Overview 151 This protocol defines how a CoAP-based AS informs Clients and 152 Resource Servers, i.e. registered devices, about revoked tokens. How 153 the relationship between the registered device and the AS is 154 established is out of scope for this work. 156 At a high level, the steps of this protocol are as follows: 158 o When a device is registered at the AS, the AS generates a new TRL 159 resource associated to that device. At any point in time, the TRL 160 resource represents a list of all revoked Access Tokens referring 161 to that registered device that are yet not expired. If the 162 registered device is a Client, the associated TRL resource 163 represents the revoked non-expired Access Tokens issued by the AS 164 to that Client. If the registered device is a Resource Server, 165 the associated TRL resource represents the revoked non-expired 166 Access Tokens issued by the AS and to be consumed by that Resource 167 Server. The TRL resource is communicated to the device in the 168 course of the registration process. 170 o After the device registration is concluded, the device sends an 171 observation request to that TRL resource as described in 172 [RFC7641], i.e. a GET request with an Observe option set to 0 173 (register). Upon receiving the request, the AS adds the device to 174 the list of observers of that TRL resource. 176 o When an Access Token is revoked, the AS adds the corresponding 177 token name to the representation of the TRL resource. Also, when 178 a revoked Access Token eventually expires, the AS removes the 179 corresponding token name from the representation of the TRL 180 resource. In either case, after updating the representation of 181 the TRL resource, the AS sends the updated corresponding list of 182 token names to the registered device as an Observe Notification, 183 as described in [RFC7641]. 185 3. Upon Device Registration 187 When a device is registered at an AS, the AS creates a TRL resource 188 under the resource path "/trl". It is RECOMMENDED for the AS to use 189 the device identifier for this resource's name, e.g. 190 "coap://example.as.org/trl/rs1807". 192 The initial content of this resource SHALL be an empty CBOR array. 193 The AS SHALL implement measures to prevent access to this resource by 194 devices other than the registered device. 196 After the registration procedure is finished, the registered device 197 performs a GET request to that resource, including the CoAP Observe 198 option set to 0 (register), in order to register an observation of 199 the TRL resource at the AS, as per Section 3.1 of [RFC7641]. The AS 200 SHALL respond with the initial value of the TRL resource, i.e. an 201 empty CBOR array, using the CoAP response code 2.05 (Content) and the 202 CoAP Observe option with value 1. 204 From that point on, the device can send GET requests to the TRL 205 resource at any time, in order to query the current list of revoked 206 Access Tokens related to the device. Unsolicited notifications are 207 provided through the CoAP observation mechanism, as described in 208 Section 4. 210 4. Notification of Revoked Tokens 212 When a non-expired Access Token is revoked, the AS checks to which 213 Client the Access Token was issued to, and which audience the Access 214 Token addresses. Note that the audience could resolve to a list of 215 Resource Servers. The AS then updates the TRL resources of these 216 registered devices, to include an identifier of the Access Token, 217 namely the corresponding token name. 219 Token names are generated as follows. The AS takes the binary 220 representation of the Access Token and generates a hash value as per 221 Section 6 of [RFC6920]. The resulting binary format name is used as 222 the token name. 224 The specifically used hash-function MUST be collision-resistant on 225 byte-strings, and MUST be selected from the "Named Information Hash 226 Algorithm" Registry defined in Section 9.4 of [RFC6920]. 228 The AS then sends Observe notifications to all the registered devices 229 affected by the revocation of that Access Token, as per Section 4.2 230 of [RFC7641]. 232 When a revoked Access Token expires, the AS removes the corresponding 233 token name from the TRLs related to the affected registered devices. 234 This will also trigger an Observe notification to those registered 235 devices, as per Section 4.2 of [RFC7641]. 237 5. Example 239 Figure 1 shows an example interaction between a Resource Server RS1 240 and an Authorization Server AS. The details of the registration 241 process are omitted, but it is assumed that RS1 sends an unspecified 242 payload to the AS, and then the AS replies with a 2.01 (Created) 243 response. The response contains a CBOR map, which includes a "trl" 244 parameter, specifying the path of the just created TRL resource. 246 The function 'h(x)' refers to the hash function used to compute the 247 token names according to [RFC6920] (see Section 4). In addition, 248 'bstr.t1' and 'bstr.t2' denote the byte-string representations of the 249 token names for the Access Tokens t1 and t2, respectively. 251 RS1 AS 252 | | 253 | Registration: POST | 254 +----------------------------------->| 255 | | 256 |<-----------------------------------+ 257 | 2.01 CREATED | 258 | Payload: { | 259 | ... | 260 | "trl" = "/trl/RS1" | 261 | } | 262 | | 263 | GET Observe: 0 | 264 | coap://example.as.com/trl/RS1 | 265 +----------------------------------->| Access control 266 | | 267 |<-----------------------------------+ 268 | 2.05 CONTENT Observe: 1 | 269 | . | 270 | . | 271 | . | 272 | | 273 | (Access Tokens t1 and t2 issued | 274 | and successfully submitted to RS1) | 275 | . | 276 | . | 277 | . | 278 | | 279 | (Access Token t1 is revoked) | 280 |<-----------------------------------+ 281 | 2.05 CONTENT Observe: 2 | 282 | Payload: | 283 | [h(bstr.t1)] | 284 | . | 285 | . | 286 | . | 287 | | 288 | (Access Token t2 is revoked) | 289 |<-----------------------------------+ 290 | 2.05 CONTENT Observe: 3 | 291 | Payload: | 292 | [h(bstr.t1), | 293 | h(bstr.t2)] | 294 | . | 295 | . | 296 | . | 297 | (Access Token t1 expires) | 298 |<-----------------------------------+ 299 | 2.05 CONTENT Observe: 4 | 300 | Payload: | 301 | [h(bstr.t2)] | 302 | | 304 Figure 1: Example of the communication between a RS and AS 306 6. Security Considerations 308 Security considerations are inherited from the ACE framework for 309 Authentication and Authorization [I-D.ietf-ace-oauth-authz], from 310 [RFC8392] as to the usage of CWTs, from [RFC7641] as to the usage of 311 CoAP Observe, and from [RFC6920] with regards to resource naming 312 through hashes. 314 The AS SHOULD ensure that only registered devices associated with a 315 TRL resource can access that specific TRL. The AS can have an access 316 control list or similar to prevent registered devices from getting 317 TRLs associated to other registered devices. 319 If a registered device has many non-expired tokens associated to it 320 that are revoked, the TRL could grow to a size bigger than what the 321 registered device is prepared to handle. This could be exploited by 322 attackers to negatively affect the behaviour of a registered device. 323 Short expiration times could help reduce the size of a TRL, but an AS 324 SHOULD take measures to limit this size. 326 7. IANA Considerations 328 This document has no actions for IANA. 330 8. Normative References 332 [I-D.ietf-ace-oauth-authz] 333 Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and 334 H. Tschofenig, "Authentication and Authorization for 335 Constrained Environments (ACE) using the OAuth 2.0 336 Framework (ACE-OAuth)", draft-ietf-ace-oauth-authz-25 337 (work in progress), October 2019. 339 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 340 Requirement Levels", BCP 14, RFC 2119, 341 DOI 10.17487/RFC2119, March 1997, 342 . 344 [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", 345 RFC 6749, DOI 10.17487/RFC6749, October 2012, 346 . 348 [RFC6920] Farrell, S., Kutscher, D., Dannewitz, C., Ohlman, B., 349 Keranen, A., and P. Hallam-Baker, "Naming Things with 350 Hashes", RFC 6920, DOI 10.17487/RFC6920, April 2013, 351 . 353 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 354 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 355 October 2013, . 357 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 358 Application Protocol (CoAP)", RFC 7252, 359 DOI 10.17487/RFC7252, June 2014, 360 . 362 [RFC7641] Hartke, K., "Observing Resources in the Constrained 363 Application Protocol (CoAP)", RFC 7641, 364 DOI 10.17487/RFC7641, September 2015, 365 . 367 [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", 368 RFC 8152, DOI 10.17487/RFC8152, July 2017, 369 . 371 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 372 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 373 May 2017, . 375 [RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig, 376 "CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392, 377 May 2018, . 379 Acknowledgments 381 The authors sincerely thank Jim Schaad for his comments and feedback. 383 The work on this document has been partly supported by VINNOVA and 384 the Celtic-Next project CRITISEC. 386 Authors' Addresses 388 Marco Tiloca 389 RISE AB 390 Isafjordsgatan 22 391 Kista SE-16440 Stockholm 392 Sweden 394 Email: marco.tiloca@ri.se 396 Ludwig Seitz 397 RISE AB 398 Scheelevagen 17 399 Lund SE-22370 Lund 400 Sweden 402 Email: ludwig.seitz@ri.se 404 Francesca Palombini 405 Ericsson AB 406 Torshamnsgatan 23 407 Kista SE-16440 Stockholm 408 Sweden 410 Email: francesca.palombini@ericsson.com 412 Sebastian Echeverria 413 CMU SEI 414 4500 Fifth Avenue 415 Pittsburgh, PA 15213-2612 416 United States of America 418 Email: secheverria@sei.cmu.edu 419 Grace Lewis 420 CMU SEI 421 4500 Fifth Avenue 422 Pittsburgh, PA 15213-2612 423 United States of America 425 Email: glewis@sei.cmu.edu