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