idnits 2.17.1 draft-gerdes-ace-actors-02.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 (October 27, 2014) is 3462 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- 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) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 4 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 October 27, 2014 5 Expires: April 30, 2015 7 Actors in the ACE Architecture 8 draft-gerdes-ace-actors-02 10 Abstract 12 Constrained nodes are small devices which are limited in terms of 13 processing power, memory, non-volatile storage and transmission 14 capacity. Due to these constraints, commonly used security protocols 15 are not easily applicable. Nevertheless, an authentication and 16 authorization solution is needed to ensure the security of these 17 devices. 19 Due to the limitations of the constrained nodes it is especially 20 important to develop a light-weight security solution which is 21 adjusted to the relevant security objectives of each participating 22 party in this environment. Necessary security measures must be 23 identified and applied where needed. 25 In this document, the required security related tasks are identified 26 as guidance for the development of authentication and authorization 27 solutions for constrained environments. Based on the tasks, an 28 architecture is developed to represent the relationships between the 29 logical functional entities involved. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on April 30, 2015. 48 Copyright Notice 50 Copyright (c) 2014 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (http://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 66 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 67 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4 68 3. Security Objectives . . . . . . . . . . . . . . . . . . . . . 5 69 4. Authentication and Authorization . . . . . . . . . . . . . . 6 70 5. Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 71 5.1. Basic Scenario Tasks . . . . . . . . . . . . . . . . . . 7 72 5.2. Security-Related Tasks . . . . . . . . . . . . . . . . . 7 73 5.3. Authentication-Related Tasks . . . . . . . . . . . . . . 8 74 5.4. Authorization-Related Tasks . . . . . . . . . . . . . . . 8 75 6. Actors . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 76 6.1. Constrained Level Actors . . . . . . . . . . . . . . . . 9 77 6.2. Principal Level Actors . . . . . . . . . . . . . . . . . 11 78 6.3. Less-Constrained Level Actors . . . . . . . . . . . . . . 11 79 7. Protocol Requirements . . . . . . . . . . . . . . . . . . . . 13 80 7.1. Constrained Level Protocols . . . . . . . . . . . . . . . 13 81 7.1.1. Cross Level Support Protocols . . . . . . . . . . . . 14 82 7.2. Less-Constrained Level Protocols . . . . . . . . . . . . 14 83 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 84 9. Security Considerations . . . . . . . . . . . . . . . . . . . 14 85 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 86 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 87 11.1. Normative References . . . . . . . . . . . . . . . . . . 15 88 11.2. Informative References . . . . . . . . . . . . . . . . . 15 89 Appendix A. List of Tasks . . . . . . . . . . . . . . . . . . . 15 90 A.1. Basic Scenario . . . . . . . . . . . . . . . . . . . . . 16 91 A.1.1. Processing Information . . . . . . . . . . . . . . . 16 92 A.1.2. Sending Information . . . . . . . . . . . . . . . . . 18 93 A.2. Security-Related Tasks . . . . . . . . . . . . . . . . . 20 94 A.2.1. Information Authenticity . . . . . . . . . . . . . . 20 95 A.2.2. Authorization Validation . . . . . . . . . . . . . . 21 96 A.2.3. Transmission Security . . . . . . . . . . . . . . . . 22 97 A.2.4. Obtain Authorization information . . . . . . . . . . 23 98 A.2.5. Attribute Binding . . . . . . . . . . . . . . . . . . 24 99 A.2.6. Configuration of Authorization Information . . . . . 25 100 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 26 102 1. Introduction 104 Constrained nodes are small devices with limited abilities which in 105 many cases are made to fulfill a single simple task. They have 106 limited hardware resources such as processing power, memory, non- 107 volatile storage and transmission capacity and additionally in most 108 cases do not have user interfaces and displays. Due to these 109 constraints, commonly used security protocols are not always easily 110 applicable. 112 Constrained nodes are expected to be integrated in all aspects of 113 everyday life and thus will be entrusted with vast amounts of data. 114 Without appropriate security mechanisms attackers might gain control 115 over things relevant to our lives. Authentication and authorization 116 mechanisms are therefore prerequisites for a secure Internet of 117 Things. 119 The limitations of the constrained nodes ask for security mechanisms 120 which take the special characteristics of constrained environments 121 into account. Therefore, it is crucial to identify the tasks which 122 must be performed to meet the security requirements in constrained 123 scenarios. Moreover, these tasks need to be assigned to logical 124 functional entities which perform the tasks: the actors in the 125 architecture. Thus, relations between the actors and requirements 126 for protocols can be identified. 128 In this document, the required security related tasks are identified 129 as guidance for the development of authentication and authorization 130 solutions for constrained environments. Based on the tasks, an 131 architecture is developed to represent the relationships between the 132 logical functional entities involved. 134 1.1. Terminology 136 Readers are required to be familiar with the terms and concepts 137 defined in [RFC4949]. In addition, this document uses the following 138 terminology: 140 Resource (R): an item of interest, which is represented through an 141 interface. It might contain sensor or actuator values or other 142 information. 144 Constrained node: a constrained device in the sense of [RFC7228]. 146 Actor: A logical functional entity that performs one or more tasks. 147 Depending on the tasks an actor must perform, the device that 148 contains the actor may need to have certain system resources 149 available. Multiple actors may share, i.e. be present within, a 150 device or even a piece of software. 152 Resource Server (RS): An entity which hosts and represents a 153 Resource. 155 Client (C): An entity which attempts to access a resource on a 156 Resource Server. 158 Resource Owner (RO): The principal that owns the resource and 159 controls its access permissions. 161 Client Owner (CO): The principal that owns the Client and controls 162 permissions concerning authorized representations of a Resource. 164 Server Authorization Manager (SAM): An entity that prepares and 165 endorses authentication and authorization data for a Resource 166 Server. 168 Client Authorization Manager (CAM): An entity that prepares and 169 endorses authentication and authorization data for a Client. 171 Attribute Binding Authority: An entity that is authorized to 172 validate claims about an entity. 174 2. Problem Statement 176 The scenario this document addresses can be summarized as follows: 178 o C wants to access R on a RS. 180 o A priori, C and RS do not necessarily know each other and have no 181 security relationship. 183 o C and / or RS are constrained. 185 ------- -------- 186 | C | -- requests resource ---> | RS | 187 ------- <-- provides resource--- -------- 189 Figure 1: Basic Scenario 191 There are some security requirements for this scenario including one 192 or more of: 194 o Rq0.1: No unauthorized entity has access to (or otherwise gains 195 knowledge of) R. 197 o Rq0.2: No unauthorized entity can provide C with a representation 198 of R (When C attempts to access R, that access reaches the proper 199 R). 201 Rq0.1 requires authorization on RS' side while Rq0.2 requires 202 authorization on C's side. 204 3. Security Objectives 206 The security objectives that can be addressed by an authorization 207 solution are confidentiality and integrity. Availability cannot be 208 achieved by authorization solutions. However, misconfigured or 209 wrongly designed authorization solutions can result in availability 210 breaches: Users might no longer be able to use data and services as 211 they are supposed to. 213 Authentication mechanisms can achieve additional security objectives 214 such as non-repudiation and accountability. They are not related to 215 authorization and thus are not in scope of this draft, but still 216 should be considered by Authenticated Authorization solutions. Non- 217 repudiation and accountability may require authentication on device 218 level, if it is necessary to determine which device performed an 219 action. In other cases it may be more important to find out who is 220 responsible for the device's actions. 222 The importance of a security objective depends on the application the 223 authorization mechanism is used for. [I-D.seitz-ace-usecases] 224 indicates that security objectives differ for the various constrained 225 environment use cases. 227 In many cases, one participating party might have different security 228 objectives than the other. However, to achieve a security objective, 229 both parties must participate in providing a solution. E.g., if CO 230 requires the integrity of sensor value representations RS is hosting, 231 RS needs to integrity-protect the transmitted data. Moreover, RS 232 needs to protect the access to the sensor representation to prevent 233 unauthorized users to manipulate the sensor values. 235 4. Authentication and Authorization 237 Authorization solutions aim at protecting the access to items of 238 interest, e.g. hardware or software resources or data: They enable 239 the owner of such a resource to control who can access it and how. 241 To determine if an entity is authorized to access a resource, an 242 authentication mechanism is needed. According to the Internet 243 Security Glossary [RFC4949], authentication is "the process of 244 verifying a claim that a system entity or system resource has a 245 certain attribute value." Examples for attribute values are the ID 246 of a device, the type of the device or the name of its owner. 248 The security objectives the authorization mechanism aims at can only 249 be achieved if the authentication and the authorization mechanism 250 work together correctly. We use the term _authenticated 251 authorization_ to refer to a synthesis of mechanism for 252 authentication and authorization. 254 If used for authorization, the authenticated attributes must be 255 meaningful for the purpose of the authorization, i.e. the 256 authorization policy grants access permissions based on these 257 attributes. If the authorization policy assigns permissions to an 258 individual entity, the authenticated attributes must be suitable to 259 uniquely identify this entity. 261 In scenarios where devices are communicating autonomously there is 262 less need to uniquely identify an individual device. For a resource 263 owner, the fact that the device belongs to a certain company or that 264 it has a specific type (e.g. light bulb) is likely more important 265 than that it has a unique identifier. 267 Resource and device owners need to decide about the required level of 268 granularity for the authorization, ranging from _device 269 authorization_ over _owner authorization_ to _binary authorization_ 270 and _unrestricted authorization_. In the first case different access 271 permissions are granted to individual devices while in the second 272 case individual owners are authorized. If binary authorization is 273 used, all authenticated entities have the same access permissions. 274 Unrestricted authorization for an item of interest means that no 275 authorization mechanism is used (not even by authentication) and all 276 entities are able to access the item as they see fit. More fine- 277 grained authorization does not necessarily provide more security. 278 Resource and device owners need to consider that an entity should 279 only be granted the permissions it really needs to ensure the 280 confidentiality and integrity of resources. 282 For all cases where an authorization solution is needed (all but 283 Unrestricted Authorization), the authorizing party needs to be able 284 to authenticate the party that is to be authorized. Authentication 285 is therefore required for messages that contain representations of an 286 accessed item. More precisely, the authorizing party needs to make 287 sure that the receiver of a message containing a representation, and 288 the sender of a message containing a representation are authorized to 289 receive and send this message, respectively. To achieve this, the 290 integrity of these messages is required: Authenticity cannot be 291 assured if it is possible for an attacker to modify the message 292 during transmission. 294 5. Tasks 296 This section gives an overview of the tasks which must be performed 297 in the given scenario (see Section 2) to meet the security 298 requirements. 300 As described in the problem statement, either C or RS or both of them 301 are constrained. Therefore tasks which must be conducted by either C 302 or RS must be performable by constrained nodes. 304 5.1. Basic Scenario Tasks 306 This document does not assume a specific solution. We assume 307 however, that at least the following information is exchanged between 308 the client and the server: 310 o C transmits to RS which resource it requests to access, the kind 311 of action it wants to perform on the resource, and the parameters 312 needed for the action. 314 o RS transmits to C the result of the attempted access. 316 5.2. Security-Related Tasks 318 The reason for the communication is that C wants RS to process some 319 information. RS' reaction to C's access request might be processed 320 by C. The reason for using an authorization solution is to validate 321 that the entity that sent the information used for processing is 322 authorized to provide it. 324 To validate if a sender is authorized to send a received piece of 325 information, the receiver must determine the sender's authorization. 326 Correspondingly, to validate if a receiver is allowed to receive a 327 message, the sender must determine its authorization. This can only 328 be achieved with the help of an authentication mechanism. 330 5.3. Authentication-Related Tasks 332 Several steps must be conducted for authenticating certain attributes 333 of an entity and validating the authenticity of an information: 335 1. Attribute binding: The attribute that shall be verifiable must be 336 bound to a verifier, e.g. a key. To achieve this, an entity that 337 is authorized to conduct the attribute binding, the attribute 338 binding authority, checks if an entity actually has the 339 attributes it claims to have and then binds them to a verifier. 340 The binding authority must provide some kind of endorsement 341 information which enables other entities to validate this 342 binding. 344 Note: The attribute binding can be conducted using either symmetric 345 or asymmetric cryptography. 347 1. Verifier validation: The entity that wants to authenticate the 348 source of an information checks the attribute-verifier-binding 349 using the endorsement provided by the attribute binding 350 authority. 352 2. Authentication: The verifier is used for authenticating the 353 source of a data item, i.e. it is checked whether the data item 354 is bound to the verifier. Thus the attributes of the source can 355 be determined. 357 Step 1 is addressed in Appendix A.2.5. After the first step is 358 conducted, step 2 and step 3 can be performed when needed. They must 359 be performed together and thus are examined together as well. Tasks 360 for step 2 and 3 are Information authenticity (see Appendix A.2.1) 361 and secure communication (see Appendix A.2.3). 363 5.4. Authorization-Related Tasks 365 Several steps must be conducted for explicit authorization: 367 1. Configuration of authorization information: The respective owners 368 (CO and RO) must configure the authorization information 369 according to their authorization policy. An authorization 370 information must contain one or more permissions and the 371 attribute an entity must have to apply to this authorization. 373 2. Obtaining authorization information: Authorization information 374 must be made available to the entity which enforces the 375 authorization. 377 3. Authorization validation: The authorization of an entity with 378 certain attributes must be confirmed by applying the request in 379 conjunction with authenticated attributes to the policy provided 380 by the authorization information. 382 4. Authorization enforcement: According to the result of the 383 authorization validation the access to a resource is granted or 384 denied. 386 Tasks for step 1 are defined in Appendix A.2.6. Appendix A.2.4 387 addresses step 2. After step 1 and step 2 are conducted, step 3 and 388 step 4 can be performed when needed. Step 3 and step 4 must be 389 performed together and thus are examined together. Appendix A.2.2 390 introduces tasks for these steps. 392 6. Actors 394 This section describes the various actors in the architecture. An 395 actor consists of a set of tasks and additionally has an security 396 domain (client domain or server domain) and a level (constrained, 397 principal, less-constrained). Tasks are assigned to actors according 398 to their security domain and required level. 400 Note: Actors are a concept to understand the security requirements 401 for constrained devices. The architecture of an actual solution 402 might differ as long as the security requirements that derive from 403 the relationship between the identified actors are considered. 404 Several actors might share a single device or even be combined in a 405 single piece of software. Interfaces between actors may be realized 406 as protocols or be internal to such a piece of software. 408 The concept of actors is used to assign the tasks defined in 409 Appendix A to logical functional entities. 411 6.1. Constrained Level Actors 413 As described in the problem statement (see Section 2), either C or RS 414 or both of them may be located on a constrained node. We therefore 415 define that C and RS must be able to perform their tasks even if they 416 are located on a constrained node. Thus, C and RS are considered to 417 be Constrained Level Actors. 419 C performs the following tasks: 421 o Negotiate means for secure communication (Task TSecureComm, see 422 Appendix A.2.3). 424 o Validate that an entity is an authorized source for R (Task 425 TValSourceAuthz, see Appendix A.2.2). 427 o Securely transmit an access request (Task TSendReq, see 428 Appendix A.1.2). 430 o Validate that the response to an access request is authentic (Task 431 TAuthnResp, see Appendix A.2.1). 433 o Process the response to an access request (Task TProcResp, see 434 Appendix A.1.1). 436 RS performs the following tasks: 438 o Negotiate means for secure communication (Task TSecureComm, see 439 Appendix A.2.3). 441 o Validate the authenticity of an access request (Task TAuthnReq, 442 see Appendix A.2.1). 444 o Validate the authorization of the requester to access the 445 requested resource as requested (Task TValAccessAuthZ, see 446 Appendix A.2.2). 448 o Process an access request (Task TProcReq, see Appendix A.1.1). 450 o Securely transmit a response to an access request (Task TSendResp, 451 see Appendix A.1.2). 453 R is an item of interest such as a sensor or actuator value. R is 454 considered to be part of RS and not a separate actor. The device on 455 which RS is located might contain several resources of different 456 resource owners. For simplicity of exposition, these resources are 457 described as if they had separate RS. 459 As C and RS do not necessarily know each other they might belong to 460 different security domains. 462 ------- -------- 463 | C | -- requests resource ---> | RS | Constrained Level 464 ------- <-- provides resource--- -------- 466 Figure 2: Constrained Level Actors 468 6.2. Principal Level Actors 470 Our objective is that C and RS are under control of principals in the 471 physical world, the Client Owner (CO) and the Resource Owner (RO) 472 respectively. The owners decide about the security policies of their 473 respective devices and belong to the same security domain. 475 CO is in charge of C, i.e. CO specifies security policies for C, 476 e.g. with whom C is allowed to communicate. By definition, C and CO 477 belong to the same security domain. 479 CO must fulfill the following task: 481 o Configure for C authorization information for sources for R (Task 482 TConfigSourceAuthz, see Appendix A.2.6). 484 RO is in charge of R and RS. RO specifies authorization policies for 485 R and decides with whom RS is allowed to communicate. By definition, 486 R, RS and RO belong to the same security domain. 488 RO must fulfill the following task: 490 o Configure for RS authorization information for accessing R (Task 491 TConfigAccessAuthz, see Appendix A.2.6). 493 ------ ------ 494 | CO | | RO | Principal Level 495 ------ ------ 496 | | 497 in charge of in charge of 498 | | 499 V V 500 ------- -------- 501 | C | -- requests resource ---> | RS | Constrained Level 502 ------- <-- provides resource--- -------- 504 Figure 3: Constrained Level Actors and Principal Level Actors 506 6.3. Less-Constrained Level Actors 508 Constrained level actors can only fulfill a limited number of tasks 509 and may not have network connectivity all the time. To relieve them 510 from having to manage keys for numerous devices and conducting 511 computationally intensive tasks, another complexity level for actors 512 is introduced. An actor on the less-constrained level belongs to the 513 same security domain as its respective constrained level actor. They 514 also have the same principal. 516 The Client Authorization Manager (CAM) belongs to the same security 517 domain as C and CO. CAM acts on behalf of CO. It assists C in 518 authenticating RS and determining if RS is an authorized source for 519 R. CAM can do that because for C, CAM is the authority for claims 520 about RS. 522 CAM performs the following tasks: 524 o Validate on the client side that an entity has certain attributes 525 (Task TValSourceAttr, see Appendix A.2.5). 527 o Obtain authorization information about an entity from C's owner 528 and provide it to C. (Task TObtainSourceAuthz, see 529 Appendix A.2.4). 531 o Negotiate means for secure communication to communicate with C 532 (Task TSecureComm, see Appendix A.2.3). 534 The Server Authorization Manager (SAM) belongs to the same security 535 domain as R, RS and RO. SAM acts on behalf of RO. It supports RS by 536 authenticating C and determining C's permissions on R. SAM can do 537 that because for RS, SAM is the authority for claims about C. 539 SAM performs the following tasks: 541 o Validate on the server side that an entity has certain attributes 542 (Task TValReqAttr, see Appendix A.2.5). 544 o Obtain authorization information about an entity from RS' owner 545 and provide it to RS (Task TObtainAccessAuthz, see 546 Appendix A.2.4). 548 o Negotiate means for secure communication to communicate with RS 549 (Task TSecureComm, see Appendix A.2.3). 551 ------ ------ 552 | CO | | RO | Principal Level 553 ------ ------ 554 | | 555 in charge of in charge of 556 | | 557 V V 558 ---------- ----------- 559 | CAM | <- AuthN and AuthZ -> | SAM | Less-Constrained Level 560 ---------- ----------- 561 | | 562 authentication authentication 563 and authorization and authorization 564 support support 565 | | 566 V V 567 ------- -------- 568 | C | -- requests resource ---> | RS | Constrained Level 569 ------- <-- provides resource -- -------- 571 Figure 4: Overview of all Complexity Levels 573 For more detailed graphics please consult the PDF version. 575 7. Protocol Requirements 577 Devices on the less-constrained level potentially are more powerful 578 than constrained level devices in terms of processing power, memory, 579 non-volatile storage. This results in different requirements for the 580 protocols used on these levels. 582 7.1. Constrained Level Protocols 584 A protocol is considered to be on the constrained level if it is used 585 between the actors C and RS which are considered to be constrained 586 (see Section 6.1). C and RS might not belong to the same security 587 domain. Therefore, constrained level protocols are required to work 588 between different security domains. 590 Commonly used Internet protocols can not in every case be applied to 591 constrained environments. In some cases, tweaking and profiling is 592 required. In other cases it is beneficial to define new protocols 593 which were designed with the special characteristics of constrained 594 environments in mind. 596 On the constrained level, protocols must be used which address the 597 specific requirements of constrained environments. The Constrained 598 Application Protocol (CoAP) [RFC7252] should be used as transfer 599 protocol if possible. CoAP defines a security binding to Datagram 600 Transport Layer Security Protocol (DTLS) [RFC6347]. Thus, DTLS 601 should be used for channel security. 603 Constrained devices have only limited storage space and thus cannot 604 store large numbers of keys. This is especially important because 605 constrained networks are expected to consist of thousands of nodes. 606 Protocols on the constrained level should keep this limitation in 607 mind. 609 7.1.1. Cross Level Support Protocols 611 Protocols which operate between a constrained device on one side and 612 the corresponding less constrained device on the other are considered 613 to be (cross level) support protocols. Protocols used between C and 614 CAM or RS and SAM are therefore support protocols. 616 Support protocols must consider the limitations of their constrained 617 endpoint and therefore belong to the constrained level protocols. 619 7.2. Less-Constrained Level Protocols 621 A protocol is considered to be on the less-constrained level if it is 622 used between the actors CAM and SAM. CAM and SAM might belong to 623 different security domains. 625 On the less-constrained level, HTTP [RFC7230] and Transport Layer 626 Security (TLS) [RFC5246] can be used alongside or instead of CoAP and 627 DTLS. Moreover, existing security solutions for authentication and 628 authorization such as the Web Authorization Protocol (OAuth) 629 [RFC6749] and Kerberos [RFC4120] can likely be used without 630 modifications and there are no limitations for the use of a Public 631 Key Infrastructure (PKI). 633 8. IANA Considerations 635 None 637 9. Security Considerations 639 This document discusses security requirements for the ACE 640 architecture. 642 10. Acknowledgments 644 The author would like to thank Carsten Bormann, Olaf Bergmann, Robert 645 Cragie and Klaus Hartke for their valuable input and feedback. 647 11. References 649 11.1. Normative References 651 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 652 Constrained-Node Networks", RFC 7228, May 2014. 654 11.2. Informative References 656 [I-D.seitz-ace-usecases] 657 Seitz, L., Gerdes, S., Selander, G., Mani, M., and S. 658 Kumar, "ACE use cases", draft-seitz-ace-usecases-02 (work 659 in progress), October 2014. 661 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The 662 Kerberos Network Authentication Service (V5)", RFC 4120, 663 July 2005. 665 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", RFC 666 4949, August 2007. 668 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 669 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 671 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 672 Security Version 1.2", RFC 6347, January 2012. 674 [RFC6749] Hardt, D., "The OAuth 2.0 Authorization Framework", RFC 675 6749, October 2012. 677 [RFC7230] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol 678 (HTTP/1.1): Message Syntax and Routing", RFC 7230, June 679 2014. 681 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 682 Application Protocol (CoAP)", RFC 7252, June 2014. 684 Appendix A. List of Tasks 686 This section defines the tasks which must be performed in the given 687 scenario (see Section 2) starting from communication related tasks 688 and then deriving the required security-related tasks. An overview 689 of the tasks can be found in Section 5. 691 A task has the following structure: 693 o The name of the task which has the form TXXX 695 o One or more Requirements (if applicable) of the form RqXXX 697 o One or more Preconditions (if applicable) of the form PreXXX 699 o One or more Postconditions (if applicable) of the form PostXXX 701 Requirements have to be met _while_ performing the task. They derive 702 directly from the scenario (see Section 2) or from the security 703 requirements defined for the scenario. Preconditions have to be 704 fulfilled _before_ conducting the task. Postconditions are the 705 _results_ of the completed task. 707 We start our analysis with the processing tasks and define which 708 preconditions need to be fulfilled before these tasks can be 709 conducted. We then determine which tasks therefore need to be 710 performed first (have postconditions which match the respective 711 preconditions). 713 Note: Regarding the communication, C and RS are defined as entities 714 each having their set of attributes and a verifier which is bound to 715 these attributes. Attributes are not necessarily usable to identify 716 an individual C or RS. Several entities might have the same 717 attributes. 719 A.1. Basic Scenario 721 The intended result of the interaction between C and RS is that C has 722 successfully accessed R. C gets to know that its access request was 723 successful by receiving the answer from RS. 725 The transmission of information from C to RS comprises two parts: 726 sending the information on one side and receiving and processing it 727 on the other. Security has to be considered at each of these steps. 729 A.1.1. Processing Information 731 The purpose of the communication between C and RS is C's intent to 732 access R. To achieve this, RS must process the information about the 733 requested access and C must process the information in the response 734 to a requested access. The request and the response might both 735 contain resource values. 737 The confidentiality and integrity of R require that only authorized 738 entities are able to access R (see Rq0.1). Therefore, C and RS must 739 check that the information is authentic and that the source of the 740 information is authorized to provide it, before the information can 741 be processed. C must validate that RS is an authorized source for R. 742 RS must validate that C is authorized to access R as requested. 744 If proxies are used, it depends on the type of proxy how they are 745 integrated into the communication and what kind of security 746 relationships need to be established. A future version of this 747 document will provide more details on this topic. At this point we 748 assume that C and RS might receive the information either from RS or 749 C directly or from a proxy which is authorized to speak for the 750 respective communication partner. 752 o Task TProcResp: Process the response to an access request. 753 Description: C processes the response to an access request 754 according to the reason for requesting the resource in the first 755 place. The response might include resource values or information 756 about the results of a request. 757 Requirements: 758 * RqProcResp.1: Is performed by C (derives from the problem 759 statement). 760 * RqProcResp.2: Must be performable by a constrained device 761 (derives from the problem statement: C and / or RS are 762 constrained). 763 Preconditions: 764 * PreProcResp.1: A response to an access request was sent (see 765 Appendix A.1.2). 766 * PreProcResp.2 (required for Rq0.2): C validated that the 767 response to an access request is authentic, i.e. it stems from the 768 entity requested in TSendReq (see Appendix A.1.2), i.e. RS or an 769 entity which is authorized to speak for RS (see Appendix A.2.1). 770 * PreProcResp.3 (required for Rq0.2): C validated that RS or the 771 entity which is authorized to speak for RS is an authorized source 772 for R (see Appendix A.2.2). 773 Postcondition: 774 * PostProcResp.1: C processed the response. 776 o Task TProcReq: Process an access request. 777 Description: RS either performs an action on the resource 778 according to the information in the request, or determines the 779 reason for not performing an action. 780 Requirements: 781 * RqProcReq.1: Is performed by RS. 782 * RqProcReq.2: Must be performable by a constrained device 783 (derives from the problem statement: C and / or RS are 784 constrained). 785 Preconditions: 786 * PreProcReq.1: An access request was sent (see Appendix A.1.2). 788 * PreProcReq.2 (needed for Rq0.1): RS validated that the request 789 is authentic, i.e. it stems from C or an entity which is 790 authorized to speak for C and is fresh. (see Appendix A.2.1). 791 * PreProcReq.3 (needed for Rq0.1): RS validated the authorization 792 of C or the entity which is authorized to speak for C to access 793 the resource as requested (see Appendix A.2.2). 794 Postconditions: 795 * PostProcReq.1: The access request was processed (fulfills 796 PreSendResp.1, see Appendix A.1.2). 798 Note: The preconditions PreProcReq.2 and PreProcReq.3 must be 799 conducted together. RS must assure that the response is bound to a 800 verifier, the verifier is bound to certain attributes and the 801 authorization information refers to these attributes. 803 A.1.2. Sending Information 805 The information needed for processing has to be transmitted at some 806 point. C has to transmit to RS which resource it wants to access 807 with which actions and parameters. RS has to transmit to C the 808 result of the request. The request and the response might both 809 contain resource values. To fulfill Rq0.1, the confidentiality and 810 integrity of the transmitted data has to be assured. 812 If proxies are used, it depends on the type of proxy how they need to 813 be handled. A future version of this document will provide more 814 details on this topic. At this point we assume that C and RS might 815 transmit the message either to RS and C directly or to a proxy which 816 is authorized to speak for the respective communication partner. 818 o Task TSendReq: Securely transmit an access request. 819 Description: C wants to access a resource R hosted by the resource 820 server RS. To achieve this, it has to transmit some information 821 to RS such as the resource to be accessed, the action to be 822 performed on the resource and, if a writing access is requested, 823 the value to write. C might send the request directly to RS or to 824 an entity which is authorized to speak for RS. C assures that the 825 request reaches the proper R. C binds the request to C's verifier 826 to ensure the integrity of the message. C uses means to assure 827 that no unauthorized entity is able to access the information in 828 the request. 829 Requirements: 830 * RqSendReq.1: Is performed by C (derives from problem statement). 831 * RqSendReq.2: Must be performable by a constrained device 832 (derives from the problem statement: C and / or RS are 833 constrained). 834 * RqSendReq.3: As the request might contain resource values, the 835 confidentiality and integrity of the request must be ensured 836 during transmission. Only authorized parties must be able to read 837 or modify the request (derives from Rq0.1). 838 Preconditions: 839 * PreSendReq.1: Validate that the receiver is an authorized source 840 for R (see Appendix A.2.2). 841 * PreSendReq.2: To assure that the request reaches the proper RS, 842 that no unauthorized party is able to access the request, and that 843 the information in the request is bound to C's verifier it is 844 necessary to negotiate means for secure communication with RS (see 845 Appendix A.2.3). 846 Postconditions: 847 * PostSendReq.1: The request was sent securely to RS (necessary 848 for Rq0.1) (fulfills PreProcReq.1, see Appendix A.1.1). 850 Note: The preconditions PreSendReq.1 and PreSendReq.2 must be 851 conducted together. C must assure that the request reaches an entity 852 with certain attributes and that the authorization information refers 853 to these attributes. 855 o Task TSendResp: Securely transmit a response to an access request. 856 Description: RS sends a response to an access request to inform C 857 about the result of the request. RS must assure that response 858 reaches the requesting C. RS might send the response to C or to 859 an entity which is authorized to speak for C. The response might 860 contain resource values. RS binds the request to RS's verifier to 861 ensure the integrity of the message. RS uses means to assure that 862 no unauthorized entity is able to access the information in the 863 response. 864 Requirements: 865 * RqSendResp.1: Is performed by RS (derives from the problem 866 statement). 867 * RqSendResp.2: Must be performable by a constrained device 868 (derives from the problem statement: C and / or RS are 869 constrained). 870 * RqSendResp.3: As the response might contain resource values, the 871 confidentiality and integrity of the response must be ensured 872 during transmission. Only authorized parties must be able to read 873 or modify the response (derives from Rq0.1). 874 Preconditions: 875 * PreSendResp.1: An access request was processed (see 876 Appendix A.1.1). 877 * PreSendResp.2: If information about R is transmitted, validate 878 that the receiver is authorized to access R (see Appendix A.2.2). 879 * PreSendResp.3: RS must assure that the response reaches the 880 requesting C, no unauthorized party is able to access the response 881 and the information in the response is bound to RS' verifier: 882 Means for secure communication were negotiated (see 883 Appendix A.2.3). 885 Postconditions: 886 * PostSendResp.1: A response to an access request was sent 887 (fulfills PreProcResp.1, see Appendix A.1.1). 889 A.2. Security-Related Tasks 891 A.2.1. Information Authenticity 893 This section addresses information authentication, i.e. using the 894 verifier to validate the source of an information. Information 895 authentication must be conducted before processing received 896 information. C must validate that a response to an access request is 897 fresh, really stems from the queried RS (or an entity which is 898 authorized to speak for RS) and was not modified during transmission. 899 RS must validate that the information in the access request is fresh, 900 really stems from C (or an entity which is authorized to speak for C) 901 and was not modified during transmission. 903 The entity which processes the information must be the entity which 904 is validating the source of the information. 906 C and RS must assure that the authenticated source of the information 907 is authorized to provide the information. 909 o Task TAuthnResp: Validate that the response to an access request 910 is authentic. 911 Description: C checks if the response to an access request stems 912 from an entity in possession of the respective verifier and is 913 fresh. Thus, C validates that the response stems from the queried 914 RS or an entity which is authorized to speak for RS. 915 Requirements: 916 * RqAuthnResp.1: Must be performed by C. 917 * RqAuthnResp.2: Must be performable by a constrained device 918 (derives from the problem statement: C and / or RS are 919 constrained). 920 Preconditions: 921 * PreAuthnResp.1: Means for secure communication were negotiated 922 (see Appendix A.2.3). 923 Postconditions: 924 * PostAuthnResp.1: C knows that the response came from RS 925 (fulfills PreProcResp.2, see Appendix A.1.1). 927 o Task TAuthnReq: Validate the authenticity of a request. 928 Description: RS checks if the request stems from an entity in 929 possession of the respective verifier and is fresh. Thus, RS 930 validates that the request stems from C or an entity which is 931 authorized to speak for C. 932 Requirements: 934 * RqAuthnReq.1: Must be performed by RS. 935 * RqAuthnReq.2: Must be performable by a constrained device 936 (derives from the problem statement: C and / or RS are 937 constrained). 938 Preconditions: 939 * PreAuthnReq.1: Means for secure communication were negotiated 940 (see Appendix A.2.3). 941 Postconditions: 942 * PostAuthnReq.1: RS knows that the request is authentic (fulfills 943 PreProcReq.2, see Appendix A.1.1). 945 A.2.2. Authorization Validation 947 This section addresses the validation of the authorization of an 948 entity. The entity which processes the information must validate 949 that the source of the information is authorized to provide it. The 950 processing entity has to verify that the source of the information 951 has certain attributes which authorize it to provide the information: 952 C must validate that RS (or the entity which speaks for RS) is in 953 possession of attributes which are necessary for being an authorized 954 source for R. RS must validate that C (or the entity which speaks 955 for C) has attributes which are necessary for a permission to access 956 R as requested. 958 o Task TValSourceAuthz: Validate that an entity is an authorized 959 source for R. 960 Description: C checks if according to CO's authorization policy 961 and the authentication endorsement provided by the attribute 962 binding authority, RS (or an entity which speaks for RS) is 963 authorized to be a source for R. RS assures that the entity's 964 verifier is bound to certain attributes and the authorization 965 information refers to these attributes. 966 Requirements: 967 * RqValSourceAuthz.1: Is performed by C 968 * RqValSourceAuthz.2: Must be performable by a constrained device 969 (derives from the problem statement: C and / or RS are 970 constrained). 971 Preconditions: 972 * PreValSourceAuthz.1: Authorization information about the entity 973 is available. Requires obtaining authorization information about 974 the entity from C's owner (see Appendix A.2.4). 975 * PreValSourceAuthz.2: Means to validate that the entity has 976 certain attributes which are relevant for the authorization: 977 Requires validation of claims about RS (see Appendix A.2.5). 978 Postconditions: 979 * PostValSourceAuthz.1: The entity which performs the task knows 980 that an entity is an authorized source for R (fulfills 981 PreProcResp.3, see Appendix A.1.1 and PreSendReq.1, see 982 Appendix A.1.2). 984 o Task TValAccessAuthZ: Validate the authorization of the requester 985 to access the requested resource as requested. 986 Description: R's owner configures which clients are authorized to 987 perform which action on R. RS has to check if according to RO's 988 authorization policy and the authentication endorsement provided 989 by the attribute binding authority, C (or an entity which speaks 990 for C) is authorized to access R as requested. RS assures that 991 requester's verifier is bound to certain attributes and the 992 authorization information refers to these attributes. 993 Requirements: 994 * RqValAccessAuthz.1: Is performed by RS 995 * RqValAccessAuthz.2: Must be performable by a constrained device 996 (derives from the problem statement: C and / or RS are 997 constrained). 998 Preconditions: 999 * PreValAccessAuthz.1: Authorization information about the entity 1000 are available. Requires obtaining authorization information about 1001 the entity from RS's owner (see Appendix A.2.4). 1002 * PreValAccessAuthz.2: Means to validate that the entity has 1003 certain attributes which are relevant for the authorization: 1004 Requires validation of claims about C or the entity which speaks 1005 for C (see Appendix A.2.5). 1006 Postconditions: 1007 * PostValAccessAuthz.1: The entity which performs the task knows 1008 that an entity is authorized to access R with the requested action 1009 (fulfills PreProcReq.3, see Appendix A.1.1). 1011 A.2.3. Transmission Security 1013 To ensure the confidentiality and integrity of information during 1014 transmission means for secure communication have to be negotiated 1015 between the communicating parties. 1017 o Task TSecureComm: Negotiate means for secure communication. 1018 Description: To ensure the confidentiality and integrity of 1019 transmitted information, means for secure communication have to be 1020 negotiated. Channel security as well as object security solutions 1021 are possible. Details depend on the used solution and are not in 1022 the scope of this document. 1023 Requirements: 1024 * RqSecureComm.1: Must be performable by a constrained device 1025 (derives from the problem statement: C and / or RS are 1026 constrained). 1027 Preconditions: 1029 * PreSecureComm.1: Sender and receiver must be able to validate 1030 that the entity in possession of a certain verifier has the 1031 claimed attributes. (see Appendix A.2.5). 1032 Postconditions: 1033 * PostSecureComm.1: C and RS can communicate securely: The 1034 integrity and confidentiality of information is ensured during 1035 transmission. The sending entity can use means to assure that the 1036 information reaches the intended receiver so that no unauthorized 1037 party is able to access the information. The sending entity can 1038 bind the information to the entity's verifier (fulfills 1039 PreSendResp.3 and PreSendReq.2, see Appendix A.1.2 as well as 1040 PreAuthnResp.1 and PreAuthnReq.1, see Appendix A.2.1). 1042 A.2.4. Obtain Authorization information 1044 As described in Section 5.4, the authorization of an entity requires 1045 several steps. The authorization information must be configured by 1046 the owner and provided to the enforcing entity. 1048 o Task TObtainSourceAuthz: Obtain authorization information about an 1049 entity from C's owner. 1050 Description: C's owner defines authorized sources for R. The 1051 authorization information must be made available to C to enable it 1052 to enforce CO's authorization information. To facilitate the 1053 configuration for the owner this device should have a user 1054 interface. The authorization information has to be made available 1055 to C in a secure way. 1056 Requirements: 1057 * RqObtainSourceAuthz.1: Must be performed by an entity which is 1058 authorized by C's owner. 1059 * RqObtainSourceAuthz.2: Must be performed by an entity which is 1060 authorized to speak for C's owner concerning authorized sources 1061 for R. 1062 * RqObtainSourceAuthz.3: Should be performed by a device which can 1063 provide some sort of user interface to facilitate the 1064 configuration of authorization information for C's owner. 1065 Preconditions: 1066 * PreObtainSourceAuthz.1: C's owner configured authorized sources 1067 for R (see Appendix A.2.6). 1068 Postconditions: 1069 * PostObtainSourceAuthz.1: C obtained RS' authorization to be a 1070 source for R (fulfills PreValSourceAuthz.1, see Appendix A.2.2). 1072 o Task TObtainAccessAuthz: Obtain authorization information about an 1073 entity from RS' owner. 1074 Description: RS' owner defines if and how C is authorized to 1075 access R. The authorization information must be made available to 1076 RS to enable it to enforce RO's authorization policies. To 1077 facilitate the configuration for the owner this device should have 1078 a user interface. The authorization information has to be made 1079 available to RS in a secure way. 1080 Requirements: 1081 * RqObtainAccessAuthz.1: Must be performed by an entity which is 1082 authorized by R's owner. 1083 * RqObtainAccessAuthz.2: Must be performed by an entity which is 1084 authorized to speak for R's owner concerning authorization of 1085 access to R. 1086 * RqObtainAccessAuthz.3: Should be performed by a device which can 1087 provide some sort of user interface to facilitate the 1088 configuration of authorization information for R's owner. 1089 Preconditions: 1090 * PreObtainAccessAuthz.1: R's owner configured authorization 1091 information for the access to R (see Appendix A.2.6). 1092 Postconditions: 1093 * PostObtainAccessAuthz.1: RS obtained C's authorization for 1094 accessing R (fulfills PreValAccessAuthz.1, see Appendix A.2.2). 1096 A.2.5. Attribute Binding 1098 As described in Section 5.3, several steps must be conducted for 1099 authentication. This section addresses the binding of attributes to 1100 a verifier. 1102 For authentication it is necessary to validate if an entity has 1103 certain attributes. An example for such an attribute in the physical 1104 world is the name of a person or her age. In constrained 1105 environments, attributes might be the name of the owner or the type 1106 of device. Authorizations are bound to such attributes. 1108 The possession of attributes must be verifiable. For that purpose, 1109 attributes must be bound to a verifier. An example for a verifier in 1110 the physical world is a passport. In constrained environments, a 1111 verifier will likely be the knowledge of a secret. 1113 At some point, an authority has to check if an entity in possession 1114 of the verifier really possesses the claimed attributes. In the 1115 physical world, government agencies check your name and age before 1116 they give you a passport. 1118 The entity that validates the claims has to provide some kind of seal 1119 to make its endorsement verifiable for other entities and thus bind 1120 the attributes to the verifier. In the physical world passports are 1121 stamped by the issuing government agencies (and must only be provided 1122 by government agencies anyway). 1124 o Task TValSourceAttr: Validate on the client side that an entity 1125 has certain attributes. 1126 Description: The claim that an entity has certain attributes has 1127 to be checked and made available for C in a secure way. The 1128 validating party states that an entity in possession of a certain 1129 key has certain attributes and provides C with means to validate 1130 this endorsement. 1131 Requirements: 1132 * RqValSourceAttr.1: Must be performed by an entity which is 1133 authorized by C's owner to validate claims about RS. 1134 * RqValSourceAttr.3: The executing entity must have the means to 1135 fulfill the task (e.g. enough storage space, computational power, 1136 a user interface to facilitate the configuration of authentication 1137 policies). 1138 Postconditions: 1139 * PostValSourceAttr.1: Means for authenticating (validating the 1140 attribute-verifier-binding of) other entities were given to C in 1141 form of a verifiable endorsement (fulfills PreValSourceAuthz.2, 1142 see Appendix A.2.2 and PreSecureComm.1, see Appendix A.2.3). 1144 o Task TValReqAttr: Validate on the server side that an entity has 1145 certain attributes. 1146 Description: The claim that an entity has certain attributes has 1147 to be checked and made available for RS in a secure way. The 1148 validating party states that an entity in possession of a certain 1149 key has certain attributes and provides RS with means to validate 1150 this endorsement. 1151 Requirements: 1152 * RqValReqAttr.1: Must be performed by an entity which is 1153 authorized by RS' owner to validate claims about C. 1154 * RqValReqAttr.2: The executing entity must have the means to 1155 fulfill the task (e.g. enough storage space, computational power, 1156 a user interface to facilitate the configuration of authentication 1157 policies). 1158 Postconditions: 1159 * PostValReqAttr.1: Means for authenticating (validating the 1160 attribute-verifier-binding of) other entities were given to RS in 1161 form of a verifiable endorsement (fulfills PreValSourceAuthz.2, 1162 see Appendix A.2.2 and PreSecureComm.1, see Appendix A.2.3). 1164 A.2.6. Configuration of Authorization Information 1166 As stated in Section 5.4, several steps have to be conducted for 1167 authorization. This section is about the configuration of 1168 authorization information. 1170 The owner of a device or resource wants to be in control of her 1171 device and her data. For that purpose, she has to configure 1172 authorization information. C's owner might want to configure which 1173 attributes an entity must have to be allowed to represent R. R's 1174 owner might want to configure which attributes are required for 1175 accessing R with a certain action. 1177 o Task TConfigSourceAuthz: Configure for C authorization information 1178 for sources for R. 1179 Description: C's owner has to define authorized sources for R. 1180 Requirements: 1181 * RqConfigSourceAuthz.1: Must be provided by C's owner. 1182 Postconditions: 1183 * PostConfigSourceAuthz.1: The authorization information are 1184 available to a device which performs TObtainSourceAuthz (fulfills 1185 PreObtainSourceAuthz.1 see Appendix A.2.4). 1187 o Task TConfigAccessAuthz: Configure for RS authorization 1188 information for accessing R. 1189 Description: R's owner has to configure if and how an entity with 1190 certain attributes is allowed to access R. 1191 Requirements: 1192 * RqConfigAccessAuthz.1: Must be provided by R's owner. 1193 Postconditions: 1194 * PostConfigAccessAuthz.1: The authorization information are 1195 available to the device which performs TObtainAccessAuthz 1196 (fulfills PreObtainAccessAuthz.1, see Appendix A.2.4). 1198 Author's Address 1200 Stefanie Gerdes 1201 Universitaet Bremen TZI 1202 Postfach 330440 1203 Bremen D-28359 1204 Germany 1206 Phone: +49-421-218-63906 1207 Email: gerdes@tzi.org