idnits 2.17.1 draft-gerdes-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 (March 25, 2015) is 3312 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-14) exists of draft-hardjono-oauth-umacore-12 == Outdated reference: A later version (-10) exists of draft-ietf-ace-usecases-03 == Outdated reference: A later version (-05) exists of draft-koster-core-coap-pubsub-01 == Outdated reference: A later version (-06) exists of draft-selander-ace-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 (~~), 5 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 26, 2015 SICS Swedish ICT AB 6 G. Selander 7 Ericsson 8 C. Bormann, Ed. 9 Universitaet Bremen TZI 10 March 25, 2015 12 Actors in the ACE Architecture 13 draft-gerdes-ace-actors-04 15 Abstract 17 Constrained nodes are small devices which are limited in terms of 18 processing power, memory, non-volatile storage and transmission 19 capacity. Due to these constraints, commonly used security protocols 20 are not easily applicable. Nevertheless, an authentication and 21 authorization solution is needed to ensure the security of these 22 devices. 24 Due to the limitations of the constrained nodes it is especially 25 important to develop a light-weight security solution which is 26 adjusted to the relevant security objectives of each participating 27 party in this environment. Necessary security measures must be 28 identified and applied where needed. 30 This document gives an overview of the necessary terminology and 31 introduces the actors in an architecture as guidance for the 32 development of authentication and authorization solutions for 33 constrained environments. The actors represent the relationships 34 between the logical functional entities involved. 36 We also present a problem description for authentication and 37 authorization in constrained-node networks, i.e. networks where some 38 devices have severe constraints on memory, processing, power and 39 communication bandwidth. 41 Status of This Memo 43 This Internet-Draft is submitted in full conformance with the 44 provisions of BCP 78 and BCP 79. 46 Internet-Drafts are working documents of the Internet Engineering 47 Task Force (IETF). Note that other groups may also distribute 48 working documents as Internet-Drafts. The list of current Internet- 49 Drafts is at http://datatracker.ietf.org/drafts/current/. 51 Internet-Drafts are draft documents valid for a maximum of six months 52 and may be updated, replaced, or obsoleted by other documents at any 53 time. It is inappropriate to use Internet-Drafts as reference 54 material or to cite them other than as "work in progress." 56 This Internet-Draft will expire on September 26, 2015. 58 Copyright Notice 60 Copyright (c) 2015 IETF Trust and the persons identified as the 61 document authors. All rights reserved. 63 This document is subject to BCP 78 and the IETF Trust's Legal 64 Provisions Relating to IETF Documents 65 (http://trustee.ietf.org/license-info) in effect on the date of 66 publication of this document. Please review these documents 67 carefully, as they describe your rights and restrictions with respect 68 to this document. Code Components extracted from this document must 69 include Simplified BSD License text as described in Section 4.e of 70 the Trust Legal Provisions and are provided without warranty as 71 described in the Simplified BSD License. 73 Table of Contents 75 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 76 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 77 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4 78 3. Security Objectives . . . . . . . . . . . . . . . . . . . . . 5 79 4. Authentication and Authorization . . . . . . . . . . . . . . 6 80 5. Autonomous Communication . . . . . . . . . . . . . . . . . . 7 81 6. Actors . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 82 6.1. Constrained Level Actors . . . . . . . . . . . . . . . . 8 83 6.2. Principal Level Actors . . . . . . . . . . . . . . . . . 9 84 6.3. Less-Constrained Level Actors . . . . . . . . . . . . . . 10 85 7. Architecture Variants . . . . . . . . . . . . . . . . . . . . 11 86 8. Kinds of Protocols . . . . . . . . . . . . . . . . . . . . . 14 87 8.1. Constrained Level Protocols . . . . . . . . . . . . . . . 14 88 8.1.1. Cross Level Support Protocols . . . . . . . . . . . . 14 89 8.2. Less-Constrained Level Protocols . . . . . . . . . . . . 15 90 9. Introduction to Problem Description . . . . . . . . . . . . . 15 91 9.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 15 92 10. Background . . . . . . . . . . . . . . . . . . . . . . . . . 16 93 11. Problem Description . . . . . . . . . . . . . . . . . . . . . 18 94 11.1. Authorization . . . . . . . . . . . . . . . . . . . . . 19 95 11.2. Authentication . . . . . . . . . . . . . . . . . . . . . 19 96 11.3. Communication Security . . . . . . . . . . . . . . . . . 20 97 11.4. Cryptographic Keys . . . . . . . . . . . . . . . . . . . 20 98 12. Assumptions and Requirements . . . . . . . . . . . . . . . . 21 99 12.1. Architecture . . . . . . . . . . . . . . . . . . . . . . 21 100 12.2. Constrained Devices . . . . . . . . . . . . . . . . . . 22 101 12.3. Authentication . . . . . . . . . . . . . . . . . . . . . 23 102 12.4. Authorization . . . . . . . . . . . . . . . . . . . . . 23 103 12.5. Authorization Information . . . . . . . . . . . . . . . 23 104 12.6. Resource Access . . . . . . . . . . . . . . . . . . . . 24 105 12.7. Keys and Cipher Suites . . . . . . . . . . . . . . . . . 24 106 12.8. Network Considerations . . . . . . . . . . . . . . . . . 25 107 12.9. Legacy Considerations . . . . . . . . . . . . . . . . . 25 108 13. Security Considerations . . . . . . . . . . . . . . . . . . . 25 109 13.1. Physical Attacks on Sensor and Actuator Networks . . . . 26 110 13.2. Time Measurements . . . . . . . . . . . . . . . . . . . 27 111 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 112 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 27 113 16. Informative References . . . . . . . . . . . . . . . . . . . 28 114 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 116 1. Introduction 118 Constrained nodes are small devices with limited abilities which in 119 many cases are made to fulfill a single simple task. They have 120 limited hardware resources such as processing power, memory, non- 121 volatile storage and transmission capacity and additionally in most 122 cases do not have user interfaces and displays. Due to these 123 constraints, commonly used security protocols are not always easily 124 applicable. 126 Constrained nodes are expected to be integrated in all aspects of 127 everyday life and thus will be entrusted with vast amounts of data. 128 Without appropriate security mechanisms attackers might gain control 129 over things relevant to our lives. Authentication and authorization 130 mechanisms are therefore prerequisites for a secure Internet of 131 Things. 133 The limitations of the constrained nodes ask for security mechanisms 134 which take the special characteristics of constrained environments 135 into account. Therefore, it is crucial to identify the tasks which 136 must be performed to meet the security requirements in constrained 137 scenarios. Moreover, these tasks need to be assigned to logical 138 functional entities which perform the tasks: the actors in the 139 architecture. Thus, relations between the actors and requirements 140 for protocols can be identified. 142 In this document, an architecture is developed to represent the 143 relationships between the logical functional entities involved. 145 1.1. Terminology 147 Readers are required to be familiar with the terms and concepts 148 defined in [RFC4949]. 150 In addition, this document uses the following terminology: 152 Resource (R): an item of interest which is represented through an 153 interface. It might contain sensor or actuator values or other 154 information. 156 Constrained node: a constrained device in the sense of [RFC7228]. 158 Actor: A logical functional entity that performs one or more tasks. 159 Depending on the tasks an actor must perform, the device that 160 contains the actor may need to have certain system resources 161 available. Multiple actors may share, i.e. be present within, a 162 device or even a piece of software. 164 Resource Server (RS): An entity which hosts and represents a 165 Resource. 167 Client (C): An entity which attempts to access a resource on a 168 Server. 170 Resource Owner (RO): The principal that is in charge of the resource 171 and controls its access permissions. 173 Requesting Party (RqP): The principal that is in charge of the 174 Client and controls permissions concerning authorized 175 representations of a Resource. 177 Principal: An individual that is either RqP or RO or both. 179 Authorization Server (AS): An entity that prepares and endorses 180 authentication and authorization data for a Server. 182 Client Authorization Server (CAS): An entity that prepares and 183 endorses authentication and authorization data for a Client. 185 Attribute Binding Authority: An entity that is authorized to 186 validate claims about an entity. 188 2. Problem Statement 190 The scenario this document addresses can be summarized as follows: 192 o C wants to access R on a RS. 194 o A priori, C and RS do not necessarily know each other and have no 195 security relationship. 197 o C and / or RS are constrained. 199 ------- -------- 200 | C | -- requests resource ---> | RS | 201 ------- <-- provides resource--- -------- 203 Figure 1: Basic Scenario 205 The security requirements of any specific version of this scenario 206 will include one or more of: 208 o Rq0.1: No unauthorized entity has access to (or otherwise gains 209 knowledge of) R. 211 o Rq0.2: C is exchanging status updates of a resource only with 212 authorized resources. (When C attempts to access R, that access 213 reaches an authorized R). 215 Rq0.1 requires authorization on the server side while Rq0.2 requires 216 authorization on the client side. 218 3. Security Objectives 220 The security objectives that can be addressed by an authorization 221 solution are confidentiality and integrity. Additionally, allowing 222 only selected entities limits the burden on system resources, thus 223 helping to achieve availability. Misconfigured or wrongly designed 224 authorization solutions can result in availability breaches: Users 225 might no longer be able to use data and services as they are supposed 226 to. 228 Authentication mechanisms can achieve additional security objectives 229 such as non-repudiation and accountability. They are not related to 230 authorization and thus are not in scope of this draft, but still 231 should be considered by Authenticated Authorization solutions. Non- 232 repudiation and accountability may require authentication on device 233 level, if it is necessary to determine which device performed an 234 action. In other cases it may be more important to find out who is 235 responsible for the device's actions. 237 The importance of a security objective depends on the application the 238 authorization mechanism is used for. [I-D.ietf-ace-usecases] 239 indicates that security objectives differ for the various constrained 240 environment use cases. 242 In many cases, one participating party might have different security 243 objectives than the other. However, to achieve a security objective, 244 both parties must participate in providing a solution. E.g., if RqP 245 requires the integrity of sensor value representations RS is hosting, 246 Both C and RS need to integrity-protect the transmitted data. 247 Moreover, RS needs to protect the access to the sensor representation 248 to prevent unauthorized users to manipulate the sensor values. 250 4. Authentication and Authorization 252 Authorization solutions aim at protecting the access to items of 253 interest, e.g. hardware or software resources or data: They enable 254 the principal of such a resource to control who can access it and 255 how. 257 To determine if an entity is authorized to access a resource, an 258 authentication mechanism is needed. According to the Internet 259 Security Glossary [RFC4949], authentication is "the process of 260 verifying a claim that a system entity or system resource has a 261 certain attribute value." Examples for attribute values are the ID 262 of a device, the type of the device or the name of its owner. 264 The security objectives the authorization mechanism aims at can only 265 be achieved if the authentication and the authorization mechanism 266 work together correctly. We use the term _authenticated 267 authorization_ to refer to a synthesis of mechanism for 268 authentication and authorization. 270 If used for authorization, the authenticated attributes must be 271 meaningful for the purpose of the authorization, i.e. the 272 authorization policy grants access permissions based on these 273 attributes. If the authorization policy assigns permissions to an 274 individual entity, the authenticated attributes must be suitable to 275 uniquely identify this entity. 277 In scenarios where devices are communicating autonomously there is 278 less need to uniquely identify an individual device. For a 279 principal, the fact that a device belongs to a certain company or 280 that it has a specific type (e.g. light bulb) is likely more 281 important than that it has a unique identifier. 283 Principals (RqP and RO) need to decide about the required level of 284 granularity for the authorization, ranging from _device 285 authorization_ over _owner authorization_ to _binary authorization_ 286 and _unrestricted authorization_. In the first case different access 287 permissions are granted to individual devices while in the second 288 case individual owners are authorized. If binary authorization is 289 used, all authenticated entities have the same access permissions. 291 Unrestricted authorization for an item of interest means that no 292 authorization mechanism is used (not even by authentication) and all 293 entities are able to access the item as they see fit. More fine- 294 grained authorization does not necessarily provide more security. 295 Principals need to consider that an entity should only be granted the 296 permissions it really needs to ensure the confidentiality and 297 integrity of resources. 299 For all cases where an authorization solution is needed (all but 300 Unrestricted Authorization), the authorizing party needs to be able 301 to authenticate the party that is to be authorized. Authentication 302 is therefore required for messages that contain representations of an 303 accessed item. More precisely, the authorizing party needs to make 304 sure that the receiver of a message containing a representation, and 305 the sender of a message containing a representation are authorized to 306 receive and send this message, respectively. To achieve this, the 307 integrity of these messages is required: Authenticity cannot be 308 assured if it is possible for an attacker to modify the message 309 during transmission. 311 In some cases, only one side (only the client side or only the server 312 side) requires the integrity and / or confidentiality of a resource 313 value. In these cases, principals may decide to use binary 314 authorization which can be achieved by an authentication mechanism or 315 even unrestricted authorization where no authentication mechanism is 316 required. However, as indicated in Section 3, the security 317 objectives of both sides must be considered. The security objectives 318 of one side can often only be achieved with the help of the other 319 side. E.g., if the server requires the confidentiality of a resource 320 representation, the client must make sure that it does not send 321 resource updates to parties other than the server. Therefore, the 322 client must at least use binary authorization. 324 5. Autonomous Communication 326 The use cases defined in [I-D.ietf-ace-usecases] demonstrate that 327 constrained devices are often used for scenarios where their 328 principals are not present at the time of the communication. 329 Moreover, these devices often do not have any user interfaces or 330 displays. Even if the principals are present at the time of access, 331 they may not be able to communicate directly with the device. The 332 devices therefore need to be able to communicate autonomously. In 333 some scenarios there is an active user at one endpoint of the 334 communication. Other scenarios ask for true machine to machine (M2M) 335 communication. 337 To achieve the principals' security objectives, the devices must be 338 enabled to enforce the security policies of their principals. 340 6. Actors 342 This section describes the various actors in the architecture. An 343 actor consists of a set of tasks and additionally has an security 344 domain (client domain or server domain) and a level (constrained, 345 principal, less-constrained). Tasks are assigned to actors according 346 to their security domain and required level. 348 Note: Actors are a concept to understand the security requirements 349 for constrained devices. The architecture of an actual solution 350 might differ as long as the security requirements that derive from 351 the relationship between the identified actors are considered. 352 Several actors might share a single device or even be combined in a 353 single piece of software. Interfaces between actors may be realized 354 as protocols or be internal to such a piece of software. 356 6.1. Constrained Level Actors 358 As described in the problem statement (see Section 2), either C or RS 359 or both of them may be located on a constrained node. We therefore 360 define that C and RS must be able to perform their tasks even if they 361 are located on a constrained node. Thus, C and RS are considered to 362 be Constrained Level Actors. 364 C performs the following tasks: 366 o Communicate in a secure way (provide for confidentiality and 367 integrity of messages). 369 o Validate that an entity is an authorized source for R. 371 o Securely transmit an access request. 373 RS performs the following tasks: 375 o Communicate in a secure way (provide for confidentiality and 376 integrity of messages). 378 o Validate the authorization of the requester to access the 379 requested resource as requested. 381 o Securely transmit a response to an access request. 383 R is an item of interest such as a sensor or actuator value. R is 384 considered to be part of RS and not a separate actor. The device on 385 which RS is located might contain several resources of different ROs. 386 For simplicity of exposition, these resources are described as if 387 they had separate RS. 389 As C and RS do not necessarily know each other they might belong to 390 different security domains. 392 ------- -------- 393 | C | -- requests resource ---> | RS | Constrained Level 394 ------- <-- provides resource--- -------- 396 Figure 2: Constrained Level Actors 398 6.2. Principal Level Actors 400 Our objective is that C and RS are under control of principals in the 401 physical world, the Requesting Party (RqP) and the Resource Owner 402 (RO) respectively. The principals decide about the security policies 403 of their respective endpoints and belong to the same security domain. 405 RqP is in charge of C, i.e. RqP specifies security policies for C, 406 e.g. with whom C is allowed to communicate. By definition, C and RqP 407 belong to the same security domain. 409 RqP must fulfill the following task: 411 o Configure for C authorization information for sources for R. 413 RO is in charge of R and RS. RO specifies authorization policies for 414 R and decides with whom RS is allowed to communicate. By definition, 415 R, RS and RO belong to the same security domain. 417 RO must fulfill the following task: 419 o Configure for RS authorization information for accessing R. 421 ------- ------- 422 | RqP | | RO | Principal Level 423 ------- ------- 424 | | 425 in charge of in charge of 426 | | 427 V V 428 ------- ------- 429 | C | -- requests resource ---> | RS | Constrained Level 430 ------- <-- provides resource--- ------- 432 Figure 3: Constrained Level Actors and Principal Level Actors 434 6.3. Less-Constrained Level Actors 436 Constrained level actors can only fulfill a limited number of tasks 437 and may not have network connectivity all the time. To relieve them 438 from having to manage keys for numerous endpoints and conducting 439 computationally intensive tasks, another complexity level for actors 440 is introduced. An actor on the less-constrained level belongs to the 441 same security domain as its respective constrained level actor. They 442 also have the same principal. 444 The Client Authorization Server (CAS) belongs to the same security 445 domain as C and RqP. CAS acts on behalf of RqP. It assists C in 446 authenticating RS and determining if RS is an authorized source for 447 R. CAS can do that because for C, CAS is the authority for claims 448 about RS. 450 CAS performs the following tasks: 452 o Validate on the client side that an entity has certain attributes. 454 o Obtain authorization information about an entity from C's 455 principal (RqP) and provide it to C. 457 o Negotiate means for secure communication to communicate with C. 459 The Authorization Server (AS) belongs to the same security domain as 460 R, RS and RO. AS acts on behalf of RO. It supports RS by 461 authenticating C and determining C's permissions on R. AS can do 462 that because for RS, AS is the authority for claims about C. 464 AS performs the following tasks: 466 o Validate on the server side that an entity has certain attributes. 468 o Obtain authorization information about an entity from RS' 469 principal (RO) and provide it to RS. 471 o Negotiate means for secure communication to communicate with RS. 473 ------- ------- 474 | RqP | | RO | Principal Level 475 ------- ------- 476 | | 477 in charge of in charge of 478 | | 479 V V 480 ---------- ---------- 481 | CAS | <- AuthN and AuthZ -> | AS | Less-Constrained Level 482 ---------- ---------- 483 | | 484 authentication authentication 485 and authorization and authorization 486 support support 487 | | 488 V V 489 ------- ------- 490 | C | -- requests resource ---> | RS | Constrained Level 491 ------- <-- provides resource -- ------- 493 Figure 4: Overview of all Complexity Levels 495 For more detailed graphics please consult the PDF version. 497 7. Architecture Variants 499 As mentioned in section Section 6, actors can share a single device 500 or even be combined in a single piece of software. If C is located 501 on a more powerful device, it can be combined with CAS: 503 ------- -------- 504 | RqP | | RO | Principal Level 505 ------- -------- 506 | | 507 in charge of in charge of 508 | | 509 V V 510 ------------ -------- 511 | CAS + C | <- AuthN and AuthZ -> | AS | Less-Constrained Level 512 ------------ -------- 513 ^ | 514 \__ | 515 \___ authentication 516 \___ and authorization 517 requests resource/ \___ support 518 provides resource \___ | 519 \___ | 520 V V 521 ------- 522 | RS | Constrained Level 523 ------- 525 Figure 5: Combined C and CAS 527 If RS is located on a more powerful device, it can be combined with 528 AS: 530 ------- ------- 531 | RqP | | RO | Principal Level 532 ------- ------- 533 | | 534 in charge of in charge of 535 | | 536 V V 537 ---------- ----------- 538 | CAS | <- AuthN and AuthZ -> | RS + AS | Less-Constrained Level 539 ---------- ----------- 540 | ^ 541 authentication ___/ 542 and authorization ___/ 543 support ___/ request resource / provides resource 544 | ___/ 545 V ___/ 546 ------- / 547 | C | <- 548 ------- 550 Figure 6: Combined AS and RS 552 If C and RS have the same principal, CAS and AS can be combined. 554 ------------ 555 | RqP = RO | Principal Level 556 ------------ 557 | 558 in charge of 559 | 560 V 561 -------------- 562 | CAS + AS | Less-Constrained Level 563 -------------- 564 / \ 565 / \ 566 authentication authentication 567 and authorization and authorization 568 support support 569 / \ 570 V V 571 ------- ------- 572 | C | -- requests resource --> | RS | Constrained Level 573 ------- <-- provides resource -- ------- 575 Figure 7: CAS combined with AS 577 8. Kinds of Protocols 579 Devices on the less-constrained level potentially are more powerful 580 than constrained level devices in terms of processing power, memory, 581 non-volatile storage. This results in different characteristics for 582 the protocols used on these levels. 584 8.1. Constrained Level Protocols 586 A protocol is considered to be on the constrained level if it is used 587 between the actors C and RS which are considered to be constrained 588 (see Section 6.1). C and RS might not belong to the same security 589 domain. Therefore, constrained level protocols need to work between 590 different security domains. 592 FIXME 594 Figure 8: Constrained Level Tasks 596 Commonly used Internet protocols can not in every case be applied to 597 constrained environments. In some cases, tweaking and profiling is 598 required. In other cases it is beneficial to define new protocols 599 which were designed with the special characteristics of constrained 600 environments in mind. 602 On the constrained level, protocols need to address the specific 603 requirements of constrained environments. Examples for protocols 604 that consider these requirements is the transfer protocol CoAP 605 (Constrained Application Protocol) [RFC7252] and the Datagram 606 Transport Layer Security Protocol (DTLS) [RFC6347] which can be used 607 for channel security. 609 Constrained devices have only limited storage space and thus cannot 610 store large numbers of keys. This is especially important because 611 constrained networks are expected to consist of thousands of nodes. 612 Protocols on the constrained level should keep this limitation in 613 mind. 615 8.1.1. Cross Level Support Protocols 617 Protocols which operate between a constrained device on one side and 618 the corresponding less constrained device on the other are considered 619 to be (cross level) support protocols. Protocols used between C and 620 CAS or RS and AS are therefore support protocols. 622 Support protocols must consider the limitations of their constrained 623 endpoint and therefore belong to the constrained level protocols. 625 8.2. Less-Constrained Level Protocols 627 A protocol is considered to be on the less-constrained level if it is 628 used between the actors CAS and AS. CAS and AS might belong to 629 different security domains. 631 On the less-constrained level, HTTP [RFC7230] and Transport Layer 632 Security (TLS) [RFC5246] can be used alongside or instead of CoAP and 633 DTLS. Moreover, existing security solutions for authentication and 634 authorization such as the Web Authorization Protocol (OAuth) 635 [RFC6749] and Kerberos [RFC4120] can likely be used without 636 modifications and there are no limitations for the use of a Public 637 Key Infrastructure (PKI). 639 FIXME 641 Figure 9: Less-constrained Level Tasks 643 9. Introduction to Problem Description 645 Authorization is the process of deciding what an entity ought to be 646 allowed to do. This memo is about properties of security protocols 647 to enable explicit and dynamic authorization of clients to access a 648 resource at a server, in particular in constrained environments when 649 the client and/or server are constrained nodes. 651 Relevant use cases are provided in [I-D.ietf-ace-usecases], which 652 also lists some authorization problems derived from the use cases. 653 In this memo we present a more specific problem description for 654 authentication and authorization in constrained RESTful environments 655 together with a detailed set of assumptions and requirements (cf. 656 Section 12). 658 9.1. Terminology 660 Certain security-related terms are to be understood in the sense 661 defined in [RFC4949]. These terms include, but are not limited to, 662 "authentication", "authorization", "confidentiality", "(data) 663 integrity", "message authentication code", and "verify". 665 RESTful terms including "resource", "representation", etc. are to be 666 understood as used in HTTP [RFC7231] and CoAP [RFC7252]. 668 Terminology for constrained environments including "constrained 669 device", "constrained-node network", "class 1", etc. are defined in 670 [RFC7228]. 672 "Explicit" authorization is used here to describe the ability to 673 specify in some detail which entity has access to what and under what 674 conditions, as opposed to "implicit" authorization where an entity is 675 either allowed to access everything or nothing. 677 "Dynamic" authorization means that the access control polices and the 678 parameters on which they are evaluated may change during normal 679 operations, as opposed to "static" authorization meaning that access 680 control policies cannot be changed during normal operations and may 681 require some special procedure such as out-of-band provision. 683 10. Background 685 We assume a client-server setting, where a client wishes to access 686 some resource hosted by a server. Such resources may e.g. be sensor 687 data, configuration data, or actuator settings. Thus access to a 688 resource could be by different methods, some of which change the 689 state of the resource. In this memo, we consider the REST setting 690 i.e. GET, POST, PUT and DELETE, and application protocols in scope 691 are HTTP [RFC7231] and CoAP [RFC7252]. 693 We assume that the roles of client and server are not fixed, i.e. a 694 node which is client could very well be server in some other context 695 and vice-versa. Further we assume that in some cases, clients are 696 not previously known to servers, thus we cannot assume that the 697 server has access control policies specific to that client when the 698 client initiates communication. 700 Finally we also assume that in a significant number of cases, the 701 server and/or the client are too constrained to handle the evaluation 702 of complex access control policies and related configuration on their 703 own. Many authorization solutions involve a centralized, trusted 704 third party, supporting the client and/or resource server. A trusted 705 third party provides a more scalable way to centrally manage 706 authorization policies, in order to ensure consistent authorization 707 decisions. The physical separation of policy decision and policy 708 enforcement is an established principle in policy based management, 709 e.g. [RFC2748]. 711 Borrowing from OAuth 2.0 [RFC6749] terminology we name the entities: 712 client (C), resource server (RS), authorization server (AS - the 713 third party), and resource owner (RO). RO is in charge of the access 714 control policies implemented in the AS governing the actions of RS. 715 However, the RO need not be active in a constrained device access 716 control setting, so we cannot rely on timely interactions with the 717 RO. In the target setting RS is typically constrained, C may be 718 constrained, whereas AS is not assumed to be constrained. 720 Since RS is constrained, we assume that it needs to offload 721 authorization policy management and/or authorization decision making 722 to AS. This means that some authorization information needs to be 723 transferred from AS to RS. 725 Protecting information carried between AS and RS, requires some a 726 priori established cryptographic keys. How those keys are 727 established is out of scope for this problem description. 729 AS may for example be implemented as a cloud service, in a home 730 server, or in a smartphone. C and RS may or may not have 731 connectivity to AS at the time of the access request, e.g. because 732 they cannot handle multiple, simultaneous connections. Another 733 reason for intermittent connectivity may be that constant 734 connectivity is not affordable (e.g. due to limited battery power, or 735 a sensor mobility business case for which cellular connectivity cost 736 too much or is not available). Obviously, in order for a client 737 request to reach RS there must be connectivity between C and RS, but 738 that could be a short range technology such as Bluetooth, ZigBee, or 739 NFC. Furthermore, if there is not sufficient authorization 740 information about C in RS, and neither C nor RS can access AS, access 741 requests will be denied. Therefore we assume that either C or RS can 742 access AS at some point in time, prior to the client's request. 744 As a summary, there are potentially three information flows that 745 needs to be protected (see Figure 10): 747 1. The transfer of authorization information from AS to RS 749 2. The transfer of cryptographic keys or credentials from AS to RS 750 and C, respectively 752 3. The access request/response procedure between C and RS 753 +---------------+ 754 | Authorization | 755 | Server | 756 | | 757 +---------------+ 758 / \ Authorization 759 Credentials, / \ Information 760 Keys / \ 761 / \ Credentials, 762 / \ Keys 763 V V 764 +--------+ +-----------+ 765 | Client | | Resource | 766 | |<---- Access procedure --->| Server | 767 | | | | 768 +--------+ +-----------+ 770 Figure. Information flows that needs to be protected. 771 Only showing origin and destination, actual 772 flow may pass intermediary nodes. 774 Figure 10 776 NOTE: 778 The information flow in Figure 10 above enables RO to control the 779 interactions of a constrained RS by means of access control policies. 780 There is an ongoing discussion about an analogous information flow 781 enabling the stakeholder associated to C ("Requesting Party" in UMA 782 terminology [I-D.hardjono-oauth-umacore]) to control the interactions 783 of a constrained C by means of policies. While this would not be 784 policies for access control to resources, it could be useful in 785 certain settings which require dynamically changing interaction 786 patterns with a constrained client without updating firmware. Such a 787 solution could potentially reuse all security components required to 788 protect the information flow in 1., so no additional specifications 789 would be needed. This aspect is not discussed further in this draft. 791 11. Problem Description 793 A number of problems needs to be solved in order to achieve explicit 794 and dynamic authorization, as is described in this section. 796 11.1. Authorization 798 The core problem we are trying to solve is authorization. The 799 following problems related to authorization need to be addressed: 801 o AS needs to transfer authorization information to RS. 803 o The transferred authorization information needs to follow a 804 defined format and encoding, which must be efficient for 805 constrained devices, considering size of authorization information 806 and parser complexity. 808 o The RS needs to be able to verify the authenticity of the 809 authorization information. There is a trade-off here between 810 processing complexity and deployment complexity. 812 o The RS needs to enforce the authorization decisions of the AS. 813 The authorization information it obtained from AS might require 814 additional policy evaluation (e.g. matching against local access 815 control lists, evaluating local conditions). The required "policy 816 evaluation" at the RS needs to be adapted to the capabilities of 817 the constrained device. 819 o Finally, as is indicated in the previous bullet, for a particular 820 authorization decision there may be different kinds of 821 authorization information needed, and these pieces of information 822 may be transferred to RS at different times and in different ways 823 prior to or during the client request. 825 11.2. Authentication 827 The following problems need to be addressed, when considering 828 authentication: 830 o RS need to authenticate AS to ensure that the authorization 831 information and related data comes from the correct source. 833 o C may need to to authenticate AS to ensure that it gets security 834 information related to the resources from the right source. 836 o In some use cases RS needs to authenticate some property of C, in 837 order to bind it to the relevant authorization information. In 838 other use cases, authentication and authorization of C may be 839 implicit, e.g. by encrypting the resource representation the RS 840 only providing access to those who possess the key to decrypt. 842 o C may need to authenticate RS, in order to ensure that it is 843 interacting with the right resources. Alternatively C may just 844 verify the integrity of a received resource representation. 846 o AS may need to authenticate its communication partner (either C or 847 RS), in order to ensure it serves the correct device. 849 11.3. Communication Security 851 There are different alternatives to provide communication security, 852 and the problem here is to choose the optimal one for each scenario. 853 We list the available alternatives: 855 o Session-based security at transport layer such as DTLS [RFC6347] 856 offers security, including integrity and confidentiality 857 protection, for the whole application layer exchange. However, 858 DTLS may not provide end-to-end security over multiple hops. 859 Another problem with DTLS is the cost of the handshake protocol, 860 which may be too expensive for constrained devices especially in 861 terms of memory and power consumption for message transmissions. 863 o An alternative is object security at application layer, e.g. 864 using [I-D.selander-ace-object-security]. Secure objects can be 865 stored or cached in network nodes and provide security for a more 866 flexible communication model such as publish/subscribe (compare 867 e.g. CoRE Mirror Server [I-D.koster-core-coap-pubsub]). A 868 problem with object security is that it can not provide 869 confidentiality for the message headers. 871 o Hybrid solutions using both session-based and object security are 872 also possible. An example of a hybrid is where authorization 873 information and cryptographic keys are provided by AS in the 874 format of secure data objects, but where the resource access is 875 protected by session-based security. 877 11.4. Cryptographic Keys 879 With respect to cryptographic keys, we see the following problems 880 that need to be addressed: 882 Symmetric vs Asymmetric Keys 883 We need keys both for protection of resource access and for 884 protection of transport of authentication and authorization 885 information. Do we want to support solutions based on asymmetric 886 keys or symmetric keys in both cases? There are classes of 887 devices that can easily perform symmetric cryptography, but 888 consume considerably more time/battery for asymmetric operations. 890 On the other hand asymmetric cryptography has benefits e.g. in 891 terms of deployment. 893 Key Establishment 894 How are the corresponding cryptographic keys established? 895 Considering Section 11.1 there must be a binding between these 896 keys and the authorization information, at least in the sense that 897 AS must be able to specify a unique client identifier which RS can 898 verify (using an associated key). One of the use cases of 899 [I-D.ietf-ace-usecases] describes spontaneous change of access 900 policies - e.g. giving a hitherto unknown client the right to 901 temporarily unlock your house door. In this case C is not 902 previously known to RS and a key must be provisioned by AS. 904 Revocation and Expiration 905 How are keys replaced and how is a key that has been compromised 906 revoked in a manner that reaches all affected parties, also 907 keeping in mind scenarios with intermittent connectivity? 909 12. Assumptions and Requirements 911 In this section we list a set of candidate assumptions and 912 requirements to make the problem description in the previous sections 913 more concise and precise. 915 12.1. Architecture 917 The architecture consists of at least the following types of nodes: 919 o RS hosting resources, and responding to access requests 921 o C requesting access to resources 923 o AS supporting the access request/response procedure by providing 924 authorization information to RS. 926 * AS may also provide other services such as authenticating C on 927 behalf of RS, or providing cryptographic keys or credentials to 928 C and/or RS to secure the request/response procedure. 930 o The architecture may contain intermediary nodes between any pair 931 of C, RS and AS, such as e.g. forward/reverse proxies in the CoRE 932 architecture. The solution shall not unduly restrict the use of 933 intermediaries. 935 * The architecture shall support session based security and data 936 object security. 938 12.2. Constrained Devices 940 o C and/or RS may be constrained in terms of power, processing, 941 communication bandwidth, memory and storage space, and moreover 943 * unable to manage complex authorization policies 945 * unable to manage a large number of secure connections 947 * without user interface 949 * without constant network connectivity 951 * unable to precisely measure time 953 * required to save on wireless communication due to high power 954 consumption 956 o AS is not a constrained device. 958 o All devices under consideration can process symmetric cryptography 959 without incurring an excessive performance penalty. 961 * We assume the use of a standardized symmetric key algorithm, 962 such as AES. 964 * Except for the most constrained devices we assume the use of a 965 standardized cryptographic hash function such as SHA-256. 967 o Public key cryptography requires additional resources (e.g. RAM, 968 ROM, power, specialized hardware). 970 o A DTLS handshake involves significant computation, communication, 971 and memory overheads in the context of constrained devices. 973 * The RAM requirements of DTLS handshakes with public key 974 cryptography are prohibitive for certain constrained devices. 976 * Certificate-based DTLS handshakes require significant volumes 977 of communication, RAM (message buffers) and computation. 979 o The solution shall support a simple scheme for expiring 980 authentication and authorization information on devices which are 981 unable to measure time (cf. section Section 13.2). 983 12.3. Authentication 985 o RS need to authenticate AS to ensure that the authorization 986 information and related data comes from the correct source. 988 o Depending on use case, C, RS or AS may need to authenticate each 989 other. 991 12.4. Authorization 993 o The authorization decision is based on credentials presented by C, 994 the requested resource, the RESTful method, and local context in 995 RS at the time of the request, or on any subset of this 996 information. 998 o The authorization decision is taken either by AS or RS. 1000 o The authorization decision is enforced by RS. 1002 * RS needs to have access to authorization information in order 1003 to verify that C is allowed to access the resource as 1004 requested. 1006 * RS needs to make sure that it provides resource access only to 1007 authorized clients. 1009 o Apart from authorization for access to a resource, authorization 1010 may also be required for access to information about a resource 1011 (e.g. resource descriptions). 1013 o The solution may need to be able to support the delegation of 1014 access rights. 1016 12.5. Authorization Information 1018 o Authorization information is transferred from AS to RS using 1019 Agent, Push or Pull mechanisms [RFC2904]. 1021 o RS shall authenticate that the authorization information is coming 1022 from AS. 1024 o The authorization information may also be encrypted end-to-end 1025 between AS and RS. 1027 o RS may not be able to communicate with AS at the time of the 1028 request from C. 1030 o RS may store or cache authorization information. 1032 o Authorization information may be pre-configured in RS. 1034 o Authorization information stored or cached in RS shall be possible 1035 to change. The change of such information shall be subject to 1036 authorization. 1038 o Authorization policies stored on RS may be handled as a resource, 1039 i.e. information located at a particular URI, accessed with 1040 RESTful methods, and the access being subject to the same 1041 authorization mechanics. AS may have special privileges when 1042 requesting access to the authorization policy resources on RS. 1044 o There may be mechanisms for C to look up the AS which provides 1045 authorization information about a particular resource. 1047 12.6. Resource Access 1049 o Resources are accessed in a RESTful manner using GET, PUT, POST, 1050 DELETE. 1052 o By default, the resource request shall be integrity protected and 1053 may be encrypted end-to-end from C to RS. It shall be possible 1054 for RS to detect a replayed request. 1056 o By default, the response to a request shall be integrity protected 1057 and encrypted end-to-end from RS to C. It shall be possible for C 1058 to detect a replayed response. 1060 o RS shall be able to verify that the request comes from an 1061 authorized client 1063 o C shall be able to verify that the response to a request comes 1064 from the intended RS. 1066 o There may be resources whose access need not be protected (e.g. 1067 for discovery of the responsible AS). 1069 12.7. Keys and Cipher Suites 1071 o AS and RS have established cryptographic keys. Either AS and RS 1072 share a secret key or each have the other's public key. 1074 o The transfer of authorization information is protected with 1075 symmetric and/or asymmetric keys. 1077 o The access request/response can be protected with symmetric and/or 1078 asymmetric keys. 1080 o There must be a mechanism for RS to establish the necessary key(s) 1081 to verify and decrypt the request. 1083 o There must be a mechanism for C to establish the necessary key(s) 1084 to verify and decrypt the response. 1086 o There must be a mechanism for C to look up the supported cipher 1087 suites of a RS. 1089 12.8. Network Considerations 1091 o The solution shall prevent network overload due to avoidable 1092 communication with AS. 1094 o The solution shall prevent network overload by compact 1095 authorization information representation. 1097 o The solution shall optimize the case where authorization 1098 information does not change often. 1100 o The solution where possible shall support an efficient mechanism 1101 for providing authorization information to multiple RSs, for 1102 example when multiple entities need to be configured or change 1103 state. 1105 12.9. Legacy Considerations 1107 o The solution shall work with existing infrastructure. 1109 o The solution shall support authorization of access to legacy 1110 devices. 1112 13. Security Considerations 1114 This document discusses authorization-related tasks for constrained 1115 environments and describes how these tasks can be mapped to actors in 1116 the architecture. 1118 The entire document is about security. Security considerations 1119 applicable to authentication and authorization in RESTful 1120 environments are provided in e.g. OAuth 2.0 [RFC6749]. 1122 In this section we focus on specific security aspects related to 1123 authorization in constrained-node networks. 1125 13.1. Physical Attacks on Sensor and Actuator Networks 1127 The focus of this work is on constrained-node networks consisting of 1128 connected sensors and actuators. The main function of such devices 1129 is to interact with the physical world by gathering information or 1130 performing an action. We now discuss attacks performed with physical 1131 access to such devices. 1133 The main threats to sensors and actuator networks are: 1135 o Unauthorized access to data to and from sensors and actuators, 1136 including eavesdropping and manipulation of data. 1138 o Denial-of-service making the sensor/actuator unable to perform its 1139 intended task correctly. 1141 A number of attacks can be made with physical access to a device 1142 including probing attacks, timing attacks, power attacks, etc. 1143 However, with physical access to a sensor or actuator device it is 1144 possible to directly perform attacks equivalent of eavesdropping, 1145 manipulating data or denial of service. For example: 1147 o Instead of eavesdropping the sensor data or attacking the 1148 authorization system to gain access to the data, the attacker 1149 could make its own measurements on the physical object. 1151 o Instead of manipulating the sensor data the attacker could change 1152 the physical object which the sensor is measuring, thereby 1153 changing the payload data which is being sent. 1155 o Instead of manipulating data for an actuator or attacking the 1156 authorization system, the attacker could perform an unauthorized 1157 action directly on the physical object. 1159 o A denial-of-service attack could be performed physically on the 1160 object or device. 1162 All these attacks are possible by having physical access to the 1163 device, since the assets are related to the physical world. 1164 Moreover, this kind of attacks are in many cases straightforward 1165 (requires no special competence or tools, low cost given physical 1166 access, etc.) 1168 As a conclusion, if an attacker has physical access to a sensor or 1169 actuator device, then much of the security functionality 1170 elaborated in this draft is not effective to protect the asset 1171 during the physical attack. 1173 Since it does not make sense to design a solution for a situation 1174 that cannot be protected against we assume there is no need to 1175 protect assets which are exposed during a physical attack. In 1176 other words, either an attacker does not have physical access to 1177 the sensor or actuator device, or if it has, the attack shall only 1178 have effect during the period of physical attack. 1180 13.2. Time Measurements 1182 Measuring time with certain accuracy is important to achieve certain 1183 security properties, for example to determine whether a public key 1184 certificate, access token or some other assertion is valid. 1186 Dynamic authorization in itself requires the ability to handle expiry 1187 or revocation of authorization decisions or to distinguish new 1188 authorization decisions from old. 1190 For certain categories of devices we can assume that there is an 1191 internal clock which is sufficiently accurate to handle the time 1192 measurement requirements. If RS can connect directly to AS it could 1193 get updated in terms of time as well as revocation information. 1195 If RS continuously measures time but can't connect to AS or other 1196 trusted source, time drift may have to be accepted and it may not be 1197 able to manage revocation. However, it may still be able to handle 1198 short lived access rights within some margins, by measuring the time 1199 since arrival of authorization information or request. 1201 Some categories of devices in scope may be unable measure time with 1202 any accuracy (e.g. because of sleep cycles). This category of 1203 devices is not suitable for the use cases which require measuring 1204 validity of assertions and authorizations in terms of absolute time. 1206 14. IANA Considerations 1208 This document has no actions for IANA. 1210 15. Acknowledgements 1212 The authors would like to thank Olaf Bergmann, Robert Cragie, Klaus 1213 Hartke, Sandeep Kumar, John Mattson, Corinna Schmitt, Mohit Sethi, 1214 Hannes Tschofenig, Vlasios Tsiatsis and Erik Wahlstroem for 1215 contributing to the discussion, giving helpful input and commenting 1216 on previous forms of this draft. The authors would also like to 1217 acknowledge input provided by Hummen et al. [HUM14delegation]. 1219 16. Informative References 1221 [HUM14delegation] 1222 Hummen, R., Shafagh, H., Raza, S., Voigt, T., and K. 1223 Wehrle, "Delegation-based Authentication and Authorization 1224 for the IP-based Internet of Things", 11th IEEE 1225 International Conference on Sensing, Communication, and 1226 Networking (SECON'14), June 30 - July 3, 2014. 1228 [I-D.hardjono-oauth-umacore] 1229 Hardjono, T., Maler, E., Machulak, M., and D. Catalano, 1230 "User-Managed Access (UMA) Profile of OAuth 2.0", draft- 1231 hardjono-oauth-umacore-12 (work in progress), February 1232 2015. 1234 [I-D.ietf-ace-usecases] 1235 Seitz, L., Gerdes, S., Selander, G., Mani, M., and S. 1236 Kumar, "ACE use cases", draft-ietf-ace-usecases-03 (work 1237 in progress), March 2015. 1239 [I-D.koster-core-coap-pubsub] 1240 Koster, M., Keranen, A., and J. Jimenez, "Publish- 1241 Subscribe Broker for the Constrained Application Protocol 1242 (CoAP)", draft-koster-core-coap-pubsub-01 (work in 1243 progress), March 2015. 1245 [I-D.selander-ace-object-security] 1246 Selander, G., Mattsson, J., and L. Seitz, "March 9, 2015", 1247 draft-selander-ace-object-security-01 (work in progress), 1248 March 2015. 1250 [RFC2748] Durham, D., Boyle, J., Cohen, R., Herzog, S., Rajan, R., 1251 and A. Sastry, "The COPS (Common Open Policy Service) 1252 Protocol", RFC 2748, January 2000. 1254 [RFC2904] Vollbrecht, J., Calhoun, P., Farrell, S., Gommans, L., 1255 Gross, G., de Bruijn, B., de Laat, C., Holdrege, M., and 1256 D. Spence, "AAA Authorization Framework", RFC 2904, August 1257 2000. 1259 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The 1260 Kerberos Network Authentication Service (V5)", RFC 4120, 1261 July 2005. 1263 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", RFC 1264 4949, August 2007. 1266 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1267 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 1269 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1270 Security Version 1.2", RFC 6347, January 2012. 1272 [RFC6749] Hardt, D., "The OAuth 2.0 Authorization Framework", RFC 1273 6749, October 2012. 1275 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 1276 Constrained-Node Networks", RFC 7228, May 2014. 1278 [RFC7230] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol 1279 (HTTP/1.1): Message Syntax and Routing", RFC 7230, June 1280 2014. 1282 [RFC7231] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol 1283 (HTTP/1.1): Semantics and Content", RFC 7231, June 2014. 1285 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 1286 Application Protocol (CoAP)", RFC 7252, June 2014. 1288 Authors' Addresses 1290 Stefanie Gerdes 1291 Universitaet Bremen TZI 1292 Postfach 330440 1293 Bremen D-28359 1294 Germany 1296 Phone: +49-421-218-63906 1297 Email: gerdes@tzi.org 1299 Ludwig Seitz 1300 SICS Swedish ICT AB 1301 Scheelevaegen 17 1302 Lund 223 70 1303 Sweden 1305 Email: ludwig@sics.se 1306 Goeran Selander 1307 Ericsson 1308 Faroegatan 6 1309 Kista 164 80 1310 Sweden 1312 Email: goran.selander@ericsson.com 1314 Carsten Bormann (editor) 1315 Universitaet Bremen TZI 1316 Postfach 330440 1317 Bremen D-28359 1318 Germany 1320 Phone: +49-421-218-63921 1321 Email: cabo@tzi.org