idnits 2.17.1 draft-gerdes-ace-actors-01.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 (July 04, 2014) is 3583 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) -- Obsolete informational reference (is this intentional?): RFC 7231 (Obsoleted by RFC 9110) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 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 July 04, 2014 5 Expires: January 5, 2015 7 Actors in the ACE Architecture 8 draft-gerdes-ace-actors-01 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 January 5, 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. Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 3.1. Basic Scenario Tasks . . . . . . . . . . . . . . . . . . 5 70 3.2. Authentication-Related Tasks . . . . . . . . . . . . . . 5 71 3.3. Authorization-Related Tasks . . . . . . . . . . . . . . . 6 72 4. Actors . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 73 4.1. Constrained Level Actors . . . . . . . . . . . . . . . . 6 74 4.2. Principal Level Actors . . . . . . . . . . . . . . . . . 7 75 4.3. Less-Constrained Level Actors . . . . . . . . . . . . . . 8 76 5. Protocol Requirements . . . . . . . . . . . . . . . . . . . . 10 77 5.1. Constrained Level Protocols . . . . . . . . . . . . . . . 10 78 5.1.1. Cross Level Support Protocols . . . . . . . . . . . . 10 79 5.2. Less-Constrained Level Protocols . . . . . . . . . . . . 11 80 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 81 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 82 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 83 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 84 9.1. Normative References . . . . . . . . . . . . . . . . . . 11 85 9.2. Informative References . . . . . . . . . . . . . . . . . 11 86 Appendix A. List of Tasks . . . . . . . . . . . . . . . . . . . 12 87 A.1. Basic Scenario . . . . . . . . . . . . . . . . . . . . . 13 88 A.1.1. Processing Information . . . . . . . . . . . . . . . 13 89 A.1.2. Sending Information . . . . . . . . . . . . . . . . . 14 90 A.2. Security-Related Tasks . . . . . . . . . . . . . . . . . 16 91 A.2.1. Information Authenticity . . . . . . . . . . . . . . 16 92 A.2.2. Authorization Validation . . . . . . . . . . . . . . 17 93 A.2.3. Transmission Security . . . . . . . . . . . . . . . . 19 94 A.2.4. Obtain Authorization information . . . . . . . . . . 19 95 A.2.5. Attribute Binding . . . . . . . . . . . . . . . . . . 20 96 A.2.6. Configuration of Authorization Information . . . . . 22 97 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 23 99 1. Introduction 101 Constrained nodes are small devices with limited abilities which in 102 many cases are made to fulfill a single simple task. They have 103 limited system resources such as processing power, memory, non- 104 volatile storage and transmission capacity and additionally in most 105 cases do not have user interfaces and displays. Due to these 106 constraints, commonly used security protocols are not always easily 107 applicable. 109 Constrained nodes are expected to be integrated in all aspects of 110 everyday life and thus will be trusted with a lot of personal data. 111 Without appropriate security mechanisms attackers might gain control 112 over things relevant to our lives. Authentication and authorization 113 mechanisms are therefore prerequisites for a secure Internet of 114 Things. 116 The Authentication and Authorization in Constrained Environments 117 (ACE) Working Group aims at defining a solution for authenticated and 118 authorized access to resources. To achieve this, it is necessary to 119 develop a deep understanding of the problem to be solved. An 120 essential part of this is to identify the tasks which must be 121 performed to meet the security requirements in this scenario. 122 Moreover, these tasks need to be assigned to logical functional 123 entities which perform the tasks: the actors in the architecture. 124 Thus, relations between the actors and requirements for protocols can 125 be identified. 127 In this document, the required security related tasks are identified 128 as guidance for the development of authentication and authorization 129 solutions for constrained environments. Based on the tasks, an 130 architecture is developed to represent the relationships between the 131 logical functional entities involved. 133 1.1. Terminology 135 This document uses the following terminology: 137 Resource: an item of interest. It might contain sensor or actuator 138 values or other information. The author had resources in the 139 sense of RFC7231 [RFC7231] in mind, but for the considerations in 140 this document the kind of representation of the item is not 141 relevant. 143 Constrained node: a constrained device in the sense of [RFC7228]. 145 Actor: A logical functional entity within a device that performs one 146 or more tasks. Depending on the tasks, the device may need to 147 have certain system resources available. Multiple actors may 148 share, i.e. be present within, a device or even a piece of 149 software. 151 Resource Server (RS): An entity which hosts a Resource. 153 Client (C): An entity which attempts to access a resource on a 154 Resource Server. 156 Resource Owner (RO): The principal that owns the resource and 157 controls its access permissions. 159 Client Owner (CO): The principal that owns the Client and controls 160 permissions concerning authorized sources for R. 162 2. Problem Statement 164 The scenario the ACE Working Group addresses can be summarized as 165 follows: 167 o A Client (C) wants to access a Resource (R) on a Resource Server 168 (RS). 170 o A priori, C and RS do not necessarily know each other and have no 171 security relationship. 173 o C and / or RS are constrained. 175 ------- -------- 176 | C | -- requests resource ---> | RS | 177 ------- <-- provides resource--- -------- 179 Figure 1: Basic Scenario 181 There are some security requirements for this scenario including one 182 or more of: 184 o Rq0.1: No unauthorized entity has access to (or otherwise gains 185 knowledge of) R. 187 o Rq0.2: When C attempts to access R, that access reaches the proper 188 R. 190 3. Tasks 191 This section gives an overview of the tasks which must be performed 192 in the given scenario (see Section 2) to meet the security 193 requirements. 195 As described in the problem statement, either C or RS or both of them 196 are constrained. Therefore tasks which must be conducted by either C 197 or RS must be performable by constrained nodes. 199 3.1. Basic Scenario Tasks 201 This document does not assume a specific solution. We assume 202 however, that at least the following information is exchanged between 203 the client and the server: 205 o C transmits to RS which resource it requests to access, the kind 206 of action it wants to perform on the resource and the parameters 207 needed for the action. 209 o RS transmits to C the result of the attempted access. 211 3.2. Authentication-Related Tasks 213 According to the Internet Security Glossary [RFC4949], authentication 214 is "the process of verifying a claim that a system entity or system 215 resource has a certain attribute value." Examples for attribute 216 values are the ID of a device, the type of the device or the name of 217 its owner. Authentication attributes might be (but not necessarily 218 are) suitable to uniquely identify an individual entity. 220 Several steps must be conducted for authenticating certain attributes 221 of an entity and validating the authenticity of an information: 223 1. Attribute binding: The attribute that shall be verifiable must be 224 bound to a verifier, e.g. a key. To achieve this, an attribute 225 binding authority has to check if the entity in possession of a 226 certain verifier really possesses the attributes it claims to 227 have. The authority must provide some kind of endorsement 228 information which enables other entities to validate the binding. 230 2. Authentication: The entity which wants to use the verifier for 231 authenticating an entity checks the attribute-verifier-binding 232 using the endorsement of the claim validation authority and uses 233 the verifier for authenticating an entity or the source of an 234 information. 236 Step 1 is addressed in Appendix A.2.5. Two types of tasks were 237 defined for step 2: Information authenticity (see Appendix A.2.1) and 238 secure communication (see Appendix A.2.3). 240 3.3. Authorization-Related Tasks 242 Several steps must be conducted for authorization: 244 1. Configuration of authorization information: The owner must 245 configure the authorization information. 247 2. Obtaining authorization information: Authorization information 248 must be made available to the entity which enforces the 249 authorization. 251 3. Authorization validation: The authorization of an entity with 252 certain attributes must be checked by mapping the attributes 253 (which must be validated by authentication) to the authorization 254 information. 256 Tasks for step 1 are defined in Appendix A.2.6. Appendix A.2.4 257 addresses step 2. Appendix A.2.2 introduces tasks for step 3. 259 4. Actors 261 This section describes the various actors in the architecture. An 262 actor is identified by the tasks it has to fulfill. Several actors 263 might share a single device or even be combined in a single piece of 264 software. Interfaces between actors may be realized as protocols or 265 be internal to such a piece of software. 267 The concept of actors is used to assign the tasks defined in 268 Appendix A to logical functional entities. 270 4.1. Constrained Level Actors 272 As described in the problem statement (see Section 2), either C or RS 273 or both of them may be located on a constrained node. We therefore 274 define that C and RS must be able to perform their tasks even if they 275 are located on a constrained node. Thus, C and RS are considered to 276 be Constrained Level Actors. 278 C performs the following tasks: 280 o Negotiate means for secure communication (Task TSecureComm, see 281 Appendix A.2.3). 283 o Validate that an entity is an authorized source for R (Task 284 TValSourceAuthz, see Appendix A.2.2). 286 o Securely transmit an access request (Task TSendReq, see 287 Appendix A.1.2). 289 o Validate that the response to an access request is authentic (Task 290 TAuthnResp, see Appendix A.2.1). 292 o Process the response to an access request (Task TProcResp, see 293 Appendix A.1.1). 295 RS performs the following tasks: 297 o Negotiate means for secure communication (Task TSecureComm, see 298 Appendix A.2.3). 300 o Validate the authenticity of an access request (Task TAuthnReq, 301 see Appendix A.2.1). 303 o Validate the authorization of the requester to access the 304 requested resource as requested (Task TValAccessAuthZ, see 305 Appendix A.2.2). 307 o Process an access request (Task TProcReq, see Appendix A.1.1). 309 o Securely transmit a response to an access request (Task TSendResp, 310 see Appendix A.1.2). 312 R is an item of interest such as a sensor or actuator value. R is 313 considered to be part of RS and not a separate actor. The device on 314 which RS is located might contain several resources of different 315 resource owners. For simplicity of exposition, these resources are 316 described as if they had separate RS. 318 As C and RS do not necessarily know each other they might belong to 319 different security domains. 321 ------- -------- 322 | C | -- requests resource ---> | RS | Constrained Level 323 ------- <-- provides resource--- -------- 325 Figure 2: Constrained Level Actors 327 4.2. Principal Level Actors 329 Our objective is that C and RS are under control of principals in the 330 physical world, the Client Owner (CO) and the Resource Owner (RO) 331 respectively. The owners decide about the security policies of their 332 respective devices and belong to the same security domain. 334 CO is in charge of C, i.e. CO specifies security policies for C, e.g. 335 with whom C is allowed to communicate. By definition, C and CO 336 belong to the same security domain. 338 CO must fulfill the following task: 340 o Configure for C authorization information for sources for R (Task 341 TConfigSourceAuthz, see Appendix A.2.6). 343 RO is in charge of R and RS. RO specifies authorization policies for 344 R and decides with whom RS is allowed to communicate. By definition, 345 R, RS and RO belong to the same security domain. 347 RO must fulfill the following task: 349 o Configure for RS authorization information for accessing R (Task 350 TConfigAccessAuthz, see Appendix A.2.6). 352 ------ ------ 353 | CO | | RO | Principal Level 354 ------ ------ 355 | | 356 in charge of in charge of 357 | | 358 V V 359 ------- -------- 360 | C | -- requests resource ---> | RS | Constrained Level 361 ------- <-- provides resource--- -------- 363 Figure 3: Constrained Level Actors and Principal Level Actors 365 4.3. Less-Constrained Level Actors 367 Constrained level actors can only fulfill a limited number of tasks 368 and may not have network connectivity all the time. To relieve them 369 from having to manage keys for numerous devices and conducting 370 computationally intensive tasks, another complexity level for actors 371 is introduced. An actor on the less-constrained level belongs to the 372 same security domain as its respective constrained level actor. They 373 also have the same principal. 375 The Authentication Manager (AM) belongs to the same security domain 376 as C and CO. AM acts on behalf of CO. It assists C in 377 authenticating RS and determining if RS an authorized source for R. 378 AM can do that because for C, AM is the authority for claims about 379 RS. 381 AM performs the following tasks: 383 o Validate on the client side that an entity has certain attributes 384 (Task TValSourceAttr, see Appendix A.2.5). 386 o Obtain authorization information about an entity from C's owner 387 and provide it to C. (Task TObtainSourceAuthz, see 388 Appendix A.2.4). 390 o Negotiate means for secure communication to communicate with C 391 (Task TSecureComm, see Appendix A.2.3). 393 The Authorization Server (AS) belongs to the same security domain as 394 R, RS and RO. AS acts on behalf of RO. It supports RS by 395 authenticating C and determining C's permissions on R. AS can do that 396 because for RS, AS is the authority for claims about C. 398 AS performs the following tasks: 400 o Validate on the server side that an entity has certain attributes 401 (Task TValReqAttr, see Appendix A.2.5). 403 o Obtain authorization information about an entity from RS' owner 404 and provide it to RS (Task TObtainAccessAuthz, see 405 Appendix A.2.4). 407 o Negotiate means for secure communication to communicate with RS 408 (Task TSecureComm, see Appendix A.2.3). 410 ------ ------ 411 | CO | | RO | Principal Level 412 ------ ------ 413 | | 414 in charge of in charge of 415 | | 416 V V 417 ---------- ----------- 418 | AM | <-- AuthN and AuthZ -> | AS | Less-Constrained Level 419 ---------- ----------- 420 | | 421 authentication authentication 422 and authorization and authorization 423 support support 424 | | 425 V V 426 ------- -------- 427 | C | -- requests resource ---> | RS | Constrained Level 428 ------- <-- provides resource -- -------- 429 Figure 4: Overview of all Complexity Levels 431 For more detailed graphics please consult the PDF version. 433 5. Protocol Requirements 435 Devices on the less-constrained level potentially are more powerful 436 than constrained level devices in terms of processing power, memory, 437 non-volatile storage. This results in different requirements for the 438 protocols used on these levels. 440 5.1. Constrained Level Protocols 442 A protocol is considered to be on the constrained level if it is used 443 between the actors C and RS which are considered to be constrained 444 (see Section 4.1). C and RS might not belong to the same security 445 domain. Therefore, constrained level protocols are required to work 446 between different security domains. 448 Commonly used Internet protocols can not in every case be applied to 449 constrained environments. In some cases, tweaking and profiling is 450 required. In other cases it is beneficial to define new protocols 451 which were designed with the special characteristics of constrained 452 environments in mind. 454 On the constrained level, protocols must be used which address the 455 specific requirements of constrained environments. The Constrained 456 Application Protocol (CoAP) [RFC7252] should be used as transfer 457 protocol if possible. CoAP defines a security binding to Datagram 458 Transport Layer Security Protocol (DTLS) [RFC6347]. Thus, DTLS 459 should be used for channel security. 461 Constrained devices have only limited storage space and thus cannot 462 store large numbers of keys. This is especially important because 463 constrained networks are expected to consist of thousands of nodes. 464 Protocols on the constrained level should keep this limitation in 465 mind. 467 5.1.1. Cross Level Support Protocols 469 Protocols which operate between a constrained device on one side and 470 the corresponding less constrained device on the other are considered 471 to be (cross level) support protocols. Protocols used between C and 472 AM or RS and AS are therefore support protocols. 474 Support protocols must consider the limitations of their constrained 475 endpoint and therefore belong to the constrained level protocols. 477 5.2. Less-Constrained Level Protocols 479 A protocol is considered to be on the less-constrained level if it is 480 used between the actors AM and AS. AM and AS might belong to 481 different security domains. 483 On the less-constrained level, HTTP [RFC7230] and Transport Layer 484 Security (TLS) [RFC5246] can be used alongside or instead of CoAP and 485 DTLS. Moreover, existing security solutions for authentication and 486 authorization such as the Web Authorization Protocol (OAuth) 487 [RFC6749] and Kerberos [RFC4120] can likely be used without 488 modifications and there are no limitations for the use of a Public 489 Key Infrastructure (PKI). 491 6. IANA Considerations 493 None 495 7. Security Considerations 497 This document discusses security requirements for the ACE 498 architecture. 500 8. Acknowledgments 502 The author would like to thank Carsten Bormann, Olaf Bergmann and 503 Klaus Hartke for their valuable input and feedback. 505 9. References 507 9.1. Normative References 509 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 510 Constrained-Node Networks", RFC 7228, May 2014. 512 9.2. Informative References 514 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The 515 Kerberos Network Authentication Service (V5)", RFC 4120, 516 July 2005. 518 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", RFC 519 4949, August 2007. 521 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 522 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 524 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 525 Security Version 1.2", RFC 6347, January 2012. 527 [RFC6749] Hardt, D., "The OAuth 2.0 Authorization Framework", RFC 528 6749, October 2012. 530 [RFC7230] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol 531 (HTTP/1.1): Message Syntax and Routing", RFC 7230, June 532 2014. 534 [RFC7231] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol 535 (HTTP/1.1): Semantics and Content", RFC 7231, June 2014. 537 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 538 Application Protocol (CoAP)", RFC 7252, June 2014. 540 Appendix A. List of Tasks 542 This section defines the tasks which must be performed in the given 543 scenario (see Section 2) starting from communication related tasks 544 and then deriving the required security-related tasks. An overview 545 of the tasks can be found in Section 3. 547 A task has the following structure: 549 o The name of the task which has the form TXXX 551 o One or more Requirements (if applicable) of the form RqXXX 553 o One or more Preconditions (if applicable) of the form PreXXX 555 o One or more Postconditions (if applicable) of the form PostXXX 557 Requirements have to be met _while_ performing the task. They derive 558 directly from the scenario (see Section 2) or from the security 559 requirements defined for the scenario. Preconditions have to be 560 fulfilled _before_ conducting the task. Postconditions are the 561 _results_ of the completed task. 563 We start our analysis with the processing tasks and define which 564 preconditions need to be fulfilled before these tasks can be 565 conducted. We then determine which tasks therefore need to be 566 performed first (have postconditions which match the respective 567 preconditions). 569 Note: Regarding the communication, C and RS are defined as entities 570 each having their set of attributes and a verifier which is bound to 571 these attributes. Attributes are not necessarily usable to identify 572 an individual C or RS. Several entities might have the same 573 attributes. 575 A.1. Basic Scenario 577 The intended result of the interaction between C and RS is that C has 578 successfully accessed R. C gets to know that its access request was 579 successful by receiving the answer from RS. 581 The transmission of information from C to RS comprises two parts: 582 sending the information on one side and receiving and processing it 583 on the other. Security has to be considered at each of these steps. 585 A.1.1. Processing Information 587 The purpose of the communication between C and RS is C's intent to 588 access R. To achieve this, RS must process the information about the 589 requested access and C must process the information in the response 590 to a requested access. The request and the response might both 591 contain resource values. 593 The confidentiality and integrity of R require that only authorized 594 entities are able to access R (see Rq0.1). Therefore, C and RS must 595 check that the information is authentic and that the source of the 596 information is authorized to provide it, before the information can 597 be processed. C must validate that RS is an authorized source for R. 598 RS must validate that C is authorized to access R as requested. 600 If proxies are used, it depends on the type of proxy how they are 601 integrated into the communication and what kind of security 602 relationships need to be established. A future version of this 603 document will provide more details on this topic. At this point we 604 assume that C and RS might receive the information either from RS or 605 C directly or from a proxy which is authorized to speak for the 606 respective communication partner. 608 o Task TProcResp: Process the response to an access request. 609 Description: C processes the response to an access request 610 according to the reason for requesting the resource in the first 611 place. The response might include resource values or information 612 about the results of a request. 613 Requirements: 614 * RqProcResp.1: Is performed by C (derives from the problem 615 statement). 616 * RqProcResp.2: Must be performable by a constrained device 617 (derives from the problem statement: C and / or RS are 618 constrained). 619 Preconditions: 621 * PreProcResp.1: A response to an access request was sent (see 622 Appendix A.1.2). 623 * PreProcResp.2 (required for Rq0.2): C validated that the 624 response to an access request is authentic, i.e. it stems from the 625 entity requested in TSendReq (see Appendix A.1.2), i.e. RS or an 626 entity which is authorized to speak for RS (see Appendix A.2.1). 627 * PreProcResp.3 (required for Rq0.2): C validated that RS or the 628 entity which is authorized to speak for RS is an authorized source 629 for R (see Appendix A.2.2). 630 Postcondition: 631 * PostProcResp.1: C processed the response. 633 o Task TProcReq: Process an access request. 634 Description: RS either performs an action on the resource 635 according to the information in the request, or determines the 636 reason for not performing an action. 637 Requirements: 638 * RqProcReq.1: Is performed by RS. 639 * RqProcReq.2: Must be performable by a constrained device 640 (derives from the problem statement: C and / or RS are 641 constrained). 642 Preconditions: 643 * PreProcReq.1: An access request was sent (see Appendix A.1.2). 644 * PreProcReq.2 (needed for Rq0.1): RS validated that the request 645 is authentic, i.e. it stems from C or an entity which is 646 authorized to speak for C and is fresh. (see Appendix A.2.1). 647 * PreProcReq.3 (needed for Rq0.1): RS validated the authorization 648 of C or the entity which is authorized to speak for C to access 649 the resource as requested (see Appendix A.2.2). 650 Postconditions: 651 * PostProcReq.1: The access request was processed (fulfills 652 PreSendResp.1, see Appendix A.1.2). 654 Note: The preconditions PreProcReq.2 and PreProcReq.3 must be 655 conducted together. RS must assure that the response is bound to a 656 verifier, the verifier is bound to certain attributes and the 657 authorization information refers to these attributes. 659 A.1.2. Sending Information 661 The information needed for processing has to be transmitted at some 662 point. C has to transmit to RS which resource it wants to access 663 with which actions and parameters. RS has to transmit to C the 664 result of the request. The request and the response might both 665 contain resource values. To fulfill Rq0.1, the confidentiality and 666 integrity of the transmitted data has to be assured. 668 If proxies are used, it depends on the type of proxy how they need to 669 be handled. A future version of this document will provide more 670 details on this topic. At this point we assume that C and RS might 671 transmit the message either to RS and C directly or to a proxy which 672 is authorized to speak for the respective communication partner. 674 o Task TSendReq: Securely transmit an access request. 675 Description: C wants to access a resource R hosted by the resource 676 server RS. To achieve this, it has to transmit some information 677 to RS such as the resource to be accessed, the action to be 678 performed on the resource and, if a writing access is requested, 679 the value to write. C might send the request directly to RS or to 680 an entity which is authorized to speak for RS. C assures that the 681 request reaches the proper R. C binds the request to C's verifier 682 to ensure the integrity of the message. C uses means to assure 683 that no unauthorized entity is able to access the information in 684 the request. 685 Requirements: 686 * RqSendReq.1: Is performed by C (derives from problem statement). 687 * RqSendReq.2: Must be performable by a constrained device 688 (derives from the problem statement: C and / or RS are 689 constrained). 690 * RqSendReq.3: As the request might contain resource values, the 691 confidentiality and integrity of the request must be ensured 692 during transmission. Only authorized parties must be able to read 693 or modify the request (derives from Rq0.1). 694 Preconditions: 695 * PreSendReq.1: Validate that the receiver is an authorized source 696 for R (see Appendix A.2.2). 697 * PreSendReq.2: To assure that the request reaches the proper RS, 698 that no unauthorized party is able to access the request, and that 699 the information in the request is bound to C's verifier it is 700 necessary to negotiate means for secure communication with RS (see 701 Appendix A.2.3). 702 Postconditions: 703 * PostSendReq.1: The request was sent securely to RS (necessary 704 for Rq0.1) (fulfills PreProcReq.1, see Appendix A.1.1). 706 Note: The preconditions PreSendReq.1 and PreSendReq.2 must be 707 conducted together. C must assure that the request reaches an entity 708 with certain attributes and that the authorization information refers 709 to these attributes. 711 o Task TSendResp: Securely transmit a response to an access request. 712 Description: RS sends a response to an access request to inform C 713 about the result of the request. RS must assure that response 714 reaches the requesting C. RS might send the response to C or to an 715 entity which is authorized to speak for C. The response might 716 contain resource values. RS binds the request to RS's verifier to 717 ensure the integrity of the message. RS uses means to assure that 718 no unauthorized entity is able to access the information in the 719 response. 720 Requirements: 721 * RqSendResp.1: Is performed by RS (derives from the problem 722 statement). 723 * RqSendResp.2: Must be performable by a constrained device 724 (derives from the problem statement: C and / or RS are 725 constrained). 726 * RqSendResp.3: As the response might contain resource values, the 727 confidentiality and integrity of the response must be ensured 728 during transmission. Only authorized parties must be able to read 729 or modify the response (derives from Rq0.1). 730 Preconditions: 731 * PreSendResp.1: An access request was processed (see 732 Appendix A.1.1). 733 * PreSendResp.2: If information about R is transmitted, validate 734 that the receiver is authorized to access R (see Appendix A.2.2). 735 * PreSendResp.3: RS must assure that the response reaches the 736 requesting C, no unauthorized party is able to access the response 737 and the information in the response is bound to RS' verifier: 738 Means for secure communication were negotiated (see 739 Appendix A.2.3). 740 Postconditions: 741 * PostSendResp.1: A response to an access request was sent 742 (fulfills PreProcResp.1, see Appendix A.1.1). 744 A.2. Security-Related Tasks 746 A.2.1. Information Authenticity 748 This section addresses information authentication, i.e. using the 749 verifier to validate the source of an information. Information 750 authentication must be conducted before processing received 751 information. C must validate that a response to an access request is 752 fresh, really stems from the queried RS (or an entity which is 753 authorized to speak for RS) and was not modified during transmission. 754 RS must validate that the information in the access request is fresh, 755 really stems from C (or an entity which is authorized to speak for C) 756 and was not modified during transmission. 758 The entity which processes the information must be the entity which 759 is validating the source of the information. 761 C and RS must assure that the authenticated source of the information 762 is authorized to provide the information. 764 o Task TAuthnResp: Validate that the response to an access request 765 is authentic. 766 Description: C checks if the response to an access request stems 767 from an entity in possession of the respective verifier and is 768 fresh. Thus, C validates that the response stems from the queried 769 RS or an entity which is authorized to speak for RS. 770 Requirements: 771 * RqAuthnResp.1: Must be performed by C. 772 * RqAuthnResp.2: Must be performable by a constrained device 773 (derives from the problem statement: C and / or RS are 774 constrained). 775 Preconditions: 776 * PreAuthnResp.1: Means for secure communication were negotiated 777 (see Appendix A.2.3). 778 Postconditions: 779 * PostAuthnResp.1: C knows that the response came from RS 780 (fulfills PreProcResp.2, see Appendix A.1.1). 782 o Task TAuthnReq: Validate the authenticity of a request. 783 Description: RS checks if the request stems from an entity in 784 possession of the respective verifier and is fresh. Thus, RS 785 validates that the request stems from C or an entity which is 786 authorized to speak for C. 787 Requirements: 788 * RqAuthnReq.1: Must be performed by RS. 789 * RqAuthnReq.2: Must be performable by a constrained device 790 (derives from the problem statement: C and / or RS are 791 constrained). 792 Preconditions: 793 * PreAuthnReq.1: Means for secure communication were negotiated 794 (see Appendix A.2.3). 795 Postconditions: 796 * PostAuthnReq.1: RS knows that the request is authentic (fulfills 797 PreProcReq.2, see Appendix A.1.1). 799 A.2.2. Authorization Validation 801 This section addresses the validation of the authorization of an 802 entity. The entity which processes the information must validate 803 that the source of the information is authorized to provide it. The 804 processing entity has to verify that the source of the information 805 has certain attributes which authorize it to provide the information: 806 C must validate that RS (or the entity which speaks for RS) is in 807 possession of attributes which are necessary for being an authorized 808 source for R. RS must validate that C (or the entity which speaks for 809 C) has attributes which are necessary for a permission to access R as 810 requested. 812 o Task TValSourceAuthz: Validate that an entity is an authorized 813 source for R. 814 Description: C checks if according to CO's authorization policy 815 and the authentication endorsement provided by the attribute 816 binding authority, RS (or an entity which speaks for RS) is 817 authorized to be a source for R. RS assures that the entity's 818 verifier is bound to certain attributes and the authorization 819 information refers to these attributes. 820 Requirements: 821 * RqValSourceAuthz.1: Is performed by C 822 * RqValSourceAuthz.2: Must be performable by a constrained device 823 (derives from the problem statement: C and / or RS are 824 constrained). 825 Preconditions: 826 * PreValSourceAuthz.1: Authorization information about the entity 827 are available. Requires obtaining authorization information about 828 the entity from C's owner (see Appendix A.2.4). 829 * PreValSourceAuthz.2: Means to validate that the entity has 830 certain attributes which are relevant for the authorization: 831 Requires validation of claims about RS (see Appendix A.2.5). 832 Postconditions: 833 * PostValSourceAuthz.1: The entity which performs the task knows 834 that an entity is an authorized source for R (fulfills 835 PreProcResp.3, see Appendix A.1.1 and PreSendReq.1, see 836 Appendix A.1.2). 838 o Task TValAccessAuthZ: Validate the authorization of the requester 839 to access the requested resource as requested. 840 Description: R's owner configures which clients are authorized to 841 perform which action on R. RS has to check if according to RO's 842 authorization policy and the authentication endorsement provided 843 by the attribute binding authority, C (or an entity which speaks 844 for C) is authorized to access R as requested. RS assures that 845 requester's verifier is bound to certain attributes and the 846 authorization information refers to these attributes. 847 Requirements: 848 * RqValAccessAuthz.1: Is performed by RS 849 * RqValAccessAuthz.2: Must be performable by a constrained device 850 (derives from the problem statement: C and / or RS are 851 constrained). 852 Preconditions: 853 * PreValAccessAuthz.1: Authorization information about the entity 854 are available. Requires obtaining authorization information about 855 the entity from RS's owner (see Appendix A.2.4). 856 * PreValAccessAuthz.2: Means to validate that the entity has 857 certain attributes which are relevant for the authorization: 858 Requires validation of claims about C or the entity which speaks 859 for C (see Appendix A.2.5). 861 Postconditions: 862 * PostValAccessAuthz.1: The entity which performs the task knows 863 that an entity is authorized to access R with the requested action 864 (fulfills PreProcReq.3, see Appendix A.1.1). 866 A.2.3. Transmission Security 868 To ensure the confidentiality and integrity of information during 869 transmission means for secure communication have to be negotiated 870 between the communicating parties. 872 o Task TSecureComm: Negotiate means for secure communication. 873 Description: To ensure the confidentiality and integrity of 874 transmitted information, means for secure communication have to be 875 negotiated. Channel security as well as object security solutions 876 are possible. Details depend on the used solution and are not in 877 the scope of this document. 878 Requirements: 879 * RqSecureComm.1: Must be performable by a constrained device 880 (derives from the problem statement: C and / or RS are 881 constrained). 882 Preconditions: 883 * PreSecureComm.1: Sender and receiver must be able to validate 884 that the entity in possession of a certain verifier has the 885 claimed attributes. (see Appendix A.2.5). 886 Postconditions: 887 * PostSecureComm.1: C and RS can communicate securely: The 888 integrity and confidentiality of information is ensured during 889 transmission. The sending entity can use means to assure that the 890 information reaches the intended receiver so that no unauthorized 891 party is able to access the information. The sending entity can 892 bind the information to the entity's verifier (fulfills 893 PreSendResp.3 and PreSendReq.2, see Appendix A.1.2 as well as 894 PreAuthnResp.1 and PreAuthnReq.1, see Appendix A.2.1). 896 A.2.4. Obtain Authorization information 898 As described in Section 3.3, the authorization of an entity requires 899 several steps. The authorization information must be configured by 900 the owner and provided to the enforcing entity. 902 o Task TObtainSourceAuthz: Obtain authorization information about an 903 entity from C's owner. 905 Description: C's owner defines authorized sources for R. The 906 authorization information must be made available to C to enable it 907 to enforce CO's authorization information. To facilitate the 908 configuration for the owner this device should have a user 909 interface. The authorization information has to be made available 910 to C in a secure way. 911 Requirements: 912 * RqObtainSourceAuthz.1: Must be performed by an entity which 913 belongs to C's security domain. 914 * RqObtainSourceAuthz.2: Must be performed by an entity which is 915 authorized to speak for C's owner concerning authorized sources 916 for R. 917 * RqObtainSourceAuthz.3: Should be performed by a device which can 918 provide some sort of user interface to facilitate the 919 configuration of authorization information for C's owner. 920 Preconditions: 921 * PreObtainSourceAuthz.1: C's owner configured authorized sources 922 for R (see Appendix A.2.6). 923 Postconditions: 924 * PostObtainSourceAuthz.1: C obtained RS' authorization to be a 925 source for R (fulfills PreValSourceAuthz.1, see Appendix A.2.2). 927 o Task TObtainAccessAuthz: Obtain authorization information about an 928 entity from RS' owner. 929 Description: RS' owner defines if and how C is authorized to 930 access R. The authorization information must be made available to 931 RS to enable it to enforce RO's authorization policies. To 932 facilitate the configuration for the owner this device should have 933 a user interface. The authorization information has to be made 934 available to RS in a secure way. 935 Requirements: 936 * RqObtainAccessAuthz.1: Must be performed by an entity which 937 belongs to R's security domain. 938 * RqObtainAccessAuthz.2: Must be performed by an entity which is 939 authorized to speak for R's owner concerning authorization of 940 access to R. 941 * RqObtainAccessAuthz.3: Should be performed by a device which can 942 provide some sort of user interface to facilitate the 943 configuration of authorization information for R's owner. 944 Preconditions: 945 * PreObtainAccessAuthz.1: R's owner configured authorization 946 information for the access to R (see Appendix A.2.6). 947 Postconditions: 948 * PostObtainAccessAuthz.1: RS obtained C's authorization for 949 accessing R (fulfills PreValAccessAuthz.1, see Appendix A.2.2). 951 A.2.5. Attribute Binding 952 As described in Section 3.2, several steps must be conducted for 953 authentication. This section addresses the binding of attributes to 954 a verifier. 956 For authentication it is necessary to validate if an entity has 957 certain attributes. An example for such an attribute in the physical 958 world is the name of a person or her age. In constrained 959 environments, attributes might be the name of the owner or the type 960 of device. Authorizations are bound to such attributes. 962 The possession of attributes must be verifiable. For that purpose, 963 attributes must be bound to a verifier. An example for a verifier in 964 the physical world is a passport. In constrained environments, a 965 verifier will likely be the knowledge of a secret. 967 At some point, an authority has to check if an entity in possession 968 of the verifier really possesses the claimed attributes. In the 969 physical world, government agencies check your name and age before 970 they give you a passport. 972 The entity that validates the claims has to provide some kind of seal 973 to make its endorsement verifiable for other entities and thus bind 974 the attributes to the verifier. In the physical world passports are 975 stamped by the issuing government agencies (and must only be provided 976 by government agencies anyway). 978 o Task TValSourceAttr: Validate on the client side that an entity 979 has certain attributes. 980 Description: The claim that an entity has certain attributes has 981 to be checked and made available for C in a secure way. The 982 validating party states that an entity in possession of a certain 983 key has certain attributes and provides C with means to validate 984 this endorsement. 985 Requirements: 986 * RqValSourceAttr.1: Must be performed by an entity which belongs 987 to C's security domain and is an authority for claims about RS. 988 * RqValSourceAttr.2: The executing entity must have the means to 989 fulfill the task (e.g. enough storage space, computational power, 990 a user interface to facilitate the configuration of authentication 991 policies). 992 Postconditions: 993 * PostValSourceAttr.1: Means for authenticating (validating the 994 attribute-verifier-binding of) other entities were given to C in 995 form of a verifiable endorsement (fulfills PreValSourceAuthz.2, 996 see Appendix A.2.2 and PreSecureComm.1, see Appendix A.2.3). 998 o Task TValReqAttr: Validate on the server side that an entity has 999 certain attributes. 1001 Description: The claim that an entity has certain attributes has 1002 to be checked and made available for RS in a secure way. The 1003 validating party states that an entity in possession of a certain 1004 key has certain attributes and provides RS with means to validate 1005 this endorsement. 1006 Requirements: 1007 * RqValReqAttr.1: Must be performed by an entity which belongs to 1008 RS' security domain and is an authority for claims about C. 1009 * RqValReqAttr.2: The executing entity must have the means to 1010 fulfill the task (e.g. enough storage space, computational power, 1011 a user interface to facilitate the configuration of authentication 1012 policies). 1013 Postconditions: 1014 * PostValReqAttr.1: Means for authenticating (validating the 1015 attribute-verifier-binding of) other entities were given to RS in 1016 form of a verifiable endorsement (fulfills PreValSourceAuthz.2, 1017 see Appendix A.2.2 and PreSecureComm.1, see Appendix A.2.3). 1019 A.2.6. Configuration of Authorization Information 1021 As stated in Section 3.3, several steps have to be conducted for 1022 authorization. This section is about the configuration of 1023 authorization information. 1025 The owner of a device or resource wants to be in control of her 1026 device and her data. For that purpose, she has to configure 1027 authorization information. C's owner might want to configure which 1028 attributes an entity must possess to be a source for R. R's owner 1029 might want to configure which attributes are required for accessing R 1030 with a certain action. 1032 o Task TConfigSourceAuthz: Configure for C authorization information 1033 for sources for R. 1034 Description: C's owner has to define authorized sources for R. 1035 Requirements: 1036 * RqConfigSourceAuthz.1: Must be provided by C's owner. 1037 Postconditions: 1038 * PostConfigSourceAuthz.1: The authorization information are 1039 available to a device which performs TObtainSourceAuthz (fulfills 1040 PreObtainSourceAuthz.1 see Appendix A.2.4). 1042 o Task TConfigAccessAuthz: Configure for RS authorization 1043 information for accessing R. 1044 Description: R's owner has to configure if and how an entity with 1045 certain attributes is allowed to access R. 1046 Requirements: 1047 * RqConfigAccessAuthz.1: Must be provided by R's owner. 1048 Postconditions: 1050 * PostConfigAccessAuthz.1: The authorization information are 1051 available to the device which performs TObtainAccessAuthz 1052 (fulfills PreObtainAccessAuthz.1, see Appendix A.2.4). 1054 Author's Address 1056 Stefanie Gerdes 1057 Universitaet Bremen TZI 1058 Postfach 330440 1059 Bremen D-28359 1060 Germany 1062 Phone: +49-421-218-63906 1063 Email: gerdes@tzi.org