idnits 2.17.1 draft-ietf-ace-aif-00.txt: -(3): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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: ---------------------------------------------------------------------------- == There are 2 instances of lines with non-ascii characters in the document. 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 (29 July 2020) is 1366 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFCthis' is mentioned on line 338, but not defined == Unused Reference: 'I-D.ietf-ace-dtls-authorize' is defined on line 392, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-ace-oscore-profile' is defined on line 401, but no explicit reference was found in the text == Outdated reference: A later version (-18) exists of draft-ietf-ace-dtls-authorize-12 == Outdated reference: A later version (-19) exists of draft-ietf-ace-oscore-profile-11 -- Obsolete informational reference (is this intentional?): RFC 7049 (Obsoleted by RFC 8949) -- Obsolete informational reference (is this intentional?): RFC 7231 (Obsoleted by RFC 9110) Summary: 0 errors (**), 0 flaws (~~), 7 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Bormann 3 Internet-Draft Universität Bremen TZI 4 Intended status: Informational 29 July 2020 5 Expires: 30 January 2021 7 An Authorization Information Format (AIF) for ACE 8 draft-ietf-ace-aif-00 10 Abstract 12 Constrained Devices as they are used in the "Internet of Things" need 13 security. One important element of this security is that devices in 14 the Internet of Things need to be able to decide which operations 15 requested of them should be considered authorized, need to ascertain 16 that the authorization to request the operation does apply to the 17 actual requester, and need to ascertain that other devices they place 18 requests on are the ones they intended. 20 To transfer detailed authorization information from an authorization 21 manager (such as an ACE-OAuth Authorization Server) to a device, a 22 representation format is needed. This document provides a suggestion 23 for such a format, the Authorization Information Format (AIF). AIF 24 is defined both as a general structure that can be used for many 25 different applications and as a specific refinement that describes 26 REST resources and the permissions on them. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at https://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on 30 January 2021. 45 Copyright Notice 47 Copyright (c) 2020 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 52 license-info) in effect on the date of publication of this document. 53 Please review these documents carefully, as they describe your rights 54 and restrictions with respect to this document. Code Components 55 extracted from this document must include Simplified BSD License text 56 as described in Section 4.e of the Trust Legal Provisions and are 57 provided without warranty as described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 2 63 2. Information Model . . . . . . . . . . . . . . . . . . . . . . 3 64 2.1. REST-specific model . . . . . . . . . . . . . . . . . . . 4 65 2.2. Limitations . . . . . . . . . . . . . . . . . . . . . . . 4 66 2.3. Extended REST-specific model . . . . . . . . . . . . . . 5 67 3. Data Model . . . . . . . . . . . . . . . . . . . . . . . . . 5 68 4. Media Types . . . . . . . . . . . . . . . . . . . . . . . . . 8 69 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 70 5.1. Media Types . . . . . . . . . . . . . . . . . . . . . . . 8 71 5.2. Registries . . . . . . . . . . . . . . . . . . . . . . . 8 72 5.3. Content-Format . . . . . . . . . . . . . . . . . . . . . 8 73 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 74 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 75 7.1. Normative References . . . . . . . . . . . . . . . . . . 9 76 7.2. Informative References . . . . . . . . . . . . . . . . . 9 77 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 11 78 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11 80 1. Introduction 82 (See Abstract.) 84 1.1. Terminology 86 This memo uses terms from [RFC7252] and [RFC4949]. 88 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 89 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 90 "OPTIONAL" in this document are to be interpreted as described in 91 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 92 capitals, as shown here. These words may also appear in this 93 document in lower case as plain English words, absent their normative 94 meanings. 96 (Note that this document is itself informational, but it is 97 discussing normative statements that MUST be put into concrete terms 98 in each specification that makes use of this document.) 100 The term "byte", abbreviated by "B", is used in its now customary 101 sense as a synonym for "octet". 103 2. Information Model 105 Authorizations are generally expressed through some data structures 106 that are cryptographically secured (or transmitted in a secure way). 107 This section discusses the information model underlying the payload 108 of that data (as opposed to the cryptographic armor around it). 110 For the purposes of this strawman, the underlying access control 111 model will be that of an access matrix, which gives a set of 112 permissions for each possible combination of a subject and an object. 113 We do not concern the AIF format with the subject for which the AIF 114 object is issued, focusing the AIF object on a single row in the 115 access matrix (such a row traditionally is also called a capability 116 list). As a consequence, AIF MUST be used in a way that the subject 117 of the authorizations is unambiguously identified (e.g., as part of 118 the armor around it). 120 The generic model of a such a capability list is a list of pairs of 121 object identifiers and the permissions the subject has on the 122 object(s) identified. 124 AIF-Generic = [* [Toid, Tperm]] 126 Figure 1: Definition of Generic AIF 128 In a specific data model, the object identifier ("Toid") will often 129 be a text string, and the set of permissions ("Tperm") will be 130 represented by a bitset in turn represented as a number (see 131 Section 3). 133 AIF-Specific = AIF-Generic 135 Figure 2: Likely shape of a specific AIF 137 2.1. REST-specific model 139 In the specific instantiation of the REST resources and the 140 permissions on them, for the object identifiers ("Toid"), we simply 141 use the URI of a resource on a CoAP server. More specifically, the 142 parts of the URI that identify the server ("authority" in [RFC3986]) 143 are considered the realm of the authentication mechanism (which are 144 handled in the cryptographic armor); we therefore focus on the "path- 145 absolute" and "query" parts of the URI (URI "local-part" in this 146 specification, as expressed by the Uri-Path and Uri-Query options in 147 CoAP). As a consequence, AIF MUST be used in a way that it is 148 unambiguous who is the target (enforcement point) of these 149 authorizations. 151 For the permissions ("Tperm"), we simplify the model permissions to 152 giving the subset of the CoAP methods permitted. This model is 153 summarized in Table 1. 155 +============+================+ 156 | local-part | Permission Set | 157 +============+================+ 158 | /s/light | GET | 159 +------------+----------------+ 160 | /a/led | PUT, GET | 161 +------------+----------------+ 162 | /dtls | POST | 163 +------------+----------------+ 165 Table 1: An authorization 166 instance in the AIF 167 Information Model 169 2.2. Limitations 171 This simple information model only allows granting permissions for 172 statically identifiable objects, e.g. URIs for the REST-specific 173 instantiation. One might be tempted to extend the model towards URI 174 templates [RFC6570], however, that requires some considerations of 175 the ease and unambiguity of matching a given URI against a set of 176 templates in an AIF object. 178 This simple information model also doesn't allow further 179 conditionalizing access based on state outside the identification of 180 objects (e.g., "opening a door is allowed if that isn't locked"). 182 Finally, the model does not provide any special access for a set of 183 resources that are specific to a subject, e.g. that the subject 184 created itself by previous operations (PUT, POST) or that were 185 specifically created for the subject by others. 187 2.3. Extended REST-specific model 189 The extended REST-specific model addresses the need to provide 190 defined access to dynamic resources that were created by the subject 191 itself, specifically, a resource that is made known to the subject by 192 providing Location-* options in a CoAP result or using the Location 193 header field in HTTP [RFC7231] (the Location-indicating mechanisms). 194 (The concept is somewhat comparable to "ACL inheritance" in NFSv4 195 [rfc5661], except that it does not use a containment relationship but 196 the fact that the dynamic resource was created from a resource to 197 which the subject had access.) 199 +================+===================================+ 200 | local-part | Permission Set | 201 +================+===================================+ 202 | /a/make-coffee | POST, Dynamic-GET, Dynamic-DELETE | 203 +----------------+-----------------------------------+ 205 Table 2: An authorization instance in the AIF 206 Information Model 208 For a method X, the presence of a Dynamic-X permission means that the 209 subject holds permission to exercise the method X on resources that 210 have been returned by a Location-indicating mechanism to a request 211 that the subject made to the resource listed ("/a/make-coffee" in the 212 example, which might return the location of a resource that allows 213 GET to find out about the status and DELETE to cancel the coffee- 214 making operation). 216 Since the use of the extension defined in this section can be 217 detected by the mentioning of the Dynamic-X permissions, there is no 218 need for another explicit switch between the basic and the extended 219 model; the extended model is always presumed once a Dynamic-X 220 permission is present. 222 3. Data Model 224 Different data model specializations can be defined for the generic 225 information model given above. 227 In this section, we will give the data model for basic REST 228 authorization. As discussed, the object identifier is specialized as 229 a text string giving a relative URI (local-part as absolute path on 230 the server serving as enforcement point). The permission set is 231 specialized to a single number by the following steps: 233 * The entries in the table that specify the same local-part are 234 merged into a single entry that specifies the union of the 235 permission sets. 237 * The (non-dynamic) methods in the permission sets are converted 238 into their CoAP method numbers, minus 1. 240 * Dynamic-X permissions are converted into what the number would 241 have been for X, plus a Dynamic-Offset chosen as 32 (e.g., 35 for 242 Dynamic-DELETE). 244 * The set of numbers is converted into a single number by taking 245 each number to the power of two and computing the inclusive OR of 246 the binary representations of all the power values. 248 This data model could be interchanged in the JSON [RFC8259] 249 representation given in Figure 3. 251 [["/s/light", 1], ["/a/led", 5], ["/dtls", 2]] 253 Figure 3: An authorization instance encoded in JSON (46 bytes) 255 In CDDL [RFC8610], a straightforward specification of the data model 256 (including both the methods from [RFC7252] and the new ones from 257 [RFC8132], identified by the method code minus 1) is: 259 AIF-REST = AIF-Generic 260 path = tstr ; URI relative to enforcement point 261 permissions = uint .bits methods 262 methods = &( 263 GET: 0 264 POST: 1 265 PUT: 2 266 DELETE: 3 267 FETCH: 4 268 PATCH: 5 269 iPATCH: 6 270 Dynamic-GET: 32; 0 .plus Dynamic-Offset 271 Dynamic-POST: 33; 1 .plus Dynamic-Offset 272 Dynamic-PUT: 34; 2 .plus Dynamic-Offset 273 Dynamic-DELETE: 35; 3 .plus Dynamic-Offset 274 Dynamic-FETCH: 36; 4 .plus Dynamic-Offset 275 Dynamic-PATCH: 37; 5 .plus Dynamic-Offset 276 Dynamic-iPATCH: 38; 6 .plus Dynamic-Offset 277 ) 279 Figure 4: AIF in CDDL 281 A representation of this information in CBOR [RFC7049] is given in 282 Figure 5; again, several optimizations/improvements are possible. 284 83 # array(3) 285 82 # array(2) 286 68 # text(8) 287 2f732f6c69676874 # "/s/light" 288 01 # unsigned(1) 289 82 # array(2) 290 66 # text(6) 291 2f612f6c6564 # "/a/led" 292 05 # unsigned(5) 293 82 # array(2) 294 65 # text(5) 295 2f64746c73 # "/dtls" 296 02 # unsigned(2) 298 Figure 5: An authorization instance encoded in CBOR (29 bytes) 300 Note that choosing 32 as Dynamic-Offset means that all future CoAP 301 methods that can be registered can be represented both as themselves 302 and in the Dynamic-X variant, but only the dynamic forms of methods 1 303 to 21 are typically usable in a JSON form [RFC7493]. 305 4. Media Types 307 This specification defines media types for the generic information 308 model, expressed in JSON ("application/aif+json") or in CBOR 309 ("application/aif+cbor"). These media types have parameters for 310 specifying "Toid" and "Tperm"; default values are the values "local- 311 uri" for "Toid" and "REST-method-set" for "Tperm". 313 [Insert lots of boilerplate here] 315 A specification that wants to use Generic AIF with different "Toid" 316 and/or "Tperm" is expected to request these as media type parameters 317 (Section 5.2) and register a corresponding Content-Format 318 (Section 5.3). 320 5. IANA Considerations 322 5.1. Media Types 324 See Section 4. 326 5.2. Registries 328 IANA is requested to create a registry for AIF with two sub- 329 registries for "Toid" and "Tperm", populated with: 331 +=============+=================+=================================+ 332 | Subregistry | name | Description/Specification | 333 +=============+=================+=================================+ 334 | Toid | local-part | local-part of URI as specified | 335 | | | in [RFCthis] | 336 +-------------+-----------------+---------------------------------+ 337 | Tperm | REST-method-set | set of REST methods represented | 338 | | | as specified in [RFCthis] | 339 +-------------+-----------------+---------------------------------+ 341 Table 3 343 The registration policy is Specification required [RFC8126]. The 344 designated expert will engage with the submitter to ascertain the 345 requirements of this document are addressed. 347 5.3. Content-Format 349 IANA is requested to register Content-Format numbers in the CoRE 350 Parameters Registry [IANA.core-parameters], as follows: 352 6. Security Considerations 354 (TBD. Some issues are already discussed in the security 355 considerations of [RFC7252] and in [RFC8576].) 357 7. References 359 7.1. Normative References 361 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 362 Requirement Levels", BCP 14, RFC 2119, 363 DOI 10.17487/RFC2119, March 1997, 364 . 366 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", 367 FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, 368 . 370 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 371 Application Protocol (CoAP)", RFC 7252, 372 DOI 10.17487/RFC7252, June 2014, 373 . 375 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 376 Writing an IANA Considerations Section in RFCs", BCP 26, 377 RFC 8126, DOI 10.17487/RFC8126, June 2017, 378 . 380 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 381 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 382 May 2017, . 384 [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data 385 Definition Language (CDDL): A Notational Convention to 386 Express Concise Binary Object Representation (CBOR) and 387 JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, 388 June 2019, . 390 7.2. Informative References 392 [I-D.ietf-ace-dtls-authorize] 393 Gerdes, S., Bergmann, O., Bormann, C., Selander, G., and 394 L. Seitz, "Datagram Transport Layer Security (DTLS) 395 Profile for Authentication and Authorization for 396 Constrained Environments (ACE)", Work in Progress, 397 Internet-Draft, draft-ietf-ace-dtls-authorize-12, 6 July 398 2020, . 401 [I-D.ietf-ace-oscore-profile] 402 Palombini, F., Seitz, L., Selander, G., and M. Gunnarsson, 403 "OSCORE profile of the Authentication and Authorization 404 for Constrained Environments Framework", Work in Progress, 405 Internet-Draft, draft-ietf-ace-oscore-profile-11, 18 June 406 2020, . 409 [IANA.core-parameters] 410 IANA, "Constrained RESTful Environments (CoRE) 411 Parameters", 412 . 414 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 415 Resource Identifier (URI): Generic Syntax", STD 66, 416 RFC 3986, DOI 10.17487/RFC3986, January 2005, 417 . 419 [rfc5661] Shepler, S., Ed., Eisler, M., Ed., and D. Noveck, Ed., 420 "Network File System (NFS) Version 4 Minor Version 1 421 Protocol", RFC 5661, DOI 10.17487/RFC5661, January 2010, 422 . 424 [RFC6570] Gregorio, J., Fielding, R., Hadley, M., Nottingham, M., 425 and D. Orchard, "URI Template", RFC 6570, 426 DOI 10.17487/RFC6570, March 2012, 427 . 429 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 430 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 431 October 2013, . 433 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 434 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 435 DOI 10.17487/RFC7231, June 2014, 436 . 438 [RFC7493] Bray, T., Ed., "The I-JSON Message Format", RFC 7493, 439 DOI 10.17487/RFC7493, March 2015, 440 . 442 [RFC8132] van der Stok, P., Bormann, C., and A. Sehgal, "PATCH and 443 FETCH Methods for the Constrained Application Protocol 444 (CoAP)", RFC 8132, DOI 10.17487/RFC8132, April 2017, 445 . 447 [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 448 Interchange Format", STD 90, RFC 8259, 449 DOI 10.17487/RFC8259, December 2017, 450 . 452 [RFC8576] Garcia-Morchon, O., Kumar, S., and M. Sethi, "Internet of 453 Things (IoT) Security: State of the Art and Challenges", 454 RFC 8576, DOI 10.17487/RFC8576, April 2019, 455 . 457 Acknowledgements 459 Jim Schaad and Francesca Palombini provided comments that shaped the 460 direction of this document. 462 Author's Address 464 Carsten Bormann 465 Universität Bremen TZI 466 Postfach 330440 467 D-28359 Bremen 468 Germany 470 Phone: +49-421-218-63921 471 Email: cabo@tzi.org