idnits 2.17.1 draft-ietf-ace-actors-05.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 (March 06, 2017) is 2580 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-16) exists of draft-ietf-core-object-security-01 -- 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: September 7, 2017 SICS Swedish ICT AB 6 G. Selander 7 Ericsson 8 C. Bormann, Ed. 9 Universitaet Bremen TZI 10 March 06, 2017 12 An architecture for authorization in constrained environments 13 draft-ietf-ace-actors-05 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 September 7, 2017. 42 Copyright Notice 44 Copyright (c) 2017 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 . . . . . . . . . . . . . . . . . . 9 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 . . . . . . . . . . . . . . . . 17 70 5.2. Principal Level Actors . . . . . . . . . . . . . . . . . 18 71 5.3. Less-Constrained Level Actors . . . . . . . . . . . . . . 18 72 6. Kinds of Protocols . . . . . . . . . . . . . . . . . . . . . 19 73 6.1. Constrained Level Protocols . . . . . . . . . . . . . . . 19 74 6.1.1. Cross Level Support Protocols . . . . . . . . . . . . 20 75 6.2. Less-Constrained Level Protocols . . . . . . . . . . . . 20 76 7. Elements of a Solution . . . . . . . . . . . . . . . . . . . 20 77 7.1. Authorization . . . . . . . . . . . . . . . . . . . . . . 20 78 7.2. Authentication . . . . . . . . . . . . . . . . . . . . . 21 79 7.3. Communication Security . . . . . . . . . . . . . . . . . 22 80 7.4. Cryptographic Keys . . . . . . . . . . . . . . . . . . . 22 81 8. Assumptions and Requirements . . . . . . . . . . . . . . . . 23 82 8.1. Architecture . . . . . . . . . . . . . . . . . . . . . . 23 83 8.2. Constrained Devices . . . . . . . . . . . . . . . . . . . 24 84 8.3. Authentication . . . . . . . . . . . . . . . . . . . . . 25 85 8.4. Server-side Authorization . . . . . . . . . . . . . . . . 25 86 8.5. Client-side Authorization Information . . . . . . . . . . 25 87 8.6. Server-side Authorization Information . . . . . . . . . . 26 88 8.7. Resource Access . . . . . . . . . . . . . . . . . . . . . 26 89 8.8. Keys and Cipher Suites . . . . . . . . . . . . . . . . . 27 90 8.9. Network Considerations . . . . . . . . . . . . . . . . . 27 91 8.10. Legacy Considerations . . . . . . . . . . . . . . . . . . 27 92 9. Security Considerations . . . . . . . . . . . . . . . . . . . 28 93 9.1. Physical Attacks on Sensor and Actuator Networks . . . . 28 94 9.2. Clocks and Time Measurements . . . . . . . . . . . . . . 29 95 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 96 11. Informative References . . . . . . . . . . . . . . . . . . . 30 97 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 32 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32 100 1. Introduction 102 As described in [RFC7228], constrained nodes are small devices with 103 limited abilities which in many cases are made to fulfill a specific 104 simple task. They may have limited hardware resources such as 105 processing power, memory, non-volatile storage and transmission 106 capacity and additionally in most cases do not have user interfaces 107 and displays. Due to these constraints, commonly used security 108 protocols are not always easily applicable, or may give rise to 109 particular deployment/management challenges. 111 As components of the Internet of Things (IoT), constrained nodes are 112 expected to be integrated in all aspects of everyday life and thus 113 will be entrusted with vast amounts of data. Without appropriate 114 security mechanisms attackers might gain control over things relevant 115 to our lives. Authentication and authorization mechanisms are 116 therefore prerequisites for a secure Internet of Things. 118 Applications generally require some degree of authentication and 119 authorization, which gives rise to some complexity. Authorization is 120 about who can do what to which objects (see also [RFC4949]). 121 Authentication specifically addresses the who, but is often specific 122 to the authorization that is required (for example, it may be 123 sufficient to authenticate the age of an actor, so no identifier is 124 needed or even desired). Authentication often involves credentials, 125 only some of which need to be long-lived and generic; others may be 126 directed towards specific authorizations (but still possibly long- 127 lived). Authorization then makes use of these credentials, as well 128 as other information (such as the time of day). This means that the 129 complexity of authenticated authorization can often be moved back and 130 forth between these two aspects. 132 In some cases authentication and authorization can be addressed by 133 static configuration provisioned during manufacturing or deployment 134 by means of fixed trust anchors and static access control lists. 135 This is particularly applicable to siloed, fixed-purpose deployments. 137 However, as the need for flexible access to assets already deployed 138 increases, the legitimate set of authorized entities as well as their 139 specific privileges cannot be conclusively defined during deployment, 140 without any need for change during the lifetime of the device. 141 Moreover, several use cases illustrate the need for fine-grained 142 access control policies, for which for instance a basic access 143 control list concept may not be sufficiently powerful [RFC7744]. 145 The limitations of the constrained nodes impose a need for security 146 mechanisms which take the special characteristics of constrained 147 environments into account; not all constituents may be able to 148 perform all necessary tasks by themselves. To put it the other way 149 round: the security mechanisms that protect constrained nodes must 150 remain effective and manageable despite the limitations imposed by 151 the constrained environment. 153 Therefore, in order to be able to achieve complex security objectives 154 between actors some of which are hosted on simple ("constrained") 155 devices, some of the actors will make use of help from other, less 156 constrained actors. (This offloading is not specific to networks 157 with constrained nodes, but their constrainedness as the main 158 motivation is.) 160 We therefore group the logical functional entities by whether they 161 can be assigned to a constrained device ("constrained level") or need 162 higher function platforms ("less-constrained level"); the latter does 163 not necessarily mean high-function, "server" or "cloud" platforms. 164 Note that assigning a logical functional entity to the constrained 165 level does not mean that the specific implementation needs to be 166 constrained, only that it _can_ be. 168 The description assumes that some form of setup (aspects of which are 169 often called provisioning and/or commissioning) has already been 170 performed and at least some initial security relationships important 171 for making the system operational have already been established. 173 This document provides some terminology, and identifies the elements 174 an architecture needs to address, representing the relationships 175 between the logical functional entities involved; on this basis, a 176 problem description for authentication and authorization in 177 constrained-node networks is provided. 179 1.1. Terminology 181 Readers are assumed to be familiar with the terms and concepts 182 defined in [RFC4949], including "authentication", "authorization", 183 "confidentiality", "(data) integrity", "message authentication code", 184 and "verify". 186 REST terms including "resource", "representation", etc. are to be 187 understood as used in HTTP [RFC7231] and CoAP [RFC7252]; the latter 188 also defines additional terms such as "endpoint". 190 Terminology for constrained environments including "constrained 191 device", "constrained-node network", "class 1", etc. is defined in 192 [RFC7228]. 194 In addition, this document uses the following terminology: 196 Resource (R): an item of interest which is represented through an 197 interface. It might contain sensor or actuator values or other 198 information. (Intended to coincide with the definitions of 199 [RFC7252] and [RFC7231].) 201 Constrained node: a constrained device in the sense of [RFC7228]. 203 Actor: A logical functional entity that performs one or more tasks. 204 Multiple actors may be present within a single device or a single 205 piece of software. 207 Resource Server (RS): An entity which hosts and represents a 208 Resource. (Used here to discuss the server that provides a 209 resource that is the end, not the means, of the authenticated 210 authorization process - i.e., not CAS or AS.) 212 Client (C): An entity which attempts to access a resource on a RS. 213 (Used to discuss the client whose access to a resource is the end, 214 not the means, of the authenticated authorization process.) 216 Principal: (Used in its English sense here, and specifically as:) An 217 individual that is either RqP or RO or both. 219 Resource Owner (RO): The principal that is in charge of the resource 220 and controls its access permissions. 222 Requesting Party (RqP): The principal that is in charge of the 223 Client and controls the requests a Client makes and its acceptance 224 of responses. 226 Authorization Server (AS): An entity that prepares and endorses 227 authentication and authorization data for a Resource Server. 229 Client Authorization Server (CAS): An entity that prepares and 230 endorses authentication and authorization data for a Client. 232 Authorization Manager: An entity that prepares and endorses 233 authentication and authorization data for a constrained node. 234 Used in constructions such as "a constrained node's authorization 235 manager" to denote AS for RS and CAS for C. 237 Authenticated Authorization: The confluence of mechanisms for 238 authentication and authorization, ensuring that authorization is 239 applied to and made available for authenticated entities and that 240 entities providing authentication services are authorized to do so 241 for the specific authorization process at hand. 243 Note that other authorization architectures such as OAuth [RFC6749] 244 or UMA [I-D.hardjono-oauth-umacore] focus on the authorization 245 problems on the RS side, in particular what accesses to resources the 246 RS is to allow. In this document the term authorization includes 247 this aspect, but is also used for the client-side aspect of 248 authorization, i.e., more generally allowing RqPs to decide what 249 interactions clients may perform with other endpoints. 251 2. Architecture and High-level Problem Statement 253 This document deals with how to control and protect resource-based 254 interaction between potentially constrained endpoints. The following 255 setting is assumed as a high-level problem statement: 257 o An endpoint may host functionality of one or more actors. 259 o C in one endpoint requests to access R on a RS in another 260 endpoint. 262 o A priori, the endpoints do not necessarily have a pre-existing 263 security relationship to each other. 265 o Either of the endpoints, or both, may be constrained. 267 2.1. Elements of an Architecture 269 In its simplest expression, the architecture starts with a two-layer 270 model: the principal level (at which components are assumed to be 271 functionally unconstrained) and the constrained level (at which some 272 functional constraints are assumed to apply to the components). 274 Without loss of generality, we focus on the C functionality in one 275 endpoint, which we therefore also call C, accessing the RS 276 functionality in another endpoint, which we therefore also call RS. 278 The constrained level and its security objectives are detailed in 279 Section 5.1. 281 -------------- -------------- 282 | ------- | | ------- | 283 | | C | ------ requests resource -----> | RS | | 284 | ------- <----- provides resource ------ ------- | 285 | Endpoint | | Endpoint | 286 -------------- -------------- 288 Figure 1: Constrained Level 290 The authorization decisions at the endpoints are made on behalf of 291 the principals that control the endpoints. To reuse OAuth and UMA 292 terminology, the present document calls the principal that is 293 controlling C the Requesting Party (RqP), and calls the principal 294 that is controlling RS the Resource Owner (RO). Each principal makes 295 authorization decisions (possibly encapsulating them into security 296 policies) which are then enforced by the endpoint it controls. 298 The specific security objectives will vary, but for any specific 299 version of this scenario will include one or more of: 301 o Objectives of type 1: No entity not authorized by the RO has 302 access to (or otherwise gains knowledge of) R. 304 o Objectives of type 2: C is exchanging information with (sending a 305 request to, accepting a response from) a resource only where it 306 can ascertain that RqP has authorized the exchange with R. 308 Objectives of type 1 require performing authorization on the Resource 309 Server side while objectives of type 2 require performing 310 authorization on the Client side. 312 More on the security objectives of the principal level in 313 Section 5.2. 315 ------- ------- 316 | RqP | | RO | Principal Level 317 ------- ------- 318 | | 319 in charge of in charge of 320 | | 321 V V 322 ------- ------- 323 | C | -- requests resource --> | RS | Constrained Level 324 ------- <-- provides resource-- ------- 326 Figure 2: Constrained Level and Principal Level 328 The use cases defined in [RFC7744] demonstrate that constrained 329 devices are often used for scenarios where their principals are not 330 present at the time of the communication, are not able to communicate 331 directly with the device because of a lack of user interfaces or 332 displays, or may prefer the device to communicate autonomously. 334 Moreover, constrained endpoints may need support with tasks requiring 335 heavy processing, large memory or storage, or interfacing to humans, 336 such as management of security policies defined by a principal. The 337 principal, in turn, requires some agent maintaining the policies 338 governing how its endpoints will interact. 340 For these reasons, another level of nodes is introduced in the 341 architecture, the less-constrained level (illustrated below in 342 Figure 3). Using OAuth terminology, AS acts on behalf of the RO to 343 control and support the RS in handling access requests, employing a 344 pre-existing security relationship with RS. We complement this with 345 CAS acting on behalf of RqP to control and support the C in making 346 resource requests and acting on the responses received, employing a 347 pre-existing security relationship with C. To further relieve the 348 constrained level, authorization (and related authentication) 349 mechanisms may be employed between CAS and AS (Section 6.2). (Again, 350 both CAS and AS are conceptual entities controlled by their 351 respective principals. Many of these entities, often acting for 352 different principals, can be combined into a single server 353 implementation; this of course requires proper segregation of the 354 control information provided by each principal.) 356 ------- ------- 357 | RqP | | RO | Principal Level 358 ------- ------- 359 | | 360 controls controls 361 | | 362 V V 363 -------- ------- 364 | CAS | <- AuthN and AuthZ -> | AS | Less-Constrained Level 365 -------- ------- 366 | | 367 controls and supports controls and supports 368 authentication authentication 369 and authorization and authorization 370 | | 371 V V 372 ------- ------- 373 | C | -- requests resource --> | RS | Constrained Level 374 ------- <-- provides resource-- ------- 376 Figure 3: Overall architecture 378 Figure 3 shows all three levels considered in this document. Note 379 that the vertical arrows point down to illustrate exerting control 380 and providing support; this is complemented by information flows that 381 often are bidirectional. Note also that not all entities need to be 382 ready to communicate at any point in time; for instance, RqP may have 383 provided enough information to CAS that CAS can autonomously 384 negotiate access to RS with AS for C based on this information. 386 2.2. Architecture Variants 388 The elements of the architecture described above are indeed 389 architectural; that is, they are parts of a conceptual model, and may 390 be instantiated in various ways in practice. For example, in a given 391 scenario, several elements might share a single device or even be 392 combined in a single piece of software. If C is located on a more 393 powerful device, it can be combined with CAS: 395 ------- -------- 396 | RqP | | RO | Principal Level 397 ------- -------- 398 | | 399 in charge of in charge of 400 | | 401 V V 402 ------------ -------- 403 | CAS + C | <- AuthN and AuthZ -> | AS | Less-Constrained Level 404 ------------ -------- 405 ^ | 406 \__ | 407 \___ authentication 408 \___ and authorization 409 requests resource/ \___ support 410 provides resource \___ | 411 \___ | 412 V V 413 ------- 414 | RS | Constrained Level 415 ------- 417 Figure 4: Combined C and CAS 419 If RS is located on a more powerful device, it can be combined with 420 AS: 422 ------- ------- 423 | RqP | | RO | Principal Level 424 ------- ------- 425 | | 426 in charge of in charge of 427 | | 428 V V 429 ---------- ----------- 430 | CAS | <- AuthN and AuthZ -> | RS + AS | Less-Constrained Level 431 ---------- ----------- 432 | ^ 433 authentication ___/ 434 and authorization ___/ 435 support ___/ request resource / provides resource 436 | ___/ 437 V ___/ 438 ------- / 439 | C | <- 440 ------- 442 Figure 5: Combined AS and RS 444 If C and RS have the same principal, CAS and AS can be combined. 446 ------------ 447 | RqP = RO | Principal Level 448 ------------ 449 | 450 in charge of 451 | 452 V 453 -------------- 454 | CAS + AS | Less-Constrained Level 455 -------------- 456 / \ 457 / \ 458 authentication authentication 459 and authorization and authorization 460 support support 461 / \ 462 V V 463 ------- ------- 464 | C | -- requests resource --> | RS | Constrained Level 465 ------- <-- provides resource -- ------- 467 Figure 6: CAS combined with AS 469 2.3. Information Flows 471 We now formulate the problem statement in terms of the information 472 flows the architecture focuses on. (While the previous section 473 discusses the architecture in terms of abstract devices and their 474 varying roles, the actual protocols being standardized define those 475 information flows and the messages embodying them: "RESTful 476 architectures focus on defining interfaces and not components" 477 ([REST], p. 116).) 479 The interaction with the nodes on the principal level, RO and RqP, is 480 not involving constrained nodes and therefore can employ an existing 481 mechanism. The less-constrained nodes, CAS and AS, support the 482 constrained nodes, C and RS, with control information, for example 483 permissions of clients, conditions on resources, attributes of client 484 and resource servers, keys and credentials. This control information 485 may be rather different for C and RS, reflecting the intrinsic 486 asymmetry with C initiating the request for access to a resource, and 487 RS acting on a received request, and C finally acting on the received 488 response. 490 The potential information flows are shown in Figure 7. The direction 491 of the vertical arrows expresses the exertion of control; actual 492 information flow is bidirectional. 494 The message flow may pass unprotected paths and thus need to be 495 protected, potentially beyond a single REST hop (Section 3.1): 497 ------- ------- 498 | CAS | | AS | 499 ------- ------- 500 a ^ | b a = requests for control info a ^ | b 501 | | b = control information | | 502 | v | v 503 ------- ------- 504 | C | ------ request -------------------> | RS | 505 | | <----- response ------------------- | | 506 ------- ------- 508 Figure 7: Information flows that need to be protected 510 o We assume that the necessary keys/credentials for protecting the 511 control information between the potentially constrained nodes and 512 their associated less-constrained nodes are pre-established, for 513 example as part of the commissioning procedure. 515 o Any necessary keys/credentials for protecting the interaction 516 between the potentially constrained nodes will need to be 517 established and maintained as part of a solution. 519 In terms of the elements of the architecture laid out above, this 520 document's problem statement for authorization in constrained 521 environments can then be summarized as follows: 523 o The interaction between potentially constrained endpoints is 524 controlled by control information provided by less-constrained 525 nodes on behalf of the principals of the endpoints. 527 o The interaction between the endpoints needs to be secured, as well 528 as the establishment of the necessary keys for securing the 529 interaction, potentially end-to-end through intermediary nodes. 531 o The mechanism for transferring control information needs to be 532 secured, potentially end-to-end through intermediary nodes. Pre- 533 established keying material may need to be employed for 534 establishing the keys used to protect these information flows. 536 (Note that other aspects relevant to secure constrained node 537 communication such as secure bootstrap or group communication are not 538 specifically addressed by the present document.) 540 3. Security Objectives 542 The security objectives that are addressed by an authorization 543 solution include confidentiality and integrity. Additionally, 544 allowing only selected operations by selected entities limits the 545 burden on system resources, thus helping to achieve availability. 546 Misconfigured or wrongly designed authorization solutions can result 547 in availability breaches (denial of service): Users might no longer 548 be able to use data and services as they are supposed to. 550 Authentication mechanisms can help achieve additional security 551 objectives such as accountability and third-party verifiability. 552 These additional objectives are not directly related to authorization 553 and thus are not in scope of this draft, but may nevertheless be 554 relevant. Accountability and third-party verifiability may require 555 authentication on a device level, if it is necessary to determine 556 which device performed an action. In other cases it may be more 557 important to find out who is responsible for the device's actions. 558 (The ensuing requirements for logging, auditability, and the related 559 integrity requirements are very relevant for constrained devices as 560 well, but outside the scope of this document.) See also Section 4 561 for more discussion about authentication and authorization. 563 The security objectives and their relative importance differ for the 564 various constrained environment applications and use cases [RFC7744]. 566 The architecture is based on the observation that different parties 567 may have different security objectives. There may also be a 568 "collaborative" dimension: to achieve a security objective of one 569 party, another party may be required to provide a service. For 570 example, if RqP requires the integrity of representations of a 571 resource R that RS is hosting, both C and RS need to partake in 572 integrity-protecting the transmitted data. Moreover, RS needs to 573 protect any write access to this resource as well as to relevant 574 other resources (such as configuration information, firmware update 575 resources) to prevent unauthorized users from manipulating R. 577 3.1. End-to-End Security Objectives in Multi-Hop Scenarios 579 In many cases, the information flows described in Section 2.3 cross 580 multiple client-server pairings but still need to be protected end- 581 to-end. For example, AS may not be connected to RS (or may not want 582 to exercise such a connection), relying on C for transferring 583 authorization information. As the authorization information is 584 related to the permissions granted to C, C must not be in a position 585 to manipulate this information, which therefore requires integrity 586 protection on the way between AS and RS. 588 As another example, resource representations sent between endpoints 589 may be stored in intermediary nodes, such as caching proxies or pub- 590 sub brokers. Where these intermediaries cannot be relied on to 591 fulfill the security objectives of the endpoints, it is the endpoints 592 that will need to protect the exchanges beyond a single client-server 593 exchange. 595 Note that there may also be cases of intermediary nodes that very 596 much partake in the security objectives to be achieved. The question 597 what are the pairs of endpoints between which the communication needs 598 end-to-end protection (and which aspect of protection) is defined by 599 the specific use case. Two examples of intermediary nodes executing 600 security functionality: 602 o To enable a trustworthy publication service, a pub-sub broker may 603 be untrusted with the plaintext content of a publication 604 (confidentiality), but required to verify that the publication is 605 performed by claimed publisher and is not a replay of an old 606 publication (authenticity/integrity). 608 o To comply with requirements of transparency, a gateway may be 609 allowed to read, verify (authenticity) but not modify (integrity) 610 a resource representation which therefore also is end-to-end 611 integrity protected from the server towards a client behind the 612 gateway. 614 In order to support the required communication and application 615 security, keying material needs to be established between the 616 relevant nodes in the architecture. 618 4. Authentication and Authorization 620 Server-side authorization solutions aim at protecting the access to 621 items of interest, for instance hardware or software resources or 622 data: They enable the resource owner to control who can access it and 623 how. 625 To determine if an entity is authorized to access a resource, an 626 authentication mechanism is needed. According to the Internet 627 Security Glossary [RFC4949], authentication is "the process of 628 verifying a claim that a system entity or system resource has a 629 certain attribute value." Examples for attribute values are the ID 630 of a device, the type of the device or the name of its owner. 632 The security objectives the authorization mechanism aims at can only 633 be achieved if the authentication and the authorization mechanism 634 work together correctly. We speak of authenticated authorization to 635 refer to the required synthesis of mechanisms for authentication and 636 authorization. 638 Where used for authorization, the set of authenticated attributes 639 must be meaningful for this purpose, i.e., authorization decisions 640 must be possible based on these attributes. If the authorization 641 policy assigns permissions to an individual entity, the set of 642 authenticated attributes must be suitable to uniquely identify this 643 entity. 645 In other scenarios, there is often less need to uniquely identify an 646 individual device: For a principal, the fact that a device belongs to 647 a certain company or that it has a specific type (such as a light 648 bulb) or location may be more important than that it has a unique 649 identifier. 651 (As a special case for the authorization of read access to a 652 resource, RS may simply make an encrypted representation available to 653 anyone [OSCAR]. In this case, controlling read access to that 654 resource can be reduced to controlling read access to the key; 655 partially removing future access also requires a timely update of the 656 key for RS and all participants still authorized.) 657 Principals (RqP and RO) need to decide about the required level of 658 granularity for the authorization. For example, we distinguish 659 device authorization from owner authorization, and flat authorization 660 from unrestricted authorization. In the first case different access 661 permissions are granted to individual devices while in the second 662 case individual owners are authorized. If flat authorization is 663 used, all authenticated entities are implicitly authorized and have 664 the same access permissions. Unrestricted authorization for an item 665 of interest means that no authorization mechanism is used for 666 accessing this resource (not even by authentication) and all entities 667 are able to access the item as they see fit (note that an 668 authorization mechanism may still be used to arrive at the decision 669 to employ unrestricted authorization). 671 +-----------------+-------------------------------------------------+ 672 | Authorization | Authorization is contingent on: | 673 | granularity | | 674 +-----------------+-------------------------------------------------+ 675 | device | authentication of specific device | 676 | | | 677 | owner | (authenticated) authorization by owner | 678 | | | 679 | flat | (any) authentication | 680 | | | 681 | unrestricted | (unrestricted access; access always authorized) | 682 +-----------------+-------------------------------------------------+ 684 Table 1: Some granularity levels for authorization 686 More fine-grained authorization does not necessarily provide more 687 security but can be more flexible. Principals need to consider that 688 an entity should only be granted the permissions it really needs 689 (principle of least privilege), to ensure the confidentiality and 690 integrity of resources. 692 Client-side authorization solutions aim at protecting the client from 693 disclosing information to or ingesting information from resource 694 servers RqP does not want it to interact with in the given way. 695 Again, flat authorization (the server can be authenticated) may be 696 sufficient, or more fine-grained authorization may be required. The 697 client-side authorization also pertains to the level of protection 698 required for the exchanges with the server (e.g., confidentiality). 699 In the browser web, client-side authorization is often left to the 700 human user; a constrained client may not have that available all the 701 time but still needs to implement the wishes of the principal 702 controlling it, the RqP. 704 For the cases where an authorization solution is needed (all but 705 unrestricted authorization), the enforcing party needs to be able to 706 authenticate the party that is to be authorized. Authentication is 707 therefore required for messages that contain (or otherwise update) 708 representations of an accessed item. More precisely: The enforcing 709 party needs to make sure that the receiver of a message containing a 710 representation is authorized to receive it, both in the case of a 711 client sending a representation to a server and vice versa. In 712 addition, it needs to ensure that the actual sender of a message 713 containing a representation is indeed the one authorized to send this 714 message, again for both the client-to-server and server-to-client 715 case. To achieve this, integrity protection of these messages is 716 required: Authenticity of the message cannot be assured if it is 717 possible for an attacker to modify it during transmission. 719 In some cases, only one side (client or server side) requires the 720 integrity and / or confidentiality of a resource value. Principals 721 may decide to omit authentication (unrestricted authorization), or 722 use flat authorization (just employing an authentication mechanism). 723 However, as indicated in Section 3, the security objectives of both 724 sides must be considered, which can often only be achieved when the 725 other side can be relied on to perform some security service. 727 5. Actors and their Tasks 729 This and the following section look at the resulting architecture 730 from two different perspectives: This section provides a more 731 detailed description of the various "actors" in the architecture, the 732 logical functional entities performing the tasks required. The 733 following section then will focus on the protocols run between these 734 functional entities. 736 For the purposes of this document, an actor consists of a set of 737 tasks and additionally has a security domain (client domain or server 738 domain) and a level (constrained, principal, less-constrained). 739 Tasks are assigned to actors according to their security domain and 740 required level. 742 Note that actors are a concept to understand the security 743 requirements for constrained devices. The architecture of an actual 744 solution might differ as long as the security requirements that 745 derive from the relationship between the identified actors are 746 considered. Several actors might share a single device or even be 747 combined in a single piece of software. Interfaces between actors 748 may be realized as protocols or be internal to such a piece of 749 software. 751 A more detailed discussion of the tasks the actors have to perform in 752 order to achieve specific security objectives is provided in 753 [I-D.gerdes-ace-tasks]. 755 5.1. Constrained Level Actors 757 As described in the problem statement (see Section 2), either C or RS 758 or both of them may be located on a constrained node. We therefore 759 define that C and RS must be able to perform their tasks even if they 760 are located on a constrained node. Thus, C and RS are considered to 761 be Constrained Level Actors. 763 C performs the following tasks: 765 o Communicate in a secure way (provide for confidentiality and 766 integrity of messages), including access requests. 768 o Validate that the RqP ("client-side") authorization information 769 allows C to communicate with RS as a server for R (i.e., from C's 770 point of view, RS is authorized as a server for the specific 771 access to R). 773 RS performs the following tasks: 775 o Communicate in a secure way (provide for confidentiality and 776 integrity of messages), including responses to access requests. 778 o Validate that the RO ("server-side") authorization information 779 allows RS to grant C access to the requested resource as requested 780 (i.e., from RS' point of view, C is authorized as a client for the 781 specific access to R). 783 R is an item of interest such as a sensor or actuator value. R is 784 considered to be part of RS and not a separate actor. The device on 785 which RS is located might contain several resources controlled by 786 different ROs. For simplicity of exposition, these resources are 787 described as if they had separate RS. 789 As C and RS do not necessarily know each other they might belong to 790 different security domains. 792 (See Figure 8.) 793 ------- -------- 794 | C | -- requests resource ---> | RS | Constrained Level 795 ------- <-- provides resource--- -------- 797 Figure 8: Constrained Level Actors 799 5.2. Principal Level Actors 801 Our objective is that C and RS are under control of principals in the 802 physical world, the Requesting Party (RqP) and the Resource Owner 803 (RO) respectively. The principals decide about the security policies 804 of their respective endpoints and belong to the same security domain. 806 RqP is in charge of C, i.e. RqP specifies security policies for C, 807 such as with whom C is allowed to communicate. By definition, C and 808 RqP belong to the same security domain. 810 RqP must fulfill the following task: 812 o Configure for C authorization information for sources for R. 814 RO is in charge of R and RS. RO specifies authorization policies for 815 R and decides with whom RS is allowed to communicate. By definition, 816 R, RS and RO belong to the same security domain. 818 RO must fulfill the following task: 820 o Configure for RS authorization information for accessing R. 822 (See Figure 2.) 824 5.3. Less-Constrained Level Actors 826 Constrained level actors can only fulfill a limited number of tasks 827 and may not have network connectivity all the time. To relieve them 828 from having to manage keys for numerous endpoints and conducting 829 computationally intensive tasks, another complexity level for actors 830 is introduced. An actor on the less-constrained level belongs to the 831 same security domain as its respective constrained level actor. They 832 also have the same principal. 834 The Client Authorization Server (CAS) belongs to the same security 835 domain as C and RqP. CAS acts on behalf of RqP. It assists C in 836 authenticating RS and determining if RS is an authorized server for 837 R. CAS can do that because for C, CAS is the authority for claims 838 about RS. 840 CAS performs the following tasks: 842 o Validate on the client side that an entity has certain attributes. 844 o Obtain authorization information about an entity from C's 845 principal (RqP) and provide it to C. 847 o Negotiate means for secure communication to communicate with C. 849 The Authorization Server (AS) belongs to the same security domain as 850 R, RS and RO. AS acts on behalf of RO. It supports RS by 851 authenticating C and determining C's permissions on R. AS can do 852 that because for RS, AS is the authority for claims about C. 854 AS performs the following tasks: 856 o Validate on the server side that an entity has certain attributes. 858 o Obtain authorization information about an entity from RS' 859 principal (RO) and provide it to RS. 861 o Negotiate means for secure communication to communicate with RS. 863 6. Kinds of Protocols 865 Devices on the less-constrained level potentially are more powerful 866 than constrained level devices in terms of processing power, memory, 867 non-volatile storage. This results in different characteristics for 868 the protocols used on these levels. 870 6.1. Constrained Level Protocols 872 A protocol is considered to be on the constrained level if it is used 873 between the actors C and RS which are considered to be constrained 874 (see Section 5.1). C and RS might not belong to the same security 875 domain. Therefore, constrained level protocols need to work between 876 different security domains. 878 Commonly used Internet protocols can not in every case be applied to 879 constrained environments. In some cases, tweaking and profiling is 880 required. In other cases it is beneficial to define new protocols 881 which were designed with the special characteristics of constrained 882 environments in mind. 884 On the constrained level, protocols need to address the specific 885 requirements of constrained environments. Examples for protocols 886 that consider these requirements is the transfer protocol CoAP 887 (Constrained Application Protocol) [RFC7252] and the Datagram 888 Transport Layer Security Protocol (DTLS) [RFC6347] which can be used 889 for channel security. 891 Constrained devices have only limited storage space and thus cannot 892 store large numbers of keys. This is especially important because 893 constrained networks are expected to consist of thousands of nodes. 894 Protocols on the constrained level should keep this limitation in 895 mind. 897 6.1.1. Cross Level Support Protocols 899 Protocols which operate between a constrained device on one side and 900 the corresponding less-constrained device on the other are considered 901 to be (cross level) support protocols. Protocols used between C and 902 CAS or RS and AS are therefore support protocols. 904 Support protocols must consider the limitations of their constrained 905 endpoint and therefore belong to the constrained level protocols. 907 6.2. Less-Constrained Level Protocols 909 A protocol is considered to be on the less-constrained level if it is 910 used between the actors CAS and AS. CAS and AS might belong to 911 different security domains. 913 On the less-constrained level, HTTP [RFC7230] and Transport Layer 914 Security (TLS) [RFC5246] can be used alongside or instead of CoAP and 915 DTLS. Moreover, existing security solutions for authentication and 916 authorization such as the OAuth web authorization framework [RFC6749] 917 and Kerberos [RFC4120] can likely be used without modifications and 918 there are no limitations for the use of a Public Key Infrastructure 919 (PKI). 921 7. Elements of a Solution 923 Without anticipating specific solutions, the following considerations 924 may be helpful in discussing them. 926 7.1. Authorization 928 The core problem we are trying to solve is authorization. The 929 following problems related to authorization need to be addressed: 931 o AS needs to transfer authorization information to RS and CAS needs 932 to transfer authorization information to C. 934 o The transferred authorization information needs to follow a 935 defined format and encoding, which must be efficient for 936 constrained devices, considering size of authorization information 937 and parser complexity. 939 o C and RS need to be able to verify the authenticity of the 940 authorization information they receive. Here as well, there is a 941 trade-off between processing complexity and deployment complexity. 943 o The RS needs to enforce the authorization decisions of the AS, 944 while C needs to abide with the authorization decisions of the 945 CAS. The authorization information might require additional 946 policy evaluation (such as matching against local access control 947 lists, evaluating local conditions). The required "policy 948 evaluation" at the constrained actors needs to be adapted to the 949 capabilities of the devices implementing them. 951 o Finally, as is indicated in the previous bullet, for a particular 952 authorization decision there may be different kinds of 953 authorization information needed, and these pieces of information 954 may be transferred to C and RS at different times and in different 955 ways prior to or during the client request. 957 7.2. Authentication 959 The following problems need to be addressed, when considering 960 authentication: 962 o RS needs to authenticate AS, and C needs to authenticate CAS, to 963 ensure that the authorization information and related data comes 964 from the correct source. 966 o CAS and AS may need to authenticate each other, both to perform 967 the required business logic and to ensure that CAS gets security 968 information related to the resources from the right source. 970 o In some use cases RS needs to authenticate some property of C, in 971 order to map it to the relevant authorization information. In 972 other applications, authentication and authorization of C may be 973 implicit, for example by encrypting the resource representation 974 the RS only providing access to those who possess the key to 975 decrypt. 977 o C may need to authenticate RS, in order to ensure that it is 978 interacting with the right resources. Alternatively C may just 979 verify the integrity of a received resource representation. 981 o CAS and AS need to authenticate their communication partner (C or 982 RS), in order to ensure it serves the correct device. 984 7.3. Communication Security 986 There are different alternatives to provide communication security, 987 and the problem here is to choose the optimal one for each scenario. 988 We list the available alternatives: 990 o Session-based security at transport layer such as DTLS [RFC6347] 991 offers security, including integrity and confidentiality 992 protection, for the whole application layer exchange. However, 993 DTLS may not provide end-to-end security over multiple hops. 994 Another problem with DTLS is the cost of the handshake protocol, 995 which may be too expensive for constrained devices especially in 996 terms of memory and power consumption for message transmissions. 998 o An alternative is object security at application layer, for 999 instance using [I-D.ietf-core-object-security]. Secure objects 1000 can be stored or cached in network nodes and provide security for 1001 a more flexible communication model such as publish/subscribe 1002 (compare e.g. CoRE Mirror Server [I-D.koster-core-coap-pubsub]). 1003 A problem with object security is that it can not provide 1004 confidentiality for the message headers. 1006 o Hybrid solutions using both session-based and object security are 1007 also possible. An example of a hybrid is where authorization 1008 information and cryptographic keys are provided by AS in the 1009 format of secure data objects, but where the resource access is 1010 protected by session-based security. 1012 7.4. Cryptographic Keys 1014 With respect to cryptographic keys, we see the following problems 1015 that need to be addressed: 1017 Symmetric vs Asymmetric Keys 1018 We need keys both for protection of resource access and for 1019 protection of transport of authentication and authorization 1020 information. Do we want to support solutions based on asymmetric 1021 keys or symmetric keys in both cases? There are classes of 1022 devices that can easily perform symmetric cryptography, but 1023 consume considerably more time/battery for asymmetric operations. 1024 On the other hand asymmetric cryptography has benefits such as in 1025 terms of deployment. 1027 Key Establishment 1028 How are the corresponding cryptographic keys established? 1029 Considering Section 7.1 there must be a mapping between these keys 1030 and the authorization information, at least in the sense that AS 1031 must be able to specify a unique client identifier which RS can 1032 verify (using an associated key). One of the use cases of 1033 [RFC7744] describes spontaneous change of access policies - such 1034 as giving a hitherto unknown client the right to temporarily 1035 unlock your house door. In this case C is not previously known to 1036 RS and a key must be provisioned by AS. 1038 Revocation and Expiration 1039 How are keys replaced and how is a key that has been compromised 1040 revoked in a manner that reaches all affected parties, also 1041 keeping in mind scenarios with intermittent connectivity? 1043 8. Assumptions and Requirements 1045 In this section we list a set of candidate assumptions and 1046 requirements to make the problem description in the previous sections 1047 more concise and precise. 1049 8.1. Architecture 1051 The architecture consists of at least the following types of nodes: 1053 o RS hosting resources, and responding to access requests 1055 o C requesting access to resources 1057 o AS supporting the access request/response procedure by providing 1058 authorization information to RS 1060 * AS may support this by aiding RS in authenticating C, or 1061 providing cryptographic keys or credentials to C and/or RS to 1062 secure the request/response procedure. 1064 o CAS supporting the access request/response procedure by providing 1065 authorization information to C 1067 * CAS may support this by aiding C in authenticating RS, 1068 forwarding information between AS and C (possibly ultimately 1069 for RS), or providing cryptographic keys or credentials to C 1070 and/or RS to secure the request/response procedure. 1072 o The architecture allows for intermediary nodes between any pair of 1073 C, RS, AS, and CAS, such as forward or reverse proxies in the CoRE 1074 architecture. (Solutions may or may not support all 1075 combinations.) 1077 * The architecture does not make a choice between session based 1078 security and data object security. 1080 8.2. Constrained Devices 1082 o C and/or RS may be constrained in terms of power, processing, 1083 communication bandwidth, memory and storage space, and moreover: 1085 * unable to manage complex authorization policies 1087 * unable to manage a large number of secure connections 1089 * without user interface 1091 * without constant network connectivity 1093 * unable to precisely measure time 1095 * required to save on wireless communication due to high power 1096 consumption 1098 o CAS and AS are not assumed to be constrained devices. 1100 o All devices under consideration can process symmetric cryptography 1101 without incurring an excessive performance penalty. 1103 * We assume the use of a standardized symmetric key algorithm, 1104 such as AES. 1106 * Except for the most constrained devices we assume the use of a 1107 standardized cryptographic hash function such as SHA-256 (which 1108 can be used with the HMAC construction for integrity 1109 protection). 1111 o Public key cryptography requires additional resources (such as 1112 RAM, ROM, power, specialized hardware). 1114 o A DTLS handshake involves significant computation, communication, 1115 and memory overheads in the context of constrained devices. 1117 * The RAM requirements of DTLS handshakes with public key 1118 cryptography are prohibitive for certain constrained devices. 1120 * Certificate-based DTLS handshakes require significant volumes 1121 of communication, RAM (message buffers) and computation. 1123 o A solution will need to consider support for a simple scheme for 1124 expiring authentication and authorization information on devices 1125 which are unable to measure time (cf. Section 9.2). 1127 8.3. Authentication 1129 o RS needs to authenticate AS to ensure that the authorization 1130 information and related data comes from the correct source. 1132 o Similarly, C needs to authenticate CAS to ensure that the 1133 authorization information and related data comes from the correct 1134 source. 1136 o Depending on use case and authorization requirements, C, RS, CAS, 1137 or AS may need to authenticate messages from each other. 1139 8.4. Server-side Authorization 1141 o RS enforces authorization for access to a resource based on 1142 credentials presented by C, the requested resource, the REST 1143 method, and local context in RS at the time of the request, or on 1144 any subset of this information. 1146 o The credentials presented by C may have been provided by CAS. 1148 o The underlying authorization decision is taken either by AS or RS. 1150 o The authorization decision is enforced by RS. 1152 * RS needs to have authorization information in order to verify 1153 that C is allowed to access the resource as requested. 1155 * RS needs to make sure that it provides resource access only to 1156 authorized clients. 1158 o Apart from authorization for access to a resource, authorization 1159 may also be required for access to information about a resource 1160 (for instance, resource descriptions). 1162 o The solution may need to be able to support the delegation of 1163 access rights. 1165 8.5. Client-side Authorization Information 1167 o C enforces client-side authorization by protecting its requests to 1168 RS and by authenticating results from RS, making use of decisions 1169 and policies as well as keying material provided by CAS. 1171 8.6. Server-side Authorization Information 1173 o Authorization information is transferred from AS to RS using 1174 Agent, Push or Pull mechanisms [RFC2904]. 1176 o RS needs to authenticate that the authorization information is 1177 coming from AS (integrity). 1179 o The authorization information may also be encrypted end-to-end 1180 between AS and RS (confidentiality). 1182 o The architecture supports the case where RS may not be able to 1183 communicate with AS at the time of the request from C. 1185 o RS may store or cache authorization information. 1187 o Authorization information may be pre-configured in RS. 1189 o Authorization information stored or cached in RS needs to be 1190 possible to change. The change of such information needs to be 1191 subject to authorization. 1193 o Authorization policies stored on RS may be handled as a resource, 1194 i.e. information located at a particular URI, accessed with 1195 RESTful methods, and the access being subject to the same 1196 authorization mechanics. AS may have special privileges when 1197 requesting access to the authorization policy resources on RS. 1199 o There may be mechanisms for C to look up the AS which provides 1200 authorization information about a particular resource. 1202 8.7. Resource Access 1204 o Resources are accessed in a RESTful manner using methods such as 1205 GET, PUT, POST, DELETE. 1207 o By default, the resource request needs to be integrity protected 1208 and may be encrypted end-to-end from C to RS. It needs to be 1209 possible for RS to detect a replayed request. 1211 o By default, the response to a request needs to be integrity 1212 protected and may be encrypted end-to-end from RS to C. It needs 1213 to be possible for C to detect a replayed response. 1215 o RS needs to be able to verify that the request comes from an 1216 authorized client. 1218 o C needs to be able to verify that the response to a request comes 1219 from the intended RS. 1221 o There may be resources whose access need not be protected (e.g. 1222 for discovery of the responsible AS). 1224 8.8. Keys and Cipher Suites 1226 o A constrained node and its authorization manager (i.e., RS and AS, 1227 and C and CAS) have established cryptographic keys. For example, 1228 they share a secret key or each have the other's public key. 1230 o The transfer of authorization information is protected with 1231 symmetric and/or asymmetric keys. 1233 o The access request/response can be protected with symmetric and/or 1234 asymmetric keys. 1236 o There must be a mechanism for RS to establish the necessary key(s) 1237 to verify and decrypt the request and to protect the response. 1239 o There must be a mechanism for C to establish the necessary key(s) 1240 to protect the request and to verify and decrypt the response. 1242 o There must be a mechanism for C to obtain the supported cipher 1243 suites of a RS. 1245 8.9. Network Considerations 1247 o A solution will need to consider network overload due to avoidable 1248 communication of a constrained node with its authorization manager 1249 (C with CAS, RS with AS). 1251 o A solution will need to consider network overload by compact 1252 authorization information representation. 1254 o A solution may want to optimize the case where authorization 1255 information does not change often. 1257 o A solution may consider support for an efficient mechanism for 1258 providing authorization information to multiple RSs, for example 1259 when multiple entities need to be configured or change state. 1261 8.10. Legacy Considerations 1263 o A solution may consider interworking with existing infrastructure. 1265 o A solution may consider supporting authorization of access to 1266 legacy devices. 1268 9. Security Considerations 1270 This document discusses authorization-related tasks for constrained 1271 environments and describes how these tasks can be mapped to actors in 1272 the architecture. 1274 The entire document is about security. Security considerations 1275 applicable to authentication and authorization in RESTful 1276 environments are provided in e.g. OAuth 2.0 [RFC6749]. 1278 In this section we focus on specific security aspects related to 1279 authorization in constrained-node networks. Section 11.6 of 1280 [RFC7252], "Constrained node considerations", discusses implications 1281 of specific constraints on the security mechanisms employed. A wider 1282 view of security in constrained-node networks is provided in 1283 [I-D.garcia-core-security]. 1285 9.1. Physical Attacks on Sensor and Actuator Networks 1287 The focus of this work is on constrained-node networks consisting of 1288 connected sensors and actuators. The main function of such devices 1289 is to interact with the physical world by gathering information or 1290 performing an action. We now discuss attacks performed with physical 1291 access to such devices. 1293 The main threats to sensors and actuator networks are: 1295 o Unauthorized access to data to and from sensors and actuators, 1296 including eavesdropping and manipulation of data. 1298 o Denial-of-service making the sensor/actuator unable to perform its 1299 intended task correctly. 1301 A number of attacks can be made with physical access to a device 1302 including probing attacks, timing attacks, power attacks, etc. 1303 However, with physical access to a sensor or actuator device it is 1304 possible to directly perform attacks equivalent of eavesdropping, 1305 manipulating data or denial of service. For example: 1307 o Instead of eavesdropping the sensor data or attacking the 1308 authorization system to gain access to the data, the attacker 1309 could make its own measurements on the physical object. 1311 o Instead of manipulating the sensor data the attacker could change 1312 the physical object which the sensor is measuring, thereby 1313 changing the payload data which is being sent. 1315 o Instead of manipulating data for an actuator or attacking the 1316 authorization system, the attacker could perform an unauthorized 1317 action directly on the physical object. 1319 o A denial-of-service attack could be performed physically on the 1320 object or device. 1322 All these attacks are possible by having physical access to the 1323 device, since the assets are related to the physical world. 1324 Moreover, this kind of attacks are in many cases straightforward 1325 (requires no special competence or tools, low cost given physical 1326 access, etc.) 1328 As a conclusion, if an attacker has full physical access to a 1329 sensor or actuator device, then much of the security functionality 1330 elaborated in this draft is not effective to protect the asset 1331 during the physical attack. 1333 Since it does not make sense to design a solution for a situation 1334 that cannot be protected against we assume there is no need to 1335 protect assets which are exposed during a physical attack. In 1336 other words, either an attacker does not have physical access to 1337 the sensor or actuator device, or if it has, the attack shall only 1338 have effect during the period of physical attack, and shall be 1339 limited in extent to the physical control the attacker exerts 1340 (e.g., must not affect the security of other devices.) 1342 9.2. Clocks and Time Measurements 1344 Measuring time and keeping wall-clock time with certain accuracy is 1345 important to achieve certain security properties, for example to 1346 determine whether a public key certificate, access token, or some 1347 other assertion, is valid. 1349 Dynamic authorization in itself requires the ability to handle expiry 1350 or revocation of authorization decisions or to distinguish new 1351 authorization decisions from old. 1353 For certain categories of devices we can assume that there is an 1354 internal clock which is sufficiently accurate to handle the time 1355 measurement requirements. If RS can connect directly to AS, this 1356 relationship can be used to update RS in terms of time, removing some 1357 uncertainty, as well as to directly provide revocation information, 1358 removing authorizations that are no longer desired. 1360 If RS continuously measures time but can't connect to AS or another 1361 trusted source of time, time drift may have to be accepted and it may 1362 be harder to manage revocation. However, it may still be able to 1363 handle short lived access rights within some margins, by measuring 1364 the time since arrival of authorization information or request. 1366 Some categories of devices in scope may be unable measure time with 1367 any accuracy (e.g. because of sleep cycles). This category of 1368 devices is not suitable for the use cases which require measuring 1369 validity of assertions and authorizations in terms of absolute time. 1371 10. IANA Considerations 1373 This document has no actions for IANA. 1375 11. Informative References 1377 [HUM14delegation] 1378 Hummen, R., Shafagh, H., Raza, S., Voigt, T., and K. 1379 Wehrle, "Delegation-based Authentication and Authorization 1380 for the IP-based Internet of Things", 11th IEEE 1381 International Conference on Sensing, Communication, and 1382 Networking (SECON'14), June 30 - July 3, 2014. 1384 [I-D.garcia-core-security] 1385 Garcia-Morchon, O., Kumar, S., Keoh, S., Hummen, R., and 1386 R. Struik, "Security Considerations in the IP-based 1387 Internet of Things", draft-garcia-core-security-06 (work 1388 in progress), September 2013. 1390 [I-D.gerdes-ace-tasks] 1391 Gerdes, S., "Authorization-Related Tasks in Constrained 1392 Environments", draft-gerdes-ace-tasks-00 (work in 1393 progress), September 2015. 1395 [I-D.hardjono-oauth-umacore] 1396 Hardjono, T., Maler, E., Machulak, M., and D. Catalano, 1397 "User-Managed Access (UMA) Profile of OAuth 2.0", draft- 1398 hardjono-oauth-umacore-14 (work in progress), January 1399 2016. 1401 [I-D.ietf-core-object-security] 1402 Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 1403 "Object Security of CoAP (OSCOAP)", draft-ietf-core- 1404 object-security-01 (work in progress), December 2016. 1406 [I-D.koster-core-coap-pubsub] 1407 Koster, M., Keranen, A., and J. Jimenez, "Publish- 1408 Subscribe Broker for the Constrained Application Protocol 1409 (CoAP)", draft-koster-core-coap-pubsub-05 (work in 1410 progress), July 2016. 1412 [OSCAR] Vucinic, M., Tourancheau, B., Rousseau, F., Duda, A., 1413 Damon, L., and R. Guizzetti, "OSCAR: Object Security 1414 Architecture for the Internet of Things", CoRR vol. 1415 abs/1404.7799, 2014. 1417 [REST] Fielding, R. and R. Taylor, "Principled design of the 1418 modern Web architecture", ACM Trans. Inter. Tech. Vol. 1419 2(2), pp. 115-150, DOI 10.1145/514183.514185, May 2002. 1421 [RFC2904] Vollbrecht, J., Calhoun, P., Farrell, S., Gommans, L., 1422 Gross, G., de Bruijn, B., de Laat, C., Holdrege, M., and 1423 D. Spence, "AAA Authorization Framework", RFC 2904, 1424 DOI 10.17487/RFC2904, August 2000, 1425 . 1427 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The 1428 Kerberos Network Authentication Service (V5)", RFC 4120, 1429 DOI 10.17487/RFC4120, July 2005, 1430 . 1432 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", 1433 FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, 1434 . 1436 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1437 (TLS) Protocol Version 1.2", RFC 5246, 1438 DOI 10.17487/RFC5246, August 2008, 1439 . 1441 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1442 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 1443 January 2012, . 1445 [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", 1446 RFC 6749, DOI 10.17487/RFC6749, October 2012, 1447 . 1449 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 1450 Constrained-Node Networks", RFC 7228, 1451 DOI 10.17487/RFC7228, May 2014, 1452 . 1454 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 1455 Protocol (HTTP/1.1): Message Syntax and Routing", 1456 RFC 7230, DOI 10.17487/RFC7230, June 2014, 1457 . 1459 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 1460 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 1461 DOI 10.17487/RFC7231, June 2014, 1462 . 1464 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 1465 Application Protocol (CoAP)", RFC 7252, 1466 DOI 10.17487/RFC7252, June 2014, 1467 . 1469 [RFC7744] Seitz, L., Ed., Gerdes, S., Ed., Selander, G., Mani, M., 1470 and S. Kumar, "Use Cases for Authentication and 1471 Authorization in Constrained Environments", RFC 7744, 1472 DOI 10.17487/RFC7744, January 2016, 1473 . 1475 Acknowledgements 1477 The authors would like to thank Olaf Bergmann, Robert Cragie, Samuel 1478 Erdtman, Klaus Hartke, Sandeep Kumar, John Mattson, Corinna Schmitt, 1479 Mohit Sethi, Abhinav Somaraju, Hannes Tschofenig, Vlasios Tsiatsis 1480 and Erik Wahlstroem for contributing to the discussion, giving 1481 helpful input and commenting on previous forms of this draft. The 1482 authors would also like to specifically acknowledge input provided by 1483 Hummen and others [HUM14delegation]. Robin Wilton provided extensive 1484 editorial comments that were the basis for significant improvements 1485 of the text. 1487 Authors' Addresses 1489 Stefanie Gerdes 1490 Universitaet Bremen TZI 1491 Postfach 330440 1492 Bremen D-28359 1493 Germany 1495 Phone: +49-421-218-63906 1496 Email: gerdes@tzi.org 1497 Ludwig Seitz 1498 SICS Swedish ICT AB 1499 Scheelevaegen 17 1500 Lund 223 70 1501 Sweden 1503 Email: ludwig@sics.se 1505 Goeran Selander 1506 Ericsson 1507 Faroegatan 6 1508 Kista 164 80 1509 Sweden 1511 Email: goran.selander@ericsson.com 1513 Carsten Bormann (editor) 1514 Universitaet Bremen TZI 1515 Postfach 330440 1516 Bremen D-28359 1517 Germany 1519 Phone: +49-421-218-63921 1520 Email: cabo@tzi.org