idnits 2.17.1 draft-ietf-ace-actors-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 22, 2018) is 1984 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-13) exists of draft-ietf-core-coap-pubsub-05 == Outdated reference: A later version (-16) exists of draft-ietf-core-object-security-15 == Outdated reference: A later version (-16) exists of draft-irtf-t2trg-iot-seccons-15 -- 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 (~~), 4 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ACE Working Group S. Gerdes 3 Internet-Draft Universitaet Bremen TZI 4 Intended status: Informational L. Seitz 5 Expires: April 25, 2019 RISE SICS 6 G. Selander 7 Ericsson AB 8 C. Bormann, Ed. 9 Universitaet Bremen TZI 10 October 22, 2018 12 An architecture for authorization in constrained environments 13 draft-ietf-ace-actors-07 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 https://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 April 25, 2019. 42 Copyright Notice 44 Copyright (c) 2018 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 (https://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 60 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 61 2. Architecture and High-level Problem Statement . . . . . . . . 6 62 2.1. Elements of an Architecture . . . . . . . . . . . . . . . 6 63 2.2. Architecture Variants . . . . . . . . . . . . . . . . . . 9 64 2.3. Information Flows . . . . . . . . . . . . . . . . . . . . 11 65 3. Security Objectives . . . . . . . . . . . . . . . . . . . . . 13 66 3.1. End-to-End Security Objectives in Multi-Hop Scenarios . . 13 67 4. Authentication and Authorization . . . . . . . . . . . . . . 14 68 5. Actors and their Tasks . . . . . . . . . . . . . . . . . . . 16 69 5.1. Constrained Level Actors . . . . . . . . . . . . . . . . 17 70 5.2. Principal Level Actors . . . . . . . . . . . . . . . . . 18 71 5.3. Less-Constrained Level Actors . . . . . . . . . . . . . . 18 72 6. Kinds of Protocols . . . . . . . . . . . . . . . . . . . . . 19 73 6.1. Constrained Level Protocols . . . . . . . . . . . . . . . 20 74 6.1.1. Cross Level Support Protocols . . . . . . . . . . . . 20 75 6.2. Less-Constrained Level Protocols . . . . . . . . . . . . 20 76 7. Elements of a Solution . . . . . . . . . . . . . . . . . . . 21 77 7.1. Authorization . . . . . . . . . . . . . . . . . . . . . . 21 78 7.2. Authentication . . . . . . . . . . . . . . . . . . . . . 22 79 7.3. Communication Security . . . . . . . . . . . . . . . . . 22 80 7.4. Cryptographic Keys . . . . . . . . . . . . . . . . . . . 23 81 8. Assumptions and Requirements . . . . . . . . . . . . . . . . 24 82 8.1. Constrained Devices . . . . . . . . . . . . . . . . . . . 24 83 8.2. Server-side Authorization . . . . . . . . . . . . . . . . 24 84 8.3. Client-side Authorization Information . . . . . . . . . . 25 85 8.4. Resource Access . . . . . . . . . . . . . . . . . . . . . 25 86 8.5. Keys and Cipher Suites . . . . . . . . . . . . . . . . . 25 87 8.6. Network Considerations . . . . . . . . . . . . . . . . . 26 88 9. Security Considerations . . . . . . . . . . . . . . . . . . . 26 89 9.1. Physical Attacks on Sensor and Actuator Networks . . . . 27 90 9.2. Clocks and Time Measurements . . . . . . . . . . . . . . 27 91 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 92 11. Informative References . . . . . . . . . . . . . . . . . . . 28 93 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 30 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30 96 1. Introduction 98 As described in [RFC7228], constrained nodes are small devices with 99 limited abilities which in many cases are made to fulfill a specific 100 simple task. They may have limited hardware resources such as 101 processing power, memory, non-volatile storage and transmission 102 capacity and additionally in most cases do not have user interfaces 103 and displays. Due to these constraints, commonly used security 104 protocols are not always easily applicable, or may give rise to 105 particular deployment/management challenges. 107 As components of the Internet of Things (IoT), constrained nodes are 108 expected to be integrated in all aspects of everyday life and thus 109 will be entrusted with vast amounts of data. Without appropriate 110 security mechanisms attackers might gain control over things relevant 111 to our lives. Authentication and authorization mechanisms are 112 therefore prerequisites for a secure Internet of Things. 114 Applications generally require some degree of authentication and 115 authorization, which gives rise to some complexity. Authorization is 116 about who can do what to which objects (see also [RFC4949]). 117 Authentication specifically addresses the who, but is often specific 118 to the authorization that is required (for example, it may be 119 sufficient to authenticate the age of an actor, so no identifier is 120 needed or even desired). Authentication often involves credentials, 121 only some of which need to be long-lived and generic; others may be 122 directed towards specific authorizations (but still possibly long- 123 lived). Authorization then makes use of these credentials, as well 124 as other information (such as the time of day). This means that the 125 complexity of authenticated authorization can often be moved back and 126 forth between these two aspects. 128 In some cases authentication and authorization can be addressed by 129 static configuration provisioned during manufacturing or deployment 130 by means of fixed trust anchors and static access control lists. 131 This is particularly applicable to siloed, fixed-purpose deployments. 133 However, as the need for flexible access to assets already deployed 134 increases, the legitimate set of authorized entities as well as their 135 specific privileges cannot be conclusively defined during deployment, 136 without any need for change during the lifetime of the device. 137 Moreover, several use cases illustrate the need for fine-grained 138 access control policies, for which for instance a basic access 139 control list concept may not be sufficiently powerful [RFC7744]. 141 The limitations of the constrained nodes impose a need for security 142 mechanisms which take the special characteristics of constrained 143 environments into account; not all constituents may be able to 144 perform all necessary tasks by themselves. To put it the other way 145 round: the security mechanisms that protect constrained nodes must 146 remain effective and manageable despite the limitations imposed by 147 the constrained environment. 149 Therefore, in order to be able to achieve complex security objectives 150 between actors some of which are hosted on simple ("constrained") 151 devices, some of the actors will make use of help from other, less 152 constrained actors. (This offloading is not specific to networks 153 with constrained nodes, but their constrainedness as the main 154 motivation is.) 156 We therefore group the logical functional entities by whether they 157 can be assigned to a constrained device ("constrained level") or need 158 higher function platforms ("less-constrained level"); the latter does 159 not necessarily mean high-function, "server" or "cloud" platforms. 160 Note that assigning a logical functional entity to the constrained 161 level does not mean that the specific implementation needs to be 162 constrained, only that it _can_ be. 164 The description assumes that some form of setup (aspects of which are 165 often called provisioning and/or commissioning) has already been 166 performed and at least some initial security relationships important 167 for making the system operational have already been established. 169 This document provides some terminology, and identifies the elements 170 an architecture needs to address, representing the relationships 171 between the logical functional entities involved; on this basis, a 172 problem description for authentication and authorization in 173 constrained-node networks is provided. 175 1.1. Terminology 177 Readers are assumed to be familiar with the terms and concepts 178 defined in [RFC4949], including "authentication", "authorization", 179 "confidentiality", "(data) integrity", "message authentication code", 180 and "verify". 182 REST terms including "resource", "representation", etc. are to be 183 understood as used in HTTP [RFC7231] and CoAP [RFC7252]; the latter 184 also defines additional terms such as "endpoint". 186 Terminology for constrained environments including "constrained 187 device", "constrained-node network", "class 1", etc. is defined in 188 [RFC7228]. 190 In addition, this document uses the following terminology: 192 Resource (R): an item of interest which is represented through an 193 interface. It might contain sensor or actuator values or other 194 information. (Intended to coincide with the definitions of 195 [RFC7252] and [RFC7231].) 197 Constrained node: a constrained device in the sense of [RFC7228]. 199 Actor: A logical functional entity that performs one or more tasks. 200 Multiple actors may be present within a single device or a single 201 piece of software. 203 Resource Server (RS): An entity which hosts and represents a 204 Resource. (Used here to discuss the server that provides a 205 resource that is the end, not the means, of the authenticated 206 authorization process - i.e., not CAS or AS.) 208 Client (C): An entity which attempts to access a resource on a RS. 209 (Used to discuss the client whose access to a resource is the end, 210 not the means, of the authenticated authorization process.) 212 Overseeing principal: (Used in its English sense here, and 213 specifically as:) An individual that is either RqP or RO or both. 215 Resource Owner (RO): The overseeing principal that is in charge of 216 the resource and controls its access permissions. 218 Requesting Party (RqP): The overseeing principal that is in charge 219 of the Client and controls the requests a Client makes and its 220 acceptance of responses. 222 Authorization Server (AS): An entity that prepares and endorses 223 authentication and authorization data for a Resource Server. 225 Client Authorization Server (CAS): An entity that prepares and 226 endorses authentication and authorization data for a Client. 228 Authorization Manager: An entity that prepares and endorses 229 authentication and authorization data for a constrained node. 230 Used in constructions such as "a constrained node's authorization 231 manager" to denote AS for RS and CAS for C. 233 Authenticated Authorization: The confluence of mechanisms for 234 authentication and authorization, ensuring that authorization is 235 applied to and made available for authenticated entities and that 236 entities providing authentication services are authorized to do so 237 for the specific authorization process at hand. 239 Note that other authorization architectures such as OAuth [RFC6749] 240 or UMA [I-D.hardjono-oauth-umacore] focus on the authorization 241 problems on the RS side, in particular what accesses to resources the 242 RS is to allow. In this document the term authorization includes 243 this aspect, but is also used for the client-side aspect of 244 authorization, i.e., more generally allowing RqPs to decide what 245 interactions clients may perform with other endpoints. 247 2. Architecture and High-level Problem Statement 249 This document deals with how to control and protect resource-based 250 interaction between potentially constrained endpoints. The following 251 setting is assumed as a high-level problem statement: 253 o An endpoint may host functionality of one or more actors. 255 o C in one endpoint requests to access R on a RS in another 256 endpoint. 258 o A priori, the endpoints do not necessarily have a pre-existing 259 security relationship to each other. 261 o Either of the endpoints, or both, may be constrained. 263 2.1. Elements of an Architecture 265 In its simplest expression, the architecture starts with a two-layer 266 model: the principal level (at which components are assumed to be 267 functionally unconstrained) and the constrained level (at which some 268 functional constraints are assumed to apply to the components). 270 Without loss of generality, we focus on the C functionality in one 271 endpoint, which we therefore also call C, accessing the RS 272 functionality in another endpoint, which we therefore also call RS. 274 The constrained level and its security objectives are detailed in 275 Section 5.1. 277 -------------- -------------- 278 | ------- | | ------- | 279 | | C | ------ requests resource -----> | RS | | 280 | ------- <----- provides resource ------ ------- | 281 | Endpoint | | Endpoint | 282 -------------- -------------- 284 Figure 1: Constrained Level 286 The authorization decisions at the endpoints are made on behalf of 287 the overseeing principals that control the endpoints. To reuse OAuth 288 and UMA terminology, the present document calls the overseeing 289 principal that is controlling C the Requesting Party (RqP), and calls 290 the overseeing principal that is controlling RS the Resource Owner 291 (RO). Each overseeing principal makes authorization decisions 292 (possibly encapsulating them into security policies) which are then 293 enforced by the endpoint it controls. 295 The specific security objectives will vary, but for any specific 296 version of this scenario will include one or more of: 298 o Objectives of type 1: No entity not authorized by the RO has 299 access to (or otherwise gains knowledge of) R. 301 o Objectives of type 2: C is exchanging information with (sending a 302 request to, accepting a response from) a resource only where it 303 can ascertain that RqP has authorized the exchange with R. 305 Objectives of type 1 require performing authorization on the Resource 306 Server side while objectives of type 2 require performing 307 authorization on the Client side. 309 More on the security objectives of the principal level in 310 Section 5.2. 312 ------- ------- 313 | RqP | | RO | Principal Level 314 ------- ------- 315 | | 316 in charge of in charge of 317 | | 318 V V 319 ------- ------- 320 | C | -- requests resource --> | RS | Constrained Level 321 ------- <-- provides resource-- ------- 323 Figure 2: Constrained Level and Principal Level 325 The use cases defined in [RFC7744] demonstrate that constrained 326 devices are often used for scenarios where their overseeing 327 principals are not present at the time of the communication, are not 328 able to communicate directly with the device because of a lack of 329 user interfaces or displays, or may prefer the device to communicate 330 autonomously. 332 Moreover, constrained endpoints may need support with tasks requiring 333 heavy processing, large memory or storage, or interfacing to humans, 334 such as management of security policies defined by an overseeing 335 principal. The principal, in turn, requires some agent maintaining 336 the policies governing how its endpoints will interact. 338 For these reasons, another level of nodes is introduced in the 339 architecture, the less-constrained level (illustrated below in 340 Figure 3). Using OAuth terminology, AS acts on behalf of the RO to 341 control and support the RS in handling access requests, employing a 342 pre-existing security relationship with RS. We complement this with 343 CAS acting on behalf of RqP to control and support the C in making 344 resource requests and acting on the responses received, employing a 345 pre-existing security relationship with C. To further relieve the 346 constrained level, authorization (and related authentication) 347 mechanisms may be employed between CAS and AS (Section 6.2). (Again, 348 both CAS and AS are conceptual entities controlled by their 349 respective overseeing principals. Many of these entities, often 350 acting for different overseeing principals, can be combined into a 351 single server implementation; this of course requires proper 352 segregation of the control information provided by each overseeing 353 principal.) 355 ------- ------- 356 | RqP | | RO | Principal Level 357 ------- ------- 358 | | 359 controls controls 360 | | 361 V V 362 -------- ------- 363 | CAS | <- AuthN and AuthZ -> | AS | Less-Constrained Level 364 -------- ------- 365 | | 366 controls and supports controls and supports 367 authentication authentication 368 and authorization and authorization 369 | | 370 V V 371 ------- ------- 372 | C | -- requests resource --> | RS | Constrained Level 373 ------- <-- provides resource-- ------- 375 Figure 3: Overall architecture 377 Figure 3 shows all three levels considered in this document. Note 378 that the vertical arrows point down to illustrate exerting control 379 and providing support; this is complemented by information flows that 380 often are bidirectional. Note also that not all entities need to be 381 ready to communicate at any point in time; for instance, RqP may have 382 provided enough information to CAS that CAS can autonomously 383 negotiate access to RS with AS for C based on this information. 385 2.2. Architecture Variants 387 The elements of the architecture described above are indeed 388 architectural; that is, they are parts of a conceptual model, and may 389 be instantiated in various ways in practice. For example, in a given 390 scenario, several elements might share a single device or even be 391 combined in a single piece of software. If C is located on a more 392 powerful device, it can be combined with CAS: 394 ------- -------- 395 | RqP | | RO | Principal Level 396 ------- -------- 397 | | 398 in charge of in charge of 399 | | 400 V V 401 ------------ -------- 402 | CAS + C | <- AuthN and AuthZ -> | AS | Less-Constrained Level 403 ------------ -------- 404 ^ | 405 \__ | 406 \___ authentication 407 \___ and authorization 408 requests resource/ \___ support 409 provides resource \___ | 410 \___ | 411 V V 412 ------- 413 | RS | Constrained Level 414 ------- 416 Figure 4: Combined C and CAS 418 If RS is located on a more powerful device, it can be combined with 419 AS: 421 ------- ------- 422 | RqP | | RO | Principal Level 423 ------- ------- 424 | | 425 in charge of in charge of 426 | | 427 V V 428 ---------- ----------- 429 | CAS | <- AuthN and AuthZ -> | RS + AS | Less-Constrained Level 430 ---------- ----------- 431 | ^ 432 authentication ___/ 433 and authorization ___/ 434 support ___/ request resource / provides resource 435 | ___/ 436 V ___/ 437 ------- / 438 | C | <- 439 ------- 441 Figure 5: Combined AS and RS 443 If C and RS have the same overseeing principal, CAS and AS can be 444 combined. 446 ------------ 447 | RqP = RO | Principal Level 448 ------------ 449 | 450 in charge of 451 | 452 V 453 -------------- 454 | CAS + AS | Less-Constrained Level 455 -------------- 456 / \ 457 / \ 458 authentication authentication 459 and authorization and authorization 460 support support 461 / \ 462 V V 463 ------- ------- 464 | C | -- requests resource --> | RS | Constrained Level 465 ------- <-- provides resource -- ------- 467 Figure 6: CAS combined with AS 469 2.3. Information Flows 471 We now formulate the problem statement in terms of the information 472 flows the architecture focuses on. (While the previous section 473 discusses the architecture in terms of abstract devices and their 474 varying roles, the actual protocols being standardized define those 475 information flows and the messages embodying them: "RESTful 476 architectures focus on defining interfaces and not components" 477 ([REST], p. 116).) 479 The interaction with the nodes on the principal level, RO and RqP, is 480 not involving constrained nodes and therefore can employ an existing 481 mechanism. The less-constrained nodes, CAS and AS, support the 482 constrained nodes, C and RS, with control information, for example 483 permissions of clients, conditions on resources, attributes of client 484 and resource servers, keys and credentials. This control information 485 may be rather different for C and RS. 487 The potential information flows are shown in Figure 7. The direction 488 of the vertical arrows expresses the exertion of control; actual 489 information flow is bidirectional. 491 The message flow may pass unprotected paths and thus need to be 492 protected, potentially beyond a single REST hop (Section 3.1): 494 ------- ------- 495 | CAS | | AS | 496 ------- ------- 497 a ^ | b a = requests for control info a ^ | b 498 | | b = control information | | 499 | v | v 500 ------- ------- 501 | C | ------ request -------------------> | RS | 502 | | <----- response ------------------- | | 503 ------- ------- 505 Figure 7: Information flows that need to be protected 507 o We assume that the necessary keys/credentials for protecting the 508 control information between the potentially constrained nodes and 509 their associated less-constrained nodes are pre-established, for 510 example as part of the commissioning procedure. 512 o Any necessary keys/credentials for protecting the interaction 513 between the potentially constrained nodes will need to be 514 established and maintained as part of a solution. 516 In terms of the elements of the architecture laid out above, this 517 document's problem statement for authorization in constrained 518 environments can then be summarized as follows: 520 o The interaction between potentially constrained endpoints is 521 controlled by control information provided by less-constrained 522 nodes on behalf of the overseeing principals of the endpoints. 524 o The interaction between the endpoints needs to be secured, as well 525 as the establishment of the necessary keys for securing the 526 interaction, potentially end-to-end through intermediary nodes. 528 o The mechanism for transferring control information needs to be 529 secured, potentially end-to-end through intermediary nodes. Pre- 530 established keying material may need to be employed for 531 establishing the keys used to protect these information flows. 533 (Note that other aspects relevant to secure constrained node 534 communication such as secure bootstrap or group communication are not 535 specifically addressed by the present document.) 537 3. Security Objectives 539 The security objectives that are addressed by an authorization 540 solution include confidentiality and integrity. Additionally, an 541 authorization solution has an impact on the availability: First, by 542 reducing the load (only accepting selected operations by selected 543 entities limits the burden on system resources), and second, because 544 misconfigured or wrongly designed authorization solutions can result 545 in availability breaches (denial of service) as users might no longer 546 be able to use data and services as they are supposed to. 548 Authentication mechanisms can help achieve additional security 549 objectives such as accountability and third-party verifiability. 550 These additional objectives are not directly related to authorization 551 and thus are not in scope of this draft, but may nevertheless be 552 relevant. Accountability and third-party verifiability may require 553 authentication on a device level, if it is necessary to determine 554 which device performed an action. In other cases it may be more 555 important to find out who is responsible for the device's actions. 556 (The ensuing requirements for logging, auditability, and the related 557 integrity requirements are very relevant for constrained devices as 558 well, but outside the scope of this document.) See also Section 4 559 for more discussion about authentication and authorization. 561 The security objectives and their relative importance differ for the 562 various constrained environment applications and use cases [RFC7744]. 564 The architecture is based on the observation that different parties 565 may have different security objectives. There may also be a 566 "collaborative" dimension: to achieve a security objective of one 567 party, another party may be required to provide a service. For 568 example, if RqP requires the integrity of representations of a 569 resource R that RS is hosting, both C and RS need to partake in 570 integrity-protecting the transmitted data. Moreover, RS needs to 571 protect any write access to this resource as well as to relevant 572 other resources (such as configuration information, firmware update 573 resources) to prevent unauthorized users from manipulating R. 575 3.1. End-to-End Security Objectives in Multi-Hop Scenarios 577 In many cases, the information flows described in Section 2.3 cross 578 multiple client-server pairings but still need to be protected end- 579 to-end. For example, AS may not be connected to RS (or may not want 580 to exercise such a connection), relying on C for transferring 581 authorization information. As the authorization information is 582 related to the permissions granted to C, C must not be in a position 583 to manipulate this information, which therefore requires integrity 584 protection on the way between AS and RS. 586 As another example, resource representations sent between endpoints 587 may be stored in intermediary nodes, such as caching proxies or pub- 588 sub brokers. Where these intermediaries cannot be relied on to 589 fulfill the security objectives of the endpoints, it is the endpoints 590 that will need to protect the exchanges beyond a single client-server 591 exchange. 593 Note that there may also be cases of intermediary nodes that very 594 much partake in the security objectives to be achieved. The question 595 what are the pairs of endpoints between which the communication needs 596 end-to-end protection (and which aspect of protection) is defined by 597 the specific use case. Two examples of intermediary nodes executing 598 security functionality: 600 o To enable a trustworthy publication service, a pub-sub broker may 601 be untrusted with the plaintext content of a publication 602 (confidentiality), but required to verify that the publication is 603 performed by claimed publisher and is not a replay of an old 604 publication (authenticity/integrity). 606 o To comply with requirements of transparency, a gateway may be 607 allowed to read, verify (authenticity) but not modify (integrity) 608 a resource representation which therefore also is end-to-end 609 integrity protected from the server towards a client behind the 610 gateway. 612 In order to support the required communication and application 613 security, keying material needs to be established between the 614 relevant nodes in the architecture. 616 4. Authentication and Authorization 618 Server-side authorization solutions aim at protecting the access to 619 items of interest, for instance hardware or software resources or 620 data: They enable the resource owner to control who can access it and 621 how. 623 To determine if an entity is authorized to access a resource, an 624 authentication mechanism is needed. According to the Internet 625 Security Glossary [RFC4949], authentication is "the process of 626 verifying a claim that a system entity or system resource has a 627 certain attribute value." Examples for attribute values are the ID 628 of a device, the type of the device or the name of its owner. 630 The security objectives the authorization mechanism aims at can only 631 be achieved if the authentication and the authorization mechanism 632 work together correctly. We speak of authenticated authorization to 633 refer to the required synthesis of mechanisms for authentication and 634 authorization. 636 Where used for authorization, the set of authenticated attributes 637 must be meaningful for this purpose, i.e., authorization decisions 638 must be possible based on these attributes. If the authorization 639 policy assigns permissions to an individual entity, the set of 640 authenticated attributes must be suitable to uniquely identify this 641 entity. 643 In scenarios where devices are communicating autonomously there is 644 often less need to uniquely identify an individual device: For an 645 overseeing principal, the fact that a device belongs to a certain 646 company or that it has a specific type (such as a light bulb) or 647 location may be more important than that it has a unique identifier. 649 Overseeing principals (RqP and RO) need to decide about the required 650 level of granularity for the authorization. For example, we 651 distinguish device authorization from owner authorization, and binary 652 authorization from unrestricted authorization. In the first case 653 different access permissions are granted to individual devices while 654 in the second case individual owners are authorized. If binary 655 authorization is used, all authenticated entities are implicitly 656 authorized and have the same access permissions. Unrestricted 657 authorization for an item of interest means that no authorization 658 mechanism is used for accessing this resource (not even by 659 authentication) and all entities are able to access the item as they 660 see fit (note that an authorization mechanism may still be used to 661 arrive at the decision to employ unrestricted authorization). 663 +-----------------+-------------------------------------------------+ 664 | Authorization | Authorization is contingent on: | 665 | granularity | | 666 +-----------------+-------------------------------------------------+ 667 | device | authentication of specific device | 668 | | | 669 | owner | (authenticated) authorization by owner | 670 | | | 671 | binary | (any) authentication | 672 | | | 673 | unrestricted | (unrestricted access; access always authorized) | 674 +-----------------+-------------------------------------------------+ 676 Table 1: Some granularity levels for authorization 678 More fine-grained authorization does not necessarily provide more 679 security but can be more flexible. Overseeing principals need to 680 consider that an entity should only be granted the permissions it 681 really needs (principle of least privilege), to ensure the 682 confidentiality and integrity of resources. 684 Client-side authorization solutions aim at protecting the client from 685 disclosing information to or ingesting information from resource 686 servers RqP does not want it to interact with in the given way. 687 Again, binary authorization (the server can be authenticated) may be 688 sufficient, or more fine-grained authorization may be required. The 689 client-side authorization also pertains to the level of protection 690 required for the exchanges with the server (e.g., confidentiality). 691 In the browser web, client-side authorization is often left to the 692 human user that directly controls the client; a constrained client 693 may not have that available all the time but still needs to implement 694 the wishes of the overseeing principal controlling it, the RqP. 696 For the cases where an authorization solution is needed (all but 697 unrestricted authorization), the enforcing party needs to be able to 698 authenticate the party that is to be authorized. Authentication is 699 therefore required for messages that contain (or otherwise update) 700 representations of an accessed item. More precisely: The enforcing 701 party needs to make sure that the receiver of a message containing a 702 representation is authorized to receive it, both in the case of a 703 client sending a representation to a server and vice versa. In 704 addition, it needs to ensure that the actual sender of a message 705 containing a representation is indeed the one authorized to send this 706 message, again for both the client-to-server and server-to-client 707 case. To achieve this, integrity protection of these messages is 708 required: Authenticity of the message cannot be assured if it is 709 possible for an attacker to modify it during transmission. 711 In some cases, only one side (client or server side) requires the 712 integrity and / or confidentiality of a resource value. Overseeing 713 principals may decide to omit authentication (unrestricted 714 authorization), or use binary authorization (just employing an 715 authentication mechanism). However, as indicated in Section 3, the 716 security objectives of both sides must be considered, which can often 717 only be achieved when the other side can be relied on to perform some 718 security service. 720 5. Actors and their Tasks 722 This and the following section look at the resulting architecture 723 from two different perspectives: This section provides a more 724 detailed description of the various "actors" in the architecture, the 725 logical functional entities performing the tasks required. The 726 following section then will focus on the protocols run between these 727 functional entities. 729 For the purposes of this document, an actor consists of a set of 730 tasks and additionally has a security domain (client domain or server 731 domain) and a level (constrained, principal, less-constrained). 732 Tasks are assigned to actors according to their security domain and 733 required level. 735 Note that actors are a concept to understand the security 736 requirements for constrained devices. The architecture of an actual 737 solution might differ as long as the security requirements that 738 derive from the relationship between the identified actors are 739 considered. Several actors might share a single device or even be 740 combined in a single piece of software. Interfaces between actors 741 may be realized as protocols or be internal to such a piece of 742 software. 744 5.1. Constrained Level Actors 746 As described in the problem statement (see Section 2), either C or RS 747 or both of them may be located on a constrained node. We therefore 748 define that C and RS must be able to perform their tasks even if they 749 are located on a constrained node. Thus, C and RS are considered to 750 be Constrained Level Actors. 752 C performs the following tasks: 754 o Communicate in a secure way (provide for confidentiality and 755 integrity of messages), including access requests. 757 o Validate that the RqP ("client-side") authorization information 758 allows C to communicate with RS as a server for R (i.e., from C's 759 point of view, RS is authorized as a server for the specific 760 access to R). 762 RS performs the following tasks: 764 o Communicate in a secure way (provide for confidentiality and 765 integrity of messages), including responses to access requests. 767 o Validate that the RO ("server-side") authorization information 768 allows RS to grant C access to the requested resource as requested 769 (i.e., from RS' point of view, C is authorized as a client for the 770 specific access to R). 772 R is an item of interest such as a sensor or actuator value. R is 773 considered to be part of RS and not a separate actor. The device on 774 which RS is located might contain several resources controlled by 775 different ROs. For simplicity of exposition, these resources are 776 described as if they had separate RS. 778 As C and RS do not necessarily know each other they might belong to 779 different security domains. 781 (See Figure 8.) 783 ------- -------- 784 | C | -- requests resource ---> | RS | Constrained Level 785 ------- <-- provides resource--- -------- 787 Figure 8: Constrained Level Actors 789 5.2. Principal Level Actors 791 Our objective is that C and RS are under control of overseeing 792 principals in the physical world, the Requesting Party (RqP) and the 793 Resource Owner (RO) respectively. The overseeing principals decide 794 about the security policies of their respective endpoints; each 795 overseeing principal belongs to the same security domain as their 796 endpoints. 798 RqP is in charge of C, i.e. RqP specifies security policies for C, 799 such as with whom C is allowed to communicate. By definition, C and 800 RqP belong to the same security domain. 802 RqP must fulfill the following task: 804 o Configure for C authorization information for sources for R. 806 RO is in charge of R and RS. RO specifies authorization policies for 807 R and decides with whom RS is allowed to communicate. By definition, 808 R, RS and RO belong to the same security domain. 810 RO must fulfill the following task: 812 o Configure for RS authorization information for accessing R. 814 (See Figure 2.) 816 5.3. Less-Constrained Level Actors 818 Constrained level actors can only fulfill a limited number of tasks 819 and may not have network connectivity all the time. To relieve them 820 from having to manage keys for numerous endpoints and conducting 821 computationally intensive tasks, another level of complexity for 822 actors is introduced (and, thus, a stricter limit on their 823 constrainedness). An actor on the less-constrained level belongs to 824 the same security domain as its respective constrained level actor. 825 They also have the same overseeing principal. 827 The Client Authorization Server (CAS) belongs to the same security 828 domain as C and RqP. CAS acts on behalf of RqP. It assists C in 829 authenticating RS and determining if RS is an authorized server for 830 R. CAS can do that because for C, CAS is the authority for claims 831 about RS. 833 CAS performs the following tasks: 835 o Vouch for the attributes of its clients. 837 o Ascertain that C's overseeing principal (RqP) authorized AS to 838 vouch for RS and provide keying material for it. 840 o Provide revocation information concerning its clients (optional). 842 o Obtain authorization information about RS from C's overseeing 843 principal (RqP) and provide it to C. 845 o Negotiate means for secure communication to communicate with C. 847 The Authorization Server (AS) belongs to the same security domain as 848 R, RS and RO. AS acts on behalf of RO. It supports RS by 849 authenticating C and determining C's permissions on R. AS can do 850 that because for RS, AS is the authority for claims about C. 852 AS performs the following tasks: 854 o Vouch for the attributes of its resource servers. 856 o Ascertain that RS's overseeing principal (RO) authorized CAS to 857 vouch for C and provide keying material for it. 859 o Provide revocation information concerning its servers (optional). 861 o Obtain authorization information about C from RS' overseeing 862 principal (RO) and provide it to RS. 864 o Negotiate means for secure communication to communicate with RS. 866 6. Kinds of Protocols 868 Devices on the less-constrained level potentially are more powerful 869 than constrained level devices in terms of processing power, memory, 870 non-volatile storage. This results in different characteristics for 871 the protocols used on these levels. 873 6.1. Constrained Level Protocols 875 A protocol is considered to be on the constrained level if it is used 876 between the actors C and RS which are considered to be constrained 877 (see Section 5.1). C and RS might not belong to the same security 878 domain. Therefore, constrained level protocols need to work between 879 different security domains. 881 Commonly used Internet protocols can not in every case be applied to 882 constrained environments. In some cases, tweaking and profiling is 883 required. In other cases it is beneficial to define new protocols 884 which were designed with the special characteristics of constrained 885 environments in mind. 887 On the constrained level, protocols need to address the specific 888 requirements of constrained environments. Examples for protocols 889 that consider these requirements is the transfer protocol CoAP 890 (Constrained Application Protocol) [RFC7252] and the Datagram 891 Transport Layer Security Protocol (DTLS) [RFC6347] which can be used 892 for channel security. 894 Constrained devices have only limited storage space and thus cannot 895 store large numbers of keys. This is especially important because 896 constrained networks are expected to consist of thousands of nodes. 897 Protocols on the constrained level should keep this limitation in 898 mind. 900 6.1.1. Cross Level Support Protocols 902 We refer to protocols that operate between a constrained device and 903 its corresponding less-constrained device as cross-level support 904 protocols. Protocols used between C and CAS or RS and AS are 905 therefore support protocols. 907 Support protocols must consider the limitations of their constrained 908 endpoint and therefore belong to the constrained level protocols. 910 6.2. Less-Constrained Level Protocols 912 A protocol is considered to be on the less-constrained level if it is 913 used between the actors CAS and AS. CAS and AS might belong to 914 different security domains. 916 On the less-constrained level, HTTP [RFC7230] and Transport Layer 917 Security (TLS) [RFC8246] can be used alongside or instead of CoAP and 918 DTLS. Moreover, existing security solutions for authentication and 919 authorization such as the OAuth web authorization framework [RFC6749] 920 and Kerberos [RFC4120] can likely be used without modifications and 921 the less-constrained layer is assumed to impose no constraints that 922 would inhibit the traditional deployment/use of, e.g., a Public Key 923 Infrastructure (PKI). 925 7. Elements of a Solution 927 Without anticipating specific solutions, the following considerations 928 may be helpful in discussing them. 930 7.1. Authorization 932 The core problem we are trying to solve is authorization. The 933 following problems related to authorization need to be addressed: 935 o AS needs to transfer authorization information to RS and CAS needs 936 to transfer authorization information to C. 938 o The transferred authorization information needs to follow a 939 defined format and encoding, which must be efficient for 940 constrained devices, considering size of authorization information 941 and parser complexity. 943 o C and RS need to be able to verify the authenticity of the 944 authorization information they receive. C must ascertain that the 945 authorization information stems from a CAS that was authorized by 946 RqP, RS must validate that the authorization information stems 947 from an AS that was authorized by RO. 949 o Some applications may require the confidentiality of authorization 950 information. It then needs to be encrypted between CAS and C and 951 AS and RS, respectively. 953 o C and RS must be able to check the freshness of the authorization 954 information and determine for how long it is supposed to be valid. 956 o The RS needs to enforce the authorization decisions of the AS, 957 while C needs to abide with the authorization decisions of the 958 CAS. The authorization information might require additional 959 policy evaluation (such as matching against local access control 960 lists, evaluating local conditions). The required "policy 961 evaluation" at the constrained actors needs to be adapted to the 962 capabilities of the devices implementing them. 964 o Finally, as is indicated in the previous bullet, for a particular 965 authorization decision there may be different kinds of 966 authorization information needed, and these pieces of information 967 may be transferred to C and RS at different times and in different 968 ways prior to or during the client request. 970 7.2. Authentication 972 The following problems need to be addressed, when considering 973 authentication: 975 o RS needs to authenticate AS in the sense that it must be certain 976 that it communicates with an AS that was authorized by RO, C needs 977 to authenticate CAS in the sense that it must be certain that it 978 communicates with a CAS that was authorized by RqP, to ensure that 979 the authorization information and related data comes from the 980 correct source. 982 o C must securely have obtained keying material to communicate with 983 its CAS that is up to date and that is updated if necessary. RS 984 must securely have obtained keying material to communicate with AS 985 that is up to date and that is updated if necessary. 987 o CAS and AS may need to authenticate each other, both to perform 988 the required business logic and to ensure that CAS gets security 989 information related to the resources from the right source. 991 o In some use cases RS needs to authenticate some property of C, in 992 order to map it to the relevant authorization information. 994 o C may need to authenticate RS, in order to ensure that it is 995 interacting with the right resources. 997 o CAS and AS need to authenticate their communication partner (C or 998 RS), in order to ensure it serves the correct device. If C and AS 999 vouch for keying material or certain attributes of their 1000 respective constrained devices, they must ascertain that the 1001 devices actually currently have this keying material or these 1002 attributes. 1004 7.3. Communication Security 1006 There are different alternatives to provide communication security, 1007 and the problem here is to choose the optimal one for each scenario. 1008 We list the available alternatives: 1010 o Session-based security at transport layer such as DTLS [RFC6347] 1011 offers security, including integrity and confidentiality 1012 protection, for the whole application layer exchange. However, 1013 DTLS may not provide end-to-end security over multiple hops. 1014 Another problem with DTLS is the cost of the handshake protocol, 1015 which may be too expensive for constrained devices especially in 1016 terms of memory and power consumption for message transmissions. 1018 o An alternative is object security at application layer, for 1019 instance using [I-D.ietf-core-object-security]. Secure objects 1020 can be stored or cached in network nodes and provide security for 1021 a more flexible communication model such as publish/subscribe 1022 (compare e.g. CoRE Mirror Server [I-D.ietf-core-coap-pubsub]). A 1023 problem with object security is that it can not provide 1024 confidentiality for the message headers. 1026 o Hybrid solutions using both session-based and object security are 1027 also possible. An example of a hybrid is where authorization 1028 information and cryptographic keys are provided by AS in the 1029 format of secure data objects, but where the resource access is 1030 protected by session-based security. 1032 7.4. Cryptographic Keys 1034 With respect to cryptographic keys, we see the following problems 1035 that need to be addressed: 1037 Symmetric vs Asymmetric Keys 1038 We need keys both for protection of resource access and for 1039 protection of transport of authentication and authorization 1040 information. It may be necessary to support solutions that 1041 require the use of asymmetric keys as well as ones that get by 1042 with symmetric keys, in both cases. There are classes of devices 1043 that can easily perform symmetric cryptography, but consume 1044 considerably more time/battery for asymmetric operations. On the 1045 other hand asymmetric cryptography has benefits such as in terms 1046 of deployment. 1048 Key Establishment 1049 How are the corresponding cryptographic keys established? 1050 Considering Section 7.1 there must be a mapping between these keys 1051 and the authorization information, at least in the sense that AS 1052 must be able to specify a unique client identifier which RS can 1053 verify (using an associated key). One of the use cases of 1054 [RFC7744] describes spontaneous change of access policies - such 1055 as giving a hitherto unknown client the right to temporarily 1056 unlock your house door. In this case C is not previously known to 1057 RS and a key must be provisioned by AS. 1059 Revocation and Expiration 1060 How are keys replaced and how is a key that has been compromised 1061 revoked in a manner that reaches all affected parties, also 1062 keeping in mind scenarios with intermittent connectivity? 1064 8. Assumptions and Requirements 1066 In this section we list a set of candidate assumptions and 1067 requirements to make the problem description in the previous sections 1068 more concise and precise. Note that many of these assumptions and 1069 requirements are targeting specific solutions and not the 1070 architecture itself. 1072 8.1. Constrained Devices 1074 o C and/or RS may be constrained in terms of power, processing, 1075 communication bandwidth, memory and storage space, and moreover: 1077 * unable to manage complex authorization policies 1079 * unable to manage a large number of secure connections 1081 * without user interface 1083 * without constant network connectivity 1085 * unable to precisely measure time 1087 * required to save on wireless communication due to high power 1088 consumption 1090 o CAS and AS are not assumed to be constrained devices. 1092 o All devices under consideration can process symmetric cryptography 1093 without incurring an excessive performance penalty. 1095 o Public key cryptography requires additional resources (such as 1096 RAM, ROM, power, specialized hardware). 1098 o A solution will need to consider support for a simple scheme for 1099 expiring authentication and authorization information on devices 1100 which are unable to measure time (cf. Section 9.2). 1102 8.2. Server-side Authorization 1104 o RS enforces authorization for access to a resource based on 1105 credentials presented by C, the requested resource, the REST 1106 method, and local context in RS at the time of the request, or on 1107 any subset of this information. 1109 o The authorization decision is enforced by RS. 1111 * RS needs to have authorization information in order to verify 1112 that C is allowed to access the resource as requested. 1114 * RS needs to make sure that it provides resource access only to 1115 authorized clients. 1117 o Apart from authorization for access to a resource, authorization 1118 may also be required for access to information about a resource 1119 (for instance, resource descriptions). 1121 8.3. Client-side Authorization Information 1123 o C enforces client-side authorization by protecting its requests to 1124 RS and by authenticating results from RS, making use of decisions 1125 and policies as well as keying material provided by CAS. 1127 8.4. Resource Access 1129 o Resources are accessed in a RESTful manner using methods such as 1130 GET, PUT, POST, DELETE. 1132 o By default, the resource request needs to be integrity protected 1133 and may be encrypted end-to-end from C to RS. It needs to be 1134 possible for RS to detect a replayed request. 1136 o By default, the response to a request needs to be integrity 1137 protected and may be encrypted end-to-end from RS to C. It needs 1138 to be possible for C to detect a replayed response. 1140 o RS needs to be able to verify that the request comes from an 1141 authorized client. 1143 o C needs to be able to verify that the response to a request comes 1144 from the intended RS. 1146 o There may be resources whose access need not be protected (e.g. 1147 for discovery of the responsible AS). 1149 8.5. Keys and Cipher Suites 1151 o A constrained node and its authorization manager (i.e., RS and AS, 1152 and C and CAS) have established cryptographic keys. For example, 1153 they share a secret key or each have the other's public key. 1155 o The transfer of authorization information is protected with 1156 symmetric and/or asymmetric keys. 1158 o The access request/response is protected with symmetric and/or 1159 asymmetric keys. 1161 o There must be a mechanism for RS to establish the necessary key(s) 1162 to verify and decrypt the request and to protect the response. 1164 o There must be a mechanism for C to establish the necessary key(s) 1165 to protect the request and to verify and decrypt the response. 1167 o There must be a mechanism for C to obtain the supported cipher 1168 suites of a RS. 1170 8.6. Network Considerations 1172 o A solution will need to consider network overload due to avoidable 1173 communication of a constrained node with its authorization manager 1174 (C with CAS, RS with AS). 1176 o A solution will need to consider network overload by compact 1177 authorization information representation. 1179 o A solution may want to optimize the case where authorization 1180 information does not change often. 1182 o A solution should combine the mechanisms for providing 1183 authentication and authorization information to the client and RS 1184 where possible. 1186 o A solution may consider support for an efficient mechanism for 1187 providing authorization information to multiple RSs, for example 1188 when multiple entities need to be configured or change state. 1190 9. Security Considerations 1192 This document discusses authorization-related tasks for constrained 1193 environments and describes how these tasks can be mapped to actors in 1194 the architecture. 1196 In this section we focus on specific security aspects related to 1197 authorization in constrained-node networks. Section 11.6 of 1198 [RFC7252], "Constrained node considerations", discusses implications 1199 of specific constraints on the security mechanisms employed. A wider 1200 view of security in constrained-node networks is provided in 1201 [I-D.irtf-t2trg-iot-seccons]. 1203 9.1. Physical Attacks on Sensor and Actuator Networks 1205 The focus of this work is on constrained-node networks consisting of 1206 connected constrained devices such as sensors and actuators. The 1207 main function of such devices is to interact with the physical world 1208 by gathering information or performing an action. We now discuss 1209 attacks performed with physical access to such devices. 1211 The main threats to sensors and actuator networks are: 1213 o Unauthorized access to data to and from sensors and actuators, 1214 including eavesdropping and manipulation of data. 1216 o Denial-of-service making the sensor/actuator unable to perform its 1217 intended task correctly. 1219 A number of attacks can be made with physical access to a device 1220 including probing attacks, timing attacks, power attacks, etc. 1221 However, with physical access to a sensor or actuator device it is 1222 possible to directly perform attacks equivalent of eavesdropping, 1223 manipulating data or denial of service. These attacks are 1224 possible by having physical access to the device, since the assets 1225 are related to the physical world. Moreover, this kind of attacks 1226 are in many cases straightforward (requires no special competence 1227 or tools, low cost given physical access, etc). If an attacker 1228 has full physical access to a sensor or actuator device, then much 1229 of the security functionality elaborated in this draft may not be 1230 effective to protect the asset during the physical attack. 1232 9.2. Clocks and Time Measurements 1234 Measuring time and keeping wall-clock time with certain accuracy is 1235 important to achieve certain security properties, for example to 1236 determine whether keying material an access token, or some other 1237 assertion, is valid. The required level of accuracy may differ for 1238 different applications. 1240 Dynamic authorization in itself requires the ability to handle expiry 1241 or revocation of authorization decisions or to distinguish new 1242 authorization decisions from old. 1244 For certain categories of devices we can assume that there is an 1245 internal clock which is sufficiently accurate to handle the time 1246 measurement requirements. If RS continuously measures time and can 1247 connect directly to AS, this relationship can be used to update RS in 1248 terms of time, removing some uncertainty, as well as to directly 1249 provide revocation information, removing authorizations that are no 1250 longer desired. 1252 If RS continuously measures time but can't connect to AS or another 1253 trusted source of time, time drift may have to be accepted and it may 1254 be harder to manage revocation. However, RS may still be able to 1255 handle short lived access rights within some margins, by measuring 1256 the time since arrival of authorization information or request. 1258 Some categories of devices in scope may be unable to measure time 1259 with any accuracy (e.g. because of sleep cycles). This category of 1260 devices is not suitable for the use cases which require measuring 1261 validity of assertions and authorizations in terms of absolute time 1262 such as TLS certificates but require a mechanism that is specifically 1263 designed for them. 1265 10. IANA Considerations 1267 This document has no actions for IANA. 1269 11. Informative References 1271 [HUM14delegation] 1272 Hummen, R., Shafagh, H., Raza, S., Voigt, T., and K. 1273 Wehrle, "Delegation-based Authentication and Authorization 1274 for the IP-based Internet of Things", 11th IEEE 1275 International Conference on Sensing, Communication, and 1276 Networking (SECON'14), June 30 - July 3, 2014. 1278 [I-D.hardjono-oauth-umacore] 1279 Hardjono, T., Maler, E., Machulak, M., and D. Catalano, 1280 "User-Managed Access (UMA) Profile of OAuth 2.0", draft- 1281 hardjono-oauth-umacore-14 (work in progress), January 1282 2016. 1284 [I-D.ietf-core-coap-pubsub] 1285 Koster, M., Keranen, A., and J. Jimenez, "Publish- 1286 Subscribe Broker for the Constrained Application Protocol 1287 (CoAP)", draft-ietf-core-coap-pubsub-05 (work in 1288 progress), July 2018. 1290 [I-D.ietf-core-object-security] 1291 Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 1292 "Object Security for Constrained RESTful Environments 1293 (OSCORE)", draft-ietf-core-object-security-15 (work in 1294 progress), August 2018. 1296 [I-D.irtf-t2trg-iot-seccons] 1297 Garcia-Morchon, O., Kumar, S., and M. Sethi, "State-of- 1298 the-Art and Challenges for the Internet of Things 1299 Security", draft-irtf-t2trg-iot-seccons-15 (work in 1300 progress), May 2018. 1302 [REST] Fielding, R. and R. Taylor, "Principled design of the 1303 modern Web architecture", ACM Trans. Inter. Tech. Vol. 1304 2(2), pp. 115-150, DOI 10.1145/514183.514185, May 2002. 1306 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The 1307 Kerberos Network Authentication Service (V5)", RFC 4120, 1308 DOI 10.17487/RFC4120, July 2005, 1309 . 1311 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", 1312 FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, 1313 . 1315 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1316 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 1317 January 2012, . 1319 [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", 1320 RFC 6749, DOI 10.17487/RFC6749, October 2012, 1321 . 1323 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 1324 Constrained-Node Networks", RFC 7228, 1325 DOI 10.17487/RFC7228, May 2014, 1326 . 1328 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 1329 Protocol (HTTP/1.1): Message Syntax and Routing", 1330 RFC 7230, DOI 10.17487/RFC7230, June 2014, 1331 . 1333 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 1334 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 1335 DOI 10.17487/RFC7231, June 2014, 1336 . 1338 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 1339 Application Protocol (CoAP)", RFC 7252, 1340 DOI 10.17487/RFC7252, June 2014, 1341 . 1343 [RFC7744] Seitz, L., Ed., Gerdes, S., Ed., Selander, G., Mani, M., 1344 and S. Kumar, "Use Cases for Authentication and 1345 Authorization in Constrained Environments", RFC 7744, 1346 DOI 10.17487/RFC7744, January 2016, 1347 . 1349 [RFC8246] McManus, P., "HTTP Immutable Responses", RFC 8246, 1350 DOI 10.17487/RFC8246, September 2017, 1351 . 1353 Acknowledgements 1355 The authors would like to thank Olaf Bergmann, Robert Cragie, Samuel 1356 Erdtman, Klaus Hartke, Sandeep Kumar, John Mattson, Corinna Schmitt, 1357 Mohit Sethi, Abhinav Somaraju, Hannes Tschofenig, Vlasios Tsiatsis 1358 and Erik Wahlstroem for contributing to the discussion, giving 1359 helpful input and commenting on previous forms of this draft. The 1360 authors would also like to specifically acknowledge input provided by 1361 Hummen and others [HUM14delegation]. Robin Wilton provided extensive 1362 editorial comments that were the basis for significant improvements 1363 of the text. 1365 Authors' Addresses 1367 Stefanie Gerdes 1368 Universitaet Bremen TZI 1369 Postfach 330440 1370 Bremen D-28359 1371 Germany 1373 Phone: +49-421-218-63906 1374 Email: gerdes@tzi.org 1376 Ludwig Seitz 1377 RISE SICS 1378 Scheelevaegen 17 1379 Lund 223 70 1380 Sweden 1382 Email: ludwig.seitz@ri.se 1384 Goeran Selander 1385 Ericsson AB 1387 Email: goran.selander@ericsson.com 1388 Carsten Bormann (editor) 1389 Universitaet Bremen TZI 1390 Postfach 330440 1391 Bremen D-28359 1392 Germany 1394 Phone: +49-421-218-63921 1395 Email: cabo@tzi.org