idnits 2.17.1 draft-ietf-ace-actors-04.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 (August 31, 2016) is 2795 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-06) exists of draft-selander-ace-object-security-05 -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 6347 (Obsoleted by RFC 9147) -- Obsolete informational reference (is this intentional?): RFC 7230 (Obsoleted by RFC 9110, RFC 9112) -- Obsolete informational reference (is this intentional?): RFC 7231 (Obsoleted by RFC 9110) Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ACE Working Group S. Gerdes 3 Internet-Draft Universitaet Bremen TZI 4 Intended status: Informational L. Seitz 5 Expires: March 4, 2017 SICS Swedish ICT AB 6 G. Selander 7 Ericsson 8 C. Bormann, Ed. 9 Universitaet Bremen TZI 10 August 31, 2016 12 An architecture for authorization in constrained environments 13 draft-ietf-ace-actors-04 15 Abstract 17 Constrained-node networks are networks where some nodes have severe 18 constraints on code size, state memory, processing capabilities, user 19 interface, power and communication bandwidth (RFC 7228). 21 This document provides terminology, and identifies the elements that 22 an architecture needs to address, providing a problem statement, for 23 authentication and authorization in these networks. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on March 4, 2017. 42 Copyright Notice 44 Copyright (c) 2016 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 60 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 61 2. Architecture and High-level Problem Statement . . . . . . . . 6 62 2.1. Elements of an Architecture . . . . . . . . . . . . . . . 6 63 2.2. Architecture Variants . . . . . . . . . . . . . . . . . . 8 64 2.3. Information Flows . . . . . . . . . . . . . . . . . . . . 11 65 3. Security Objectives . . . . . . . . . . . . . . . . . . . . . 12 66 3.1. End-to-End Security Objectives in Multi-Hop Scenarios . . 13 67 4. Authentication and Authorization . . . . . . . . . . . . . . 14 68 5. Actors and their Tasks . . . . . . . . . . . . . . . . . . . 16 69 5.1. Constrained Level Actors . . . . . . . . . . . . . . . . 16 70 5.2. Principal Level Actors . . . . . . . . . . . . . . . . . 17 71 5.3. Less-Constrained Level Actors . . . . . . . . . . . . . . 18 72 6. Kinds of Protocols . . . . . . . . . . . . . . . . . . . . . 18 73 6.1. Constrained Level Protocols . . . . . . . . . . . . . . . 19 74 6.1.1. Cross Level Support Protocols . . . . . . . . . . . . 19 75 6.2. Less-Constrained Level Protocols . . . . . . . . . . . . 19 76 7. Elements of a Solution . . . . . . . . . . . . . . . . . . . 20 77 7.1. Authorization . . . . . . . . . . . . . . . . . . . . . . 20 78 7.2. Authentication . . . . . . . . . . . . . . . . . . . . . 20 79 7.3. Communication Security . . . . . . . . . . . . . . . . . 21 80 7.4. Cryptographic Keys . . . . . . . . . . . . . . . . . . . 22 81 8. Assumptions and Requirements . . . . . . . . . . . . . . . . 22 82 8.1. Architecture . . . . . . . . . . . . . . . . . . . . . . 22 83 8.2. Constrained Devices . . . . . . . . . . . . . . . . . . . 23 84 8.3. Authentication . . . . . . . . . . . . . . . . . . . . . 24 85 8.4. Server-side Authorization . . . . . . . . . . . . . . . . 24 86 8.5. Client-side Authorization Information . . . . . . . . . . 25 87 8.6. Server-side Authorization Information . . . . . . . . . . 25 88 8.7. Resource Access . . . . . . . . . . . . . . . . . . . . . 26 89 8.8. Keys and Cipher Suites . . . . . . . . . . . . . . . . . 26 90 8.9. Network Considerations . . . . . . . . . . . . . . . . . 26 91 8.10. Legacy Considerations . . . . . . . . . . . . . . . . . . 27 92 9. Security Considerations . . . . . . . . . . . . . . . . . . . 27 93 9.1. Physical Attacks on Sensor and Actuator Networks . . . . 27 94 9.2. Clocks and Time Measurements . . . . . . . . . . . . . . 29 95 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 96 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 29 97 12. Informative References . . . . . . . . . . . . . . . . . . . 29 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32 100 1. Introduction 102 Constrained nodes are small devices with limited abilities which in 103 many cases are made to fulfill a specific simple task. They have 104 limited hardware resources such as processing power, memory, non- 105 volatile storage and transmission capacity and additionally in most 106 cases do not have user interfaces and displays. Due to these 107 constraints, commonly used security protocols are not always easily 108 applicable. 110 Constrained nodes are expected to be integrated in all aspects of 111 everyday life and thus will be entrusted with vast amounts of data. 112 Without appropriate security mechanisms attackers might gain control 113 over things relevant to our lives. Authentication and authorization 114 mechanisms are therefore prerequisites for a secure Internet of 115 Things. 117 Authorization is about who can do what to which objects. 118 Authentication specifically addresses the who, but is often specific 119 to the authorization that is required (for example, it may be 120 sufficient to authenticate the age of an actor, so no identifier is 121 needed or even desired). Authentication often involves credentials, 122 only some of which need to be long-lived and generic; others may be 123 directed towards specific authorizations (but still possibly long- 124 lived). Authorization then makes use of these credentials, as well 125 as other information (such as the time of day). This means that the 126 application-induced complexity of authenticated authorization can 127 often be moved back and forth between these two aspects. 129 In some cases authentication and authorization can be addressed by 130 static configuration provisioned during manufacturing or deployment 131 by means of fixed trust anchors and static access control lists. 132 This is particularly applicable to siloed, fixed-purpose deployments. 134 However, as the need for flexible access to assets already deployed 135 increases, the legitimate set of authorized entities as well as their 136 specific privileges cannot be conclusively defined during deployment, 137 without any need for change during the lifetime of the device. 138 Moreover, several use cases illustrate the need for fine-grained 139 access control policies, for which for instance a basic access 140 control list concept may not be sufficiently powerful [RFC7744]. 142 The limitations of the constrained nodes ask for security mechanisms 143 which take the special characteristics of constrained environments 144 into account; not all constituents may be able to perform all 145 necessary tasks by themselves. In order to meet the security 146 requirements in constrained scenarios, the necessary tasks need to be 147 assigned to logical functional entities. 149 In order to be able to achieve complex security objectives between 150 actors some of which are hosted on simple ("constrained") devices, 151 some of the actors will make use of help from other, less constrained 152 actors. (This offloading is not specific to networks with 153 constrained nodes, but their constrainedness as the main motivation 154 is.) 156 We therefore group the logical functional entities by whether they 157 can be assigned to a constrained device ("constrained level") or need 158 higher function platforms ("less-constrained level"); the latter does 159 not necessarily mean high-function, "server" or "cloud" platforms. 160 Note that assigning a logical functional entity to the constrained 161 level does not mean that the specific implementation needs to be 162 constrained, only that it _can_ be. 164 The description assumes that some form of setup (aspects of which are 165 often called provisioning and/or commissioning) has already been 166 performed and at least some initial security relationships important 167 for making the system operational have already been established. 169 This document provides some terminology, and identifies the elements 170 an architecture needs to address, representing the relationships 171 between the logical functional entities involved; on this basis, a 172 problem description for authentication and authorization in 173 constrained-node networks is provided. 175 1.1. Terminology 177 Readers are required to be familiar with the terms and concepts 178 defined in [RFC4949], including "authentication", "authorization", 179 "confidentiality", "(data) integrity", "message authentication code", 180 and "verify". 182 REST terms including "resource", "representation", etc. are to be 183 understood as used in HTTP [RFC7231] and CoAP [RFC7252]; the latter 184 also defines additional terms such as "endpoint". 186 Terminology for constrained environments including "constrained 187 device", "constrained-node network", "class 1", etc. is defined in 188 [RFC7228]. 190 In addition, this document uses the following terminology: 192 Resource (R): an item of interest which is represented through an 193 interface. It might contain sensor or actuator values or other 194 information. (Intended to coincide with the definitions of 195 [RFC7252] and [RFC7231].) 197 Constrained node: a constrained device in the sense of [RFC7228]. 199 Actor: A logical functional entity that performs one or more tasks. 200 Multiple actors may be present within a single device or a single 201 piece of software. 203 Resource Server (RS): An entity which hosts and represents a 204 Resource. (Used here to discuss the server that provides a 205 resource that is the end, not the means, of the authenticated 206 authorization process - i.e., not CAS or AS.) 208 Client (C): An entity which attempts to access a resource on a RS. 209 (Used to discuss the client whose access to a resource is the end, 210 not the means, of the authenticated authorization process.) 212 Principal: (Used in its English sense here, and specifically as:) An 213 individual that is either RqP or RO or both. 215 Resource Owner (RO): The principal that is in charge of the resource 216 and controls its access permissions. 218 Requesting Party (RqP): The principal that is in charge of the 219 Client and controls the requests a Client makes and its acceptance 220 of responses. 222 Authorization Server (AS): An entity that prepares and endorses 223 authentication and authorization data for a Resource Server. 225 Client Authorization Server (CAS): An entity that prepares and 226 endorses authentication and authorization data for a Client. 228 Authorization Manager: An entity that prepares and endorses 229 authentication and authorization data for a constrained node. 230 Used in constructions such as "a constrained node's authorization 231 manager" to denote AS for RS and CAS for C. 233 Authenticated Authorization: The confluence of mechanisms for 234 authentication and authorization, ensuring that authorization is 235 applied to and made available for authenticated entities and that 236 entities providing authentication services are authorized to do so 237 for the specific authorization process at hand. 239 Note that other authorization architectures such as OAuth [RFC6749] 240 or UMA [I-D.hardjono-oauth-umacore] focus on the authorization 241 problems on the RS side, in particular what accesses to resources the 242 RS is to allow. In this document the term authorization includes 243 this aspect, but is also used for the client-side aspect of 244 authorization, i.e., more generally allowing RqPs to decide what 245 interactions clients may perform with other endpoints. 247 2. Architecture and High-level Problem Statement 249 This document deals with how to control and protect resource-based 250 interaction between potentially constrained endpoints. The following 251 setting is assumed as a high-level problem statement: 253 o An endpoint may host functionality of one or more actors. 255 o C in one endpoint requests to access R on a RS in another 256 endpoint. 258 o A priori, the endpoints do not necessarily have a pre-existing 259 security relationship to each other. 261 o Either of the endpoints, or both, may be constrained. 263 2.1. Elements of an Architecture 265 Without loss of generality, we focus on the C functionality in one 266 endpoint, which we therefore also call C, accessing the RS 267 functionality in another endpoint, which we therefore also call RS. 269 The constrained level and its security objectives are detailed in 270 Section 5.1. 272 -------------- -------------- 273 | ------- | | ------- | 274 | | C | ------ requests resource -----> | RS | | 275 | ------- <----- provides resource ------ ------- | 276 | Endpoint | | Endpoint | 277 -------------- -------------- 279 Figure 1: Constrained Level 281 The authorization decisions at the endpoints are made on behalf of 282 the principals that control the endpoints. To reuse OAuth and UMA 283 terminology, the present document calls the principal that is 284 controlling C the Requesting Party (RqP), and calls the principal 285 that is controlling RS the Resource Owner (RO). Each principal makes 286 authorization decisions (possibly encapsulating them into security 287 policies) which the endpoint it controls then enforces. 289 The specific security objectives will vary, but for any specific 290 version of this scenario will include one or more of: 292 o Objectives of type 1: No entity not authorized by the RO has 293 access to (or otherwise gains knowledge of) R. 295 o Objectives of type 2: C is exchanging information with (sending a 296 request to, accepting a response from) a resource only where it 297 can ascertain that RqP has authorized the exchange with R. 299 Objectives of type 1 require performing authorization on the Resource 300 Server side while objectives of type 2 require performing 301 authorization on the Client side. 303 More on the security objectives of the principal level in 304 Section 5.2. 306 ------- ------- 307 | RqP | | RO | Principal Level 308 ------- ------- 309 | | 310 in charge of in charge of 311 | | 312 V V 313 ------- ------- 314 | C | -- requests resource --> | RS | Constrained Level 315 ------- <-- provides resource-- ------- 317 Figure 2: Constrained Level and Principal Level 319 The use cases defined in [RFC7744] demonstrate that constrained 320 devices are often used for scenarios where their principals are not 321 present at the time of the communication, are not able to communicate 322 directly with the device because of a lack of user interfaces or 323 displays, or may prefer the device to communicate autonomously. 325 Moreover, constrained endpoints may need support with tasks requiring 326 heavy processing, large memory or storage, or interfacing to humans, 327 such as management of security policies defined by a principal. The 328 principal, in turn, requires some agent maintaining the policies 329 governing how its endpoints will interact. 331 For these reasons, another level of nodes is introduced in the 332 architecture, the less-constrained level. Using OAuth terminology, 333 AS acts on behalf of the RO to control and support the RS in handling 334 access requests, employing a pre-existing security relationship with 335 RS. We complement this with CAS acting on behalf of RqP to control 336 and support the C in making resource requests and acting on the 337 responses received, employing a pre-existing security relationship 338 with C. To further relieve the constrained level, authorization (and 339 related authentication) mechanisms may be employed between CAS and AS 340 (Section 6.2). (Again, both CAS and AS are conceptual entities 341 controlled by their respective principals. Many of these entities, 342 often acting for different principals, can be combined into a single 343 server implementation; this of course requires proper segregation of 344 the control information provided by each principal.) 346 ------- ------- 347 | RqP | | RO | Principal Level 348 ------- ------- 349 | | 350 controls controls 351 | | 352 V V 353 -------- ------- 354 | CAS | <- AuthN and AuthZ -> | AS | Less-Constrained Level 355 -------- ------- 356 | | 357 controls and supports controls and supports 358 authentication authentication 359 and authorization and authorization 360 | | 361 V V 362 ------- ------- 363 | C | -- requests resource --> | RS | Constrained Level 364 ------- <-- provides resource-- ------- 366 Figure 3: Overall architecture 368 Figure 3 shows all three levels considered in this document. Note 369 that the vertical arrows point down to illustrate exerting control 370 and providing support; this is complemented by information flows that 371 often are bidirectional. Note also that not all entities need to be 372 ready to communicate at any point in time; for instance, RqP may have 373 provided enough information to CAS that CAS can autonomously 374 negotiate access to RS with AS for C based on this information. 376 2.2. Architecture Variants 378 The elements of the architecture described above are architectural. 379 In a specific scenario, several elements can share a single device or 380 even be combined in a single piece of software. If C is located on a 381 more powerful device, it can be combined with CAS: 383 ------- -------- 384 | RqP | | RO | Principal Level 385 ------- -------- 386 | | 387 in charge of in charge of 388 | | 389 V V 390 ------------ -------- 391 | CAS + C | <- AuthN and AuthZ -> | AS | Less-Constrained Level 392 ------------ -------- 393 ^ | 394 \__ | 395 \___ authentication 396 \___ and authorization 397 requests resource/ \___ support 398 provides resource \___ | 399 \___ | 400 V V 401 ------- 402 | RS | Constrained Level 403 ------- 405 Figure 4: Combined C and CAS 407 If RS is located on a more powerful device, it can be combined with 408 AS: 410 ------- ------- 411 | RqP | | RO | Principal Level 412 ------- ------- 413 | | 414 in charge of in charge of 415 | | 416 V V 417 ---------- ----------- 418 | CAS | <- AuthN and AuthZ -> | RS + AS | Less-Constrained Level 419 ---------- ----------- 420 | ^ 421 authentication ___/ 422 and authorization ___/ 423 support ___/ request resource / provides resource 424 | ___/ 425 V ___/ 426 ------- / 427 | C | <- 428 ------- 430 Figure 5: Combined AS and RS 432 If C and RS have the same principal, CAS and AS can be combined. 434 ------------ 435 | RqP = RO | Principal Level 436 ------------ 437 | 438 in charge of 439 | 440 V 441 -------------- 442 | CAS + AS | Less-Constrained Level 443 -------------- 444 / \ 445 / \ 446 authentication authentication 447 and authorization and authorization 448 support support 449 / \ 450 V V 451 ------- ------- 452 | C | -- requests resource --> | RS | Constrained Level 453 ------- <-- provides resource -- ------- 455 Figure 6: CAS combined with AS 457 2.3. Information Flows 459 We now formulate the problem statement in terms of the information 460 flows the architecture focuses on. (While the previous section 461 discusses the architecture in terms of abstract devices and their 462 varying roles, the actual protocols being standardized define those 463 information flows and the messages embodying them: "RESTful 464 architectures focus on defining interfaces and not components" 465 ([REST], p. 116).) 467 The interaction with the nodes on the principal level, RO and RqP, is 468 not involving constrained nodes and therefore can employ an existing 469 mechanism. The less-constrained nodes, CAS and AS, support the 470 constrained nodes, C and RS, with control information, for example 471 permissions of clients, conditions on resources, attributes of client 472 and resource servers, keys and credentials. This control information 473 may be rather different for C and RS, reflecting the intrinsic 474 asymmetry with C initiating the request for access to a resource, and 475 RS acting on a received request, and C finally acting on the received 476 response. 478 The potential information flows are shown in Figure 7. The direction 479 of the vertical arrows expresses the exertion of control; actual 480 information flow is bidirectional. 482 The message flow may pass unprotected paths and thus need to be 483 protected, potentially beyond a single REST hop (Section 3.1): 485 ------- ------- 486 | CAS | | AS | 487 ------- ------- 488 a ^ | b a = requests for control info a ^ | b 489 | | b = control information | | 490 | v | v 491 ------- ------- 492 | C | ------ request -------------------> | RS | 493 | | <----- response ------------------- | | 494 ------- ------- 496 Figure 7: Information flows that need to be protected 498 o We assume that the necessary keys/credentials for protecting the 499 control information between the potentially constrained nodes and 500 their associated less-constrained nodes are pre-established, for 501 example as part of the commissioning procedure. 503 o Any necessary keys/credentials for protecting the interaction 504 between the potentially constrained nodes will need to be 505 established and maintained as part of a solution. 507 In terms of the elements of the architecture laid out above, this 508 document's problem statement for authorization in constrained 509 environments can then be summarized as follows: 511 o The interaction between potentially constrained endpoints is 512 controlled by control information provided by less-constrained 513 nodes on behalf of the principals of the endpoints. 515 o The interaction between the endpoints needs to be secured, as well 516 as the establishment of the necessary keys for securing the 517 interaction, potentially end-to-end through intermediary nodes. 519 o The mechanism for transferring control information needs to be 520 secured, potentially end-to-end through intermediary nodes. Pre- 521 established keying material may need to be employed for 522 establishing the keys used to protect these information flows. 524 (Note that other aspects relevant to secure constrained node 525 communication such as secure bootstrap or group communication are not 526 specifically addressed by the present document.) 528 3. Security Objectives 530 The security objectives that are addressed by an authorization 531 solution include confidentiality and integrity. Additionally, 532 allowing only selected entities limits the burden on system 533 resources, thus helping to achieve availability. Misconfigured or 534 wrongly designed authorization solutions can result in availability 535 breaches (denial of service): Users might no longer be able to use 536 data and services as they are supposed to. 538 Authentication mechanisms can achieve additional security objectives 539 such as accountability and third-party verifiability. These 540 additional objectives are not directly related to authorization and 541 thus are not in scope of this draft, but may nevertheless be 542 relevant. Accountability and third-party verifiability may require 543 authentication on a device level, if it is necessary to determine 544 which device performed an action. In other cases it may be more 545 important to find out who is responsible for the device's actions. 546 See also Section 4 for more discussion about authentication and 547 authorization. 549 The security objectives and their relative importance differ for the 550 various constrained environment applications and use cases [RFC7744]. 552 In many cases, one participating party has different security 553 objectives than another. To achieve a security objective of one 554 party, another party may be required to provide a service. For 555 example, if RqP requires the integrity of representations of a 556 resource R that RS is hosting, both C and RS need to partake in 557 integrity-protecting the transmitted data. Moreover, RS needs to 558 protect any write access to this resource as well as to relevant 559 other resources (such as configuration information, firmware update 560 resources) to prevent unauthorized users from manipulating R. 562 3.1. End-to-End Security Objectives in Multi-Hop Scenarios 564 In many cases, the information flows described in Section 2.3 cross 565 multiple client-server pairings but still need to be protected end- 566 to-end. For example, AS may not be connected to RS (or may not want 567 to exercise such a connection), relying on C for transferring 568 authorization information. As the authorization information is 569 related to the permissions granted to C, C must not be in a position 570 to manipulate this information, which therefore requires integrity 571 protection on the way between AS and RS. 573 As another example, resource representations sent between endpoints 574 may be stored in intermediary nodes, such as caching proxies or pub- 575 sub brokers. Where these intermediaries cannot be relied on to 576 fulfill the security objectives of the endpoints, these will need to 577 protect the exchanges beyond a single client-server exchange. 579 Note that there may also be cases of intermediary nodes that very 580 much partake in the security objectives to be achieved. The question 581 what are the pairs of endpoints between which the communication needs 582 end-to-end protection (and which aspect of protection) is defined by 583 the specific use case. Two examples of intermediary nodes executing 584 security functionality: 586 o To enable a trustworthy publication service, a pub-sub broker may 587 be untrusted with the plaintext content of a publication 588 (confidentiality), but required to verify that the publication is 589 performed by claimed publisher and is not a replay of an old 590 publication (authenticity/integrity). 592 o To comply with requirements of transparency, a gateway may be 593 allowed to read, verify (authenticity) but not modify (integrity) 594 a resource representation which therefore also is end-to-end 595 integrity protected from the server towards a client behind the 596 gateway. 598 In order to support the required communication and application 599 security, keying material needs to be established between the 600 relevant nodes in the architecture. 602 4. Authentication and Authorization 604 Server-side authorization solutions aim at protecting the access to 605 items of interest, for instance hardware or software resources or 606 data: They enable the resource owner to control who can access it and 607 how. 609 To determine if an entity is authorized to access a resource, an 610 authentication mechanism is needed. According to the Internet 611 Security Glossary [RFC4949], authentication is "the process of 612 verifying a claim that a system entity or system resource has a 613 certain attribute value." Examples for attribute values are the ID 614 of a device, the type of the device or the name of its owner. 616 The security objectives the authorization mechanism aims at can only 617 be achieved if the authentication and the authorization mechanism 618 work together correctly. We speak of authenticated authorization to 619 refer to the required synthesis of mechanism for authentication and 620 authorization. 622 Where used for authorization, the set of authenticated attributes 623 must be meaningful for this purpose, i.e., authorization decisions 624 must be possible based on these attributes. If the authorization 625 policy assigns permissions to an individual entity, the set of 626 authenticated attributes must be suitable to uniquely identify this 627 entity. 629 In scenarios where devices are communicating autonomously there is 630 often less need to uniquely identify an individual device: For a 631 principal, the fact that a device belongs to a certain company or 632 that it has a specific type (such as a light bulb) or location may be 633 more important than that it has a unique identifier. 635 (As a special case for the authorization of read access to a 636 resource, RS may simply make an encrypted representation available to 637 anyone [OSCAR]. In this case, controlling read access to that 638 resource can be reduced to controlling read access to the key; 639 partially removing access also requires a timely update of the key 640 for RS and all participants still authorized.) 642 Principals (RqP and RO) need to decide about the required level of 643 granularity for the authorization. For example, we distinguish 644 device authorization from owner authorization, and flat authorization 645 from unrestricted authorization. In the first case different access 646 permissions are granted to individual devices while in the second 647 case individual owners are authorized. If flat authorization is 648 used, all authenticated entities are implicitly authorized and have 649 the same access permissions. Unrestricted authorization for an item 650 of interest means that no authorization mechanism is used for 651 accessing this resource (not even by authentication) and all entities 652 are able to access the item as they see fit (note that an 653 authorization mechanism may still be used to arrive at the decision 654 to employ unrestricted authorization). 656 More fine-grained authorization does not necessarily provide more 657 security but can be more flexible. Principals need to consider that 658 an entity should only be granted the permissions it really needs 659 (principle of least privilege), to ensure the confidentiality and 660 integrity of resources. 662 Client-side authorization solutions aim at protecting the client from 663 disclosing information to or ingesting information from resource 664 servers RqP does not want it to interact with in the given way. 665 Again, flat authorization (the server can be authenticated) may be 666 sufficient, or more fine-grained authorization may be required. The 667 client-side authorization also pertains to the level of protection 668 required for the exchanges with the server (e.g., confidentiality). 669 In the browser web, client-side authorization is often left to the 670 human user; a constrained client may not have that available all the 671 time but still needs to implement the wishes of the principal 672 controlling it, the RqP. 674 For all cases where an authorization solution is needed (all but 675 unrestricted authorization), the enforcing party needs to be able to 676 authenticate the party that is to be authorized. Authentication is 677 therefore required for messages that contain (or otherwise update) 678 representations of an accessed item. More precisely: The enforcing 679 party needs to make sure that the receiver of a message containing a 680 representation is authorized to receive it, both in the case of a 681 client sending a representation to a server and vice versa. In 682 addition, it needs to ensure that the actual sender of a message 683 containing a representation is indeed the one authorized to send this 684 message, again for both the client-to-server and server-to-client 685 case. To achieve this, integrity protection of these messages is 686 required: Authenticity cannot be assured if it is possible for an 687 attacker to modify the message during transmission. 689 In some cases, only one side (client or server side) requires the 690 integrity and / or confidentiality of a resource value. Principals 691 may decide to omit authentication (unrestricted authorization), or 692 use flat authorization (just employing an authentication mechanism). 693 However, as indicated in Section 3, the security objectives of both 694 sides must be considered, which can often only be achieved when the 695 other side can be relied on to perform some security service. 697 5. Actors and their Tasks 699 This and the following section look at the resulting architecture 700 from two different perspectives: This section provides a more 701 detailed description of the various "actors" in the architecture, the 702 logical functional entities performing the tasks required. The 703 following section then will focus on the protocols run between these 704 functional entities. 706 For the purposes of this document, an actor consists of a set of 707 tasks and additionally has a security domain (client domain or server 708 domain) and a level (constrained, principal, less-constrained). 709 Tasks are assigned to actors according to their security domain and 710 required level. 712 Note that actors are a concept to understand the security 713 requirements for constrained devices. The architecture of an actual 714 solution might differ as long as the security requirements that 715 derive from the relationship between the identified actors are 716 considered. Several actors might share a single device or even be 717 combined in a single piece of software. Interfaces between actors 718 may be realized as protocols or be internal to such a piece of 719 software. 721 A more detailed discussion of the tasks the actors have to perform in 722 order to achieve specific security objectives is provided in 723 [I-D.gerdes-ace-tasks]. 725 5.1. Constrained Level Actors 727 As described in the problem statement (see Section 2), either C or RS 728 or both of them may be located on a constrained node. We therefore 729 define that C and RS must be able to perform their tasks even if they 730 are located on a constrained node. Thus, C and RS are considered to 731 be Constrained Level Actors. 733 C performs the following tasks: 735 o Communicate in a secure way (provide for confidentiality and 736 integrity of messages), including access requests. 738 o Validate that the RqP ("client-side") authorization information 739 allows C to communicate with RS as a server for R (i.e., from C's 740 point of view, RS is authorized as a server for the specific 741 access to R). 743 RS performs the following tasks: 745 o Communicate in a secure way (provide for confidentiality and 746 integrity of messages), including responses to access requests. 748 o Validate that the RO ("server-side") authorization information 749 allows RS to grant C access to the requested resource as requested 750 (i.e., from RS' point of view, C is authorized as a client for the 751 specific access to R). 753 R is an item of interest such as a sensor or actuator value. R is 754 considered to be part of RS and not a separate actor. The device on 755 which RS is located might contain several resources controlled by 756 different ROs. For simplicity of exposition, these resources are 757 described as if they had separate RS. 759 As C and RS do not necessarily know each other they might belong to 760 different security domains. 762 (See Figure 8.) 764 ------- -------- 765 | C | -- requests resource ---> | RS | Constrained Level 766 ------- <-- provides resource--- -------- 768 Figure 8: Constrained Level Actors 770 5.2. Principal Level Actors 772 Our objective is that C and RS are under control of principals in the 773 physical world, the Requesting Party (RqP) and the Resource Owner 774 (RO) respectively. The principals decide about the security policies 775 of their respective endpoints and belong to the same security domain. 777 RqP is in charge of C, i.e. RqP specifies security policies for C, 778 such as with whom C is allowed to communicate. By definition, C and 779 RqP belong to the same security domain. 781 RqP must fulfill the following task: 783 o Configure for C authorization information for sources for R. 785 RO is in charge of R and RS. RO specifies authorization policies for 786 R and decides with whom RS is allowed to communicate. By definition, 787 R, RS and RO belong to the same security domain. 789 RO must fulfill the following task: 791 o Configure for RS authorization information for accessing R. 793 (See Figure 2.) 795 5.3. Less-Constrained Level Actors 797 Constrained level actors can only fulfill a limited number of tasks 798 and may not have network connectivity all the time. To relieve them 799 from having to manage keys for numerous endpoints and conducting 800 computationally intensive tasks, another complexity level for actors 801 is introduced. An actor on the less-constrained level belongs to the 802 same security domain as its respective constrained level actor. They 803 also have the same principal. 805 The Client Authorization Server (CAS) belongs to the same security 806 domain as C and RqP. CAS acts on behalf of RqP. It assists C in 807 authenticating RS and determining if RS is an authorized server for 808 R. CAS can do that because for C, CAS is the authority for claims 809 about RS. 811 CAS performs the following tasks: 813 o Validate on the client side that an entity has certain attributes. 815 o Obtain authorization information about an entity from C's 816 principal (RqP) and provide it to C. 818 o Negotiate means for secure communication to communicate with C. 820 The Authorization Server (AS) belongs to the same security domain as 821 R, RS and RO. AS acts on behalf of RO. It supports RS by 822 authenticating C and determining C's permissions on R. AS can do 823 that because for RS, AS is the authority for claims about C. 825 AS performs the following tasks: 827 o Validate on the server side that an entity has certain attributes. 829 o Obtain authorization information about an entity from RS' 830 principal (RO) and provide it to RS. 832 o Negotiate means for secure communication to communicate with RS. 834 6. Kinds of Protocols 836 Devices on the less-constrained level potentially are more powerful 837 than constrained level devices in terms of processing power, memory, 838 non-volatile storage. This results in different characteristics for 839 the protocols used on these levels. 841 6.1. Constrained Level Protocols 843 A protocol is considered to be on the constrained level if it is used 844 between the actors C and RS which are considered to be constrained 845 (see Section 5.1). C and RS might not belong to the same security 846 domain. Therefore, constrained level protocols need to work between 847 different security domains. 849 Commonly used Internet protocols can not in every case be applied to 850 constrained environments. In some cases, tweaking and profiling is 851 required. In other cases it is beneficial to define new protocols 852 which were designed with the special characteristics of constrained 853 environments in mind. 855 On the constrained level, protocols need to address the specific 856 requirements of constrained environments. Examples for protocols 857 that consider these requirements is the transfer protocol CoAP 858 (Constrained Application Protocol) [RFC7252] and the Datagram 859 Transport Layer Security Protocol (DTLS) [RFC6347] which can be used 860 for channel security. 862 Constrained devices have only limited storage space and thus cannot 863 store large numbers of keys. This is especially important because 864 constrained networks are expected to consist of thousands of nodes. 865 Protocols on the constrained level should keep this limitation in 866 mind. 868 6.1.1. Cross Level Support Protocols 870 Protocols which operate between a constrained device on one side and 871 the corresponding less-constrained device on the other are considered 872 to be (cross level) support protocols. Protocols used between C and 873 CAS or RS and AS are therefore support protocols. 875 Support protocols must consider the limitations of their constrained 876 endpoint and therefore belong to the constrained level protocols. 878 6.2. Less-Constrained Level Protocols 880 A protocol is considered to be on the less-constrained level if it is 881 used between the actors CAS and AS. CAS and AS might belong to 882 different security domains. 884 On the less-constrained level, HTTP [RFC7230] and Transport Layer 885 Security (TLS) [RFC5246] can be used alongside or instead of CoAP and 886 DTLS. Moreover, existing security solutions for authentication and 887 authorization such as the OAuth web authorization framework [RFC6749] 888 and Kerberos [RFC4120] can likely be used without modifications and 889 there are no limitations for the use of a Public Key Infrastructure 890 (PKI). 892 7. Elements of a Solution 894 Without anticipating specific solutions, the following considerations 895 may be helpful in discussing them. 897 7.1. Authorization 899 The core problem we are trying to solve is authorization. The 900 following problems related to authorization need to be addressed: 902 o AS needs to transfer authorization information to RS and CAS needs 903 to transfer authorization information to C. 905 o The transferred authorization information needs to follow a 906 defined format and encoding, which must be efficient for 907 constrained devices, considering size of authorization information 908 and parser complexity. 910 o C and RS need to be able to verify the authenticity of the 911 authorization information they receive. Here as well, there is a 912 trade-off between processing complexity and deployment complexity. 914 o The RS needs to enforce the authorization decisions of the AS, 915 while C needs to abide with the authorization decisions of the 916 CAS. The authorization information might require additional 917 policy evaluation (such as matching against local access control 918 lists, evaluating local conditions). The required "policy 919 evaluation" at the constrained actors needs to be adapted to the 920 capabilities of the devices implementing them. 922 o Finally, as is indicated in the previous bullet, for a particular 923 authorization decision there may be different kinds of 924 authorization information needed, and these pieces of information 925 may be transferred to C and RS at different times and in different 926 ways prior to or during the client request. 928 7.2. Authentication 930 The following problems need to be addressed, when considering 931 authentication: 933 o RS needs to authenticate AS, and C needs to authenticate CAS, to 934 ensure that the authorization information and related data comes 935 from the correct source. 937 o CAS and AS may need to authenticate each other, both to perform 938 the required business logic and to ensure that CAS gets security 939 information related to the resources from the right source. 941 o In some use cases RS needs to authenticate some property of C, in 942 order to map it to the relevant authorization information. In 943 other applications, authentication and authorization of C may be 944 implicit, for example by encrypting the resource representation 945 the RS only providing access to those who possess the key to 946 decrypt. 948 o C may need to authenticate RS, in order to ensure that it is 949 interacting with the right resources. Alternatively C may just 950 verify the integrity of a received resource representation. 952 o CAS and AS need to authenticate their communication partner (C or 953 RS), in order to ensure it serves the correct device. 955 7.3. Communication Security 957 There are different alternatives to provide communication security, 958 and the problem here is to choose the optimal one for each scenario. 959 We list the available alternatives: 961 o Session-based security at transport layer such as DTLS [RFC6347] 962 offers security, including integrity and confidentiality 963 protection, for the whole application layer exchange. However, 964 DTLS may not provide end-to-end security over multiple hops. 965 Another problem with DTLS is the cost of the handshake protocol, 966 which may be too expensive for constrained devices especially in 967 terms of memory and power consumption for message transmissions. 969 o An alternative is object security at application layer, for 970 instance using [I-D.selander-ace-object-security]. Secure objects 971 can be stored or cached in network nodes and provide security for 972 a more flexible communication model such as publish/subscribe 973 (compare e.g. CoRE Mirror Server [I-D.koster-core-coap-pubsub]). 974 A problem with object security is that it can not provide 975 confidentiality for the message headers. 977 o Hybrid solutions using both session-based and object security are 978 also possible. An example of a hybrid is where authorization 979 information and cryptographic keys are provided by AS in the 980 format of secure data objects, but where the resource access is 981 protected by session-based security. 983 7.4. Cryptographic Keys 985 With respect to cryptographic keys, we see the following problems 986 that need to be addressed: 988 Symmetric vs Asymmetric Keys 989 We need keys both for protection of resource access and for 990 protection of transport of authentication and authorization 991 information. Do we want to support solutions based on asymmetric 992 keys or symmetric keys in both cases? There are classes of 993 devices that can easily perform symmetric cryptography, but 994 consume considerably more time/battery for asymmetric operations. 995 On the other hand asymmetric cryptography has benefits such as in 996 terms of deployment. 998 Key Establishment 999 How are the corresponding cryptographic keys established? 1000 Considering Section 7.1 there must be a mapping between these keys 1001 and the authorization information, at least in the sense that AS 1002 must be able to specify a unique client identifier which RS can 1003 verify (using an associated key). One of the use cases of 1004 [RFC7744] describes spontaneous change of access policies - such 1005 as giving a hitherto unknown client the right to temporarily 1006 unlock your house door. In this case C is not previously known to 1007 RS and a key must be provisioned by AS. 1009 Revocation and Expiration 1010 How are keys replaced and how is a key that has been compromised 1011 revoked in a manner that reaches all affected parties, also 1012 keeping in mind scenarios with intermittent connectivity? 1014 8. Assumptions and Requirements 1016 In this section we list a set of candidate assumptions and 1017 requirements to make the problem description in the previous sections 1018 more concise and precise. 1020 8.1. Architecture 1022 The architecture consists of at least the following types of nodes: 1024 o RS hosting resources, and responding to access requests 1026 o C requesting access to resources 1027 o AS supporting the access request/response procedure by providing 1028 authorization information to RS 1030 * AS may support this by aiding RS in authenticating C, or 1031 providing cryptographic keys or credentials to C and/or RS to 1032 secure the request/response procedure. 1034 o CAS supporting the access request/response procedure by providing 1035 authorization information to C 1037 * CAS may support this by aiding C in authenticating RS, 1038 forwarding information between AS and C (possibly ultimately 1039 for RS), or providing cryptographic keys or credentials to C 1040 and/or RS to secure the request/response procedure. 1042 o The architecture allows for intermediary nodes between any pair of 1043 C, RS, AS, and CAS, such as forward or reverse proxies in the CoRE 1044 architecture. (Solutions may or may not support all 1045 combinations.) 1047 * The architecture does not make a choice between session based 1048 security and data object security. 1050 8.2. Constrained Devices 1052 o C and/or RS may be constrained in terms of power, processing, 1053 communication bandwidth, memory and storage space, and moreover: 1055 * unable to manage complex authorization policies 1057 * unable to manage a large number of secure connections 1059 * without user interface 1061 * without constant network connectivity 1063 * unable to precisely measure time 1065 * required to save on wireless communication due to high power 1066 consumption 1068 o CAS and AS are not assumed to be constrained devices. 1070 o All devices under consideration can process symmetric cryptography 1071 without incurring an excessive performance penalty. 1073 * We assume the use of a standardized symmetric key algorithm, 1074 such as AES. 1076 * Except for the most constrained devices we assume the use of a 1077 standardized cryptographic hash function such as SHA-256 (which 1078 can be used with the HMAC construction for integrity 1079 protection). 1081 o Public key cryptography requires additional resources (such as 1082 RAM, ROM, power, specialized hardware). 1084 o A DTLS handshake involves significant computation, communication, 1085 and memory overheads in the context of constrained devices. 1087 * The RAM requirements of DTLS handshakes with public key 1088 cryptography are prohibitive for certain constrained devices. 1090 * Certificate-based DTLS handshakes require significant volumes 1091 of communication, RAM (message buffers) and computation. 1093 o A solution will need to consider support for a simple scheme for 1094 expiring authentication and authorization information on devices 1095 which are unable to measure time (cf. Section 9.2). 1097 8.3. Authentication 1099 o RS needs to authenticate AS to ensure that the authorization 1100 information and related data comes from the correct source. 1102 o Similarly, C needs to authenticate CAS to ensure that the 1103 authorization information and related data comes from the correct 1104 source. 1106 o Depending on use case and authorization requirements, C, RS, CAS, 1107 or AS may need to authenticate messages from each other. 1109 8.4. Server-side Authorization 1111 o RS enforces authorization for access to a resource based on 1112 credentials presented by C, the requested resource, the REST 1113 method, and local context in RS at the time of the request, or on 1114 any subset of this information. 1116 o The credentials presented by C may have been provided by CAS. 1118 o The underlying authorization decision is taken either by AS or RS. 1120 o The authorization decision is enforced by RS. 1122 * RS needs to have authorization information in order to verify 1123 that C is allowed to access the resource as requested. 1125 * RS needs to make sure that it provides resource access only to 1126 authorized clients. 1128 o Apart from authorization for access to a resource, authorization 1129 may also be required for access to information about a resource 1130 (for instance, resource descriptions). 1132 o The solution may need to be able to support the delegation of 1133 access rights. 1135 8.5. Client-side Authorization Information 1137 o C enforces client-side authorization by protecting its requests to 1138 RS and by authenticating results from RS, making use of decisions 1139 and policies as well as keying material provided by CAS. 1141 8.6. Server-side Authorization Information 1143 o Authorization information is transferred from AS to RS using 1144 Agent, Push or Pull mechanisms [RFC2904]. 1146 o RS needs to authenticate that the authorization information is 1147 coming from AS (integrity). 1149 o The authorization information may also be encrypted end-to-end 1150 between AS and RS (confidentiality). 1152 o The architecture supports the case where RS may not be able to 1153 communicate with AS at the time of the request from C. 1155 o RS may store or cache authorization information. 1157 o Authorization information may be pre-configured in RS. 1159 o Authorization information stored or cached in RS needs to be 1160 possible to change. The change of such information needs to be 1161 subject to authorization. 1163 o Authorization policies stored on RS may be handled as a resource, 1164 i.e. information located at a particular URI, accessed with 1165 RESTful methods, and the access being subject to the same 1166 authorization mechanics. AS may have special privileges when 1167 requesting access to the authorization policy resources on RS. 1169 o There may be mechanisms for C to look up the AS which provides 1170 authorization information about a particular resource. 1172 8.7. Resource Access 1174 o Resources are accessed in a RESTful manner using methods such as 1175 GET, PUT, POST, DELETE. 1177 o By default, the resource request needs to be integrity protected 1178 and may be encrypted end-to-end from C to RS. It needs to be 1179 possible for RS to detect a replayed request. 1181 o By default, the response to a request needs to be integrity 1182 protected and may be encrypted end-to-end from RS to C. It needs 1183 to be possible for C to detect a replayed response. 1185 o RS needs to be able to verify that the request comes from an 1186 authorized client. 1188 o C needs to be able to verify that the response to a request comes 1189 from the intended RS. 1191 o There may be resources whose access need not be protected (e.g. 1192 for discovery of the responsible AS). 1194 8.8. Keys and Cipher Suites 1196 o A constrained node and its authorization manager (i.e., RS and AS, 1197 and C and CAS) have established cryptographic keys. For example, 1198 they share a secret key or each have the other's public key. 1200 o The transfer of authorization information is protected with 1201 symmetric and/or asymmetric keys. 1203 o The access request/response can be protected with symmetric and/or 1204 asymmetric keys. 1206 o There must be a mechanism for RS to establish the necessary key(s) 1207 to verify and decrypt the request and to protect the response. 1209 o There must be a mechanism for C to establish the necessary key(s) 1210 to protect the request and to verify and decrypt the response. 1212 o There must be a mechanism for C to obtain the supported cipher 1213 suites of a RS. 1215 8.9. Network Considerations 1217 o A solution will need to consider network overload due to avoidable 1218 communication of a constrained node with its authorization manager 1219 (C with CAS, RS with AS). 1221 o A solution will need to consider network overload by compact 1222 authorization information representation. 1224 o A solution may want to optimize the case where authorization 1225 information does not change often. 1227 o A solution may consider support for an efficient mechanism for 1228 providing authorization information to multiple RSs, for example 1229 when multiple entities need to be configured or change state. 1231 8.10. Legacy Considerations 1233 o A solution may consider interworking with existing infrastructure. 1235 o A solution may consider supporting authorization of access to 1236 legacy devices. 1238 9. Security Considerations 1240 This document discusses authorization-related tasks for constrained 1241 environments and describes how these tasks can be mapped to actors in 1242 the architecture. 1244 The entire document is about security. Security considerations 1245 applicable to authentication and authorization in RESTful 1246 environments are provided in e.g. OAuth 2.0 [RFC6749]. 1248 In this section we focus on specific security aspects related to 1249 authorization in constrained-node networks. Section 11.6 of 1250 [RFC7252], "Constrained node considerations", discusses implications 1251 of specific constraints on the security mechanisms employed. A wider 1252 view of security in constrained-node networks is provided in 1253 [I-D.garcia-core-security]. 1255 9.1. Physical Attacks on Sensor and Actuator Networks 1257 The focus of this work is on constrained-node networks consisting of 1258 connected sensors and actuators. The main function of such devices 1259 is to interact with the physical world by gathering information or 1260 performing an action. We now discuss attacks performed with physical 1261 access to such devices. 1263 The main threats to sensors and actuator networks are: 1265 o Unauthorized access to data to and from sensors and actuators, 1266 including eavesdropping and manipulation of data. 1268 o Denial-of-service making the sensor/actuator unable to perform its 1269 intended task correctly. 1271 A number of attacks can be made with physical access to a device 1272 including probing attacks, timing attacks, power attacks, etc. 1273 However, with physical access to a sensor or actuator device it is 1274 possible to directly perform attacks equivalent of eavesdropping, 1275 manipulating data or denial of service. For example: 1277 o Instead of eavesdropping the sensor data or attacking the 1278 authorization system to gain access to the data, the attacker 1279 could make its own measurements on the physical object. 1281 o Instead of manipulating the sensor data the attacker could change 1282 the physical object which the sensor is measuring, thereby 1283 changing the payload data which is being sent. 1285 o Instead of manipulating data for an actuator or attacking the 1286 authorization system, the attacker could perform an unauthorized 1287 action directly on the physical object. 1289 o A denial-of-service attack could be performed physically on the 1290 object or device. 1292 All these attacks are possible by having physical access to the 1293 device, since the assets are related to the physical world. 1294 Moreover, this kind of attacks are in many cases straightforward 1295 (requires no special competence or tools, low cost given physical 1296 access, etc.) 1298 As a conclusion, if an attacker has full physical access to a 1299 sensor or actuator device, then much of the security functionality 1300 elaborated in this draft is not effective to protect the asset 1301 during the physical attack. 1303 Since it does not make sense to design a solution for a situation 1304 that cannot be protected against we assume there is no need to 1305 protect assets which are exposed during a physical attack. In 1306 other words, either an attacker does not have physical access to 1307 the sensor or actuator device, or if it has, the attack shall only 1308 have effect during the period of physical attack, and shall be 1309 limited in extent to the physical control the attacker exerts 1310 (e.g., must not affect the security of other devices.) 1312 9.2. Clocks and Time Measurements 1314 Measuring time and keeping wall-clock time with certain accuracy is 1315 important to achieve certain security properties, for example to 1316 determine whether a public key certificate, access token, or some 1317 other assertion, is valid. 1319 Dynamic authorization in itself requires the ability to handle expiry 1320 or revocation of authorization decisions or to distinguish new 1321 authorization decisions from old. 1323 For certain categories of devices we can assume that there is an 1324 internal clock which is sufficiently accurate to handle the time 1325 measurement requirements. If RS can connect directly to AS, this 1326 relationship can be used to update RS in terms of time, removing some 1327 uncertainty, as well as to directly provide revocation information, 1328 removing authorizations that are no longer desired. 1330 If RS continuously measures time but can't connect to AS or another 1331 trusted source of time, time drift may have to be accepted and it may 1332 be harder to manage revocation. However, it may still be able to 1333 handle short lived access rights within some margins, by measuring 1334 the time since arrival of authorization information or request. 1336 Some categories of devices in scope may be unable measure time with 1337 any accuracy (e.g. because of sleep cycles). This category of 1338 devices is not suitable for the use cases which require measuring 1339 validity of assertions and authorizations in terms of absolute time. 1341 10. IANA Considerations 1343 This document has no actions for IANA. 1345 11. Acknowledgements 1347 The authors would like to thank Olaf Bergmann, Robert Cragie, Samuel 1348 Erdtman, Klaus Hartke, Sandeep Kumar, John Mattson, Corinna Schmitt, 1349 Mohit Sethi, Abhinav Somaraju, Hannes Tschofenig, Vlasios Tsiatsis 1350 and Erik Wahlstroem for contributing to the discussion, giving 1351 helpful input and commenting on previous forms of this draft. The 1352 authors would also like to specifically acknowledge input provided by 1353 Hummen and others [HUM14delegation]. 1355 12. Informative References 1357 [HUM14delegation] 1358 Hummen, R., Shafagh, H., Raza, S., Voigt, T., and K. 1359 Wehrle, "Delegation-based Authentication and Authorization 1360 for the IP-based Internet of Things", 11th IEEE 1361 International Conference on Sensing, Communication, and 1362 Networking (SECON'14), June 30 - July 3, 2014. 1364 [I-D.garcia-core-security] 1365 Garcia-Morchon, O., Kumar, S., Keoh, S., Hummen, R., and 1366 R. Struik, "Security Considerations in the IP-based 1367 Internet of Things", draft-garcia-core-security-06 (work 1368 in progress), September 2013. 1370 [I-D.gerdes-ace-tasks] 1371 Gerdes, S., "Authorization-Related Tasks in Constrained 1372 Environments", draft-gerdes-ace-tasks-00 (work in 1373 progress), September 2015. 1375 [I-D.hardjono-oauth-umacore] 1376 Hardjono, T., Maler, E., Machulak, M., and D. Catalano, 1377 "User-Managed Access (UMA) Profile of OAuth 2.0", draft- 1378 hardjono-oauth-umacore-14 (work in progress), January 1379 2016. 1381 [I-D.koster-core-coap-pubsub] 1382 Koster, M., Keranen, A., and J. Jimenez, "Publish- 1383 Subscribe Broker for the Constrained Application Protocol 1384 (CoAP)", draft-koster-core-coap-pubsub-05 (work in 1385 progress), July 2016. 1387 [I-D.selander-ace-object-security] 1388 Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 1389 "Object Security of CoAP (OSCOAP)", draft-selander-ace- 1390 object-security-05 (work in progress), July 2016. 1392 [OSCAR] Vucinic, M., Tourancheau, B., Rousseau, F., Duda, A., 1393 Damon, L., and R. Guizzetti, "OSCAR: Object Security 1394 Architecture for the Internet of Things", CoRR vol. 1395 abs/1404.7799, 2014. 1397 [REST] Fielding, R. and R. Taylor, "Principled design of the 1398 modern Web architecture", ACM Trans. Inter. Tech. Vol. 1399 2(2), pp. 115-150, DOI 10.1145/514183.514185, May 2002. 1401 [RFC2904] Vollbrecht, J., Calhoun, P., Farrell, S., Gommans, L., 1402 Gross, G., de Bruijn, B., de Laat, C., Holdrege, M., and 1403 D. Spence, "AAA Authorization Framework", RFC 2904, 1404 DOI 10.17487/RFC2904, August 2000, 1405 . 1407 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The 1408 Kerberos Network Authentication Service (V5)", RFC 4120, 1409 DOI 10.17487/RFC4120, July 2005, 1410 . 1412 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", 1413 FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, 1414 . 1416 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1417 (TLS) Protocol Version 1.2", RFC 5246, 1418 DOI 10.17487/RFC5246, August 2008, 1419 . 1421 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1422 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 1423 January 2012, . 1425 [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", 1426 RFC 6749, DOI 10.17487/RFC6749, October 2012, 1427 . 1429 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 1430 Constrained-Node Networks", RFC 7228, 1431 DOI 10.17487/RFC7228, May 2014, 1432 . 1434 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 1435 Protocol (HTTP/1.1): Message Syntax and Routing", 1436 RFC 7230, DOI 10.17487/RFC7230, June 2014, 1437 . 1439 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 1440 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 1441 DOI 10.17487/RFC7231, June 2014, 1442 . 1444 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 1445 Application Protocol (CoAP)", RFC 7252, 1446 DOI 10.17487/RFC7252, June 2014, 1447 . 1449 [RFC7744] Seitz, L., Ed., Gerdes, S., Ed., Selander, G., Mani, M., 1450 and S. Kumar, "Use Cases for Authentication and 1451 Authorization in Constrained Environments", RFC 7744, 1452 DOI 10.17487/RFC7744, January 2016, 1453 . 1455 Authors' Addresses 1457 Stefanie Gerdes 1458 Universitaet Bremen TZI 1459 Postfach 330440 1460 Bremen D-28359 1461 Germany 1463 Phone: +49-421-218-63906 1464 Email: gerdes@tzi.org 1466 Ludwig Seitz 1467 SICS Swedish ICT AB 1468 Scheelevaegen 17 1469 Lund 223 70 1470 Sweden 1472 Email: ludwig@sics.se 1474 Goeran Selander 1475 Ericsson 1476 Faroegatan 6 1477 Kista 164 80 1478 Sweden 1480 Email: goran.selander@ericsson.com 1482 Carsten Bormann (editor) 1483 Universitaet Bremen TZI 1484 Postfach 330440 1485 Bremen D-28359 1486 Germany 1488 Phone: +49-421-218-63921 1489 Email: cabo@tzi.org