idnits 2.17.1 draft-gerdes-ace-actors-05.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 (April 29, 2015) is 3285 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-03 == Outdated reference: A later version (-05) exists of draft-koster-core-coap-pubsub-01 == Outdated reference: A later version (-06) exists of draft-selander-ace-object-security-01 -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 6347 (Obsoleted by RFC 9147) -- Obsolete informational reference (is this intentional?): RFC 7230 (Obsoleted by RFC 9110, RFC 9112) -- Obsolete informational reference (is this intentional?): RFC 7231 (Obsoleted by RFC 9110) Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ACE Working Group S. Gerdes 3 Internet-Draft Universitaet Bremen TZI 4 Intended status: Informational L. Seitz 5 Expires: October 31, 2015 SICS Swedish ICT AB 6 G. Selander 7 Ericsson 8 C. Bormann, Ed. 9 Universitaet Bremen TZI 10 April 29, 2015 12 An architecture for authorization in constrained environments 13 draft-gerdes-ace-actors-05 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 elements of an architecture / 22 a problem statement, for authentication and authorization in these 23 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 October 31, 2015. 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 . . . . . . . . . . . . . . . . . . 7 64 2.3. Information flows . . . . . . . . . . . . . . . . . . . . 10 65 2.4. Problem statement . . . . . . . . . . . . . . . . . . . . 11 66 3. Security Objectives . . . . . . . . . . . . . . . . . . . . . 11 67 3.1. End-to-End Security Objectives . . . . . . . . . . . . . 12 68 4. Authentication and Authorization . . . . . . . . . . . . . . 12 69 5. Actors and their Tasks . . . . . . . . . . . . . . . . . . . 14 70 5.1. Constrained Level Actors . . . . . . . . . . . . . . . . 15 71 5.2. Principal Level Actors . . . . . . . . . . . . . . . . . 16 72 5.3. Less-Constrained Level Actors . . . . . . . . . . . . . . 16 73 6. Kinds of Protocols . . . . . . . . . . . . . . . . . . . . . 17 74 6.1. Constrained Level Protocols . . . . . . . . . . . . . . . 17 75 6.1.1. Cross Level Support Protocols . . . . . . . . . . . . 18 76 6.2. Less-Constrained Level Protocols . . . . . . . . . . . . 18 77 7. Elements of a Solution . . . . . . . . . . . . . . . . . . . 18 78 7.1. Authorization . . . . . . . . . . . . . . . . . . . . . . 18 79 7.2. Authentication . . . . . . . . . . . . . . . . . . . . . 19 80 7.3. Communication Security . . . . . . . . . . . . . . . . . 19 81 7.4. Cryptographic Keys . . . . . . . . . . . . . . . . . . . 20 82 8. Assumptions and Requirements . . . . . . . . . . . . . . . . 21 83 8.1. Architecture . . . . . . . . . . . . . . . . . . . . . . 21 84 8.2. Constrained Devices . . . . . . . . . . . . . . . . . . . 21 85 8.3. Authentication . . . . . . . . . . . . . . . . . . . . . 22 86 8.4. Server-side Authorization . . . . . . . . . . . . . . . . 23 87 8.5. Client-side Authorization Information . . . . . . . . . . 23 88 8.6. Server-side Authorization Information . . . . . . . . . . 23 89 8.7. Resource Access . . . . . . . . . . . . . . . . . . . . . 24 90 8.8. Keys and Cipher Suites . . . . . . . . . . . . . . . . . 24 91 8.9. Network Considerations . . . . . . . . . . . . . . . . . 25 92 8.10. Legacy Considerations . . . . . . . . . . . . . . . . . . 25 93 9. Security Considerations . . . . . . . . . . . . . . . . . . . 25 94 9.1. Physical Attacks on Sensor and Actuator Networks . . . . 26 95 9.2. Time Measurements . . . . . . . . . . . . . . . . . . . . 27 96 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 97 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28 98 12. Informative References . . . . . . . . . . . . . . . . . . . 28 99 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 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 In some cases authentication and authorization can be addressed by 119 static configuration provisioned during manufacturing or deployment 120 by means of fixed trust anchors and access control lists. This is 121 particularly applicable to siloed, fixed-purpose deployments. 122 However, as the need for flexible access to assets already deployed 123 increases, the legitimate set of authorized entities as well as their 124 privileges cannot be conclusively defined during deployment, without 125 any need for change during the lifetime of the device. Moreover, 126 several use cases illustrate the need for fine-grained access control 127 policies, for which the access control lists concept may not be 128 sufficiently generic. 130 The limitations of the constrained nodes ask for security mechanisms 131 which take the special characteristics of constrained environments 132 into account; not all constituents may be able to perform all 133 necessary tasks by themselves. In order to meet the security 134 requirements in constrained scenarios, the necessary tasks need to be 135 assigned to logical functional entities. 137 This document provides some terminology, as well as elements of an 138 architecture to represent the relationships between the logical 139 functional entities involved; on this basis, a problem description 140 for authentication and authorization in constrained-node networks is 141 provided. 143 1.1. Terminology 145 Readers are required to be familiar with the terms and concepts 146 defined in [RFC4949], including "authentication", "authorization", 147 "confidentiality", "(data) integrity", "message authentication code", 148 and "verify". 150 REST terms including "resource", "representation", etc. are to be 151 understood as used in HTTP [RFC7231] and CoAP [RFC7252]. 153 Terminology for constrained environments including "constrained 154 device", "constrained-node network", "class 1", etc. are defined in 155 [RFC7228]. 157 In addition, this document uses the following terminology: 159 Resource (R): an item of interest which is represented through an 160 interface. It might contain sensor or actuator values or other 161 information. 163 Constrained node: a constrained device in the sense of [RFC7228]. 165 Actor: A logical functional entity that performs one or more tasks. 166 Multiple actors may be present within a single device or a single 167 piece of software. 169 Resource Server (RS): An entity which hosts and represents a 170 Resource. 172 Client (C): An entity which attempts to access a resource on an RS. 174 Principal: (Used in its English sense here, and specifically as:) An 175 individual that is either RqP or RO or both. 177 Resource Owner (RO): The principal that is in charge of the resource 178 and controls its access permissions. 180 Requesting Party (RqP): The principal that is in charge of the 181 Client and controls the requests a Client makes and its acceptance 182 of responses. 184 Authorization Server (AS): An entity that prepares and endorses 185 authentication and authorization data for a Resource Server. 187 Client Authorization Server (CAS): An entity that prepares and 188 endorses authentication and authorization data for a Client. 190 Authenticated Authorization: A synthesis of mechanisms for 191 authentication and authorization. 193 Note that other authorization architectures such as OAuth [RFC6749] 194 or UMA [I-D.hardjono-oauth-umacore] focus on the authorization 195 problems on the RS side, in particular what accesses to resources the 196 RS is to allow. In this document the term authorization includes 197 this aspect, but is also used for client-side authorization, i.e., 198 more generally to describe allowed interactions with other endpoints. 200 2. Architecture and High-level Problem Statement 202 2.1. Elements of an Architecture 204 This document deals with how to control and protect resource-based 205 interaction between potentially constrained endpoints. The following 206 setting is assumed: 208 o An endpoint may host functionality of C, RS or both C and RS. 210 o C in one endpoint requests to access R on a RS in another 211 endpoint. 213 o A priori, the endpoints do not necessarily have a pre-existing 214 security relationship to each other. 216 o Either of the endpoints, or both, may be constrained. 218 Without loss of generality, we focus on the C functionality in one 219 endpoint, which we therefore also call C, accessing the RS 220 functionality in another endpoint, which we therefore also call RS. 222 More on the security objectives of the constrained level in 223 Section 5.1. 225 -------------- -------------- 226 | ------- | | ------- | 227 | | C | ------ requests resource -----> | RS | | 228 | ------- <----- provides resource ------ ------- | 229 | Endpoint | | Endpoint | 230 -------------- -------------- 232 Figure 1: Constrained Level 234 The authorization decisions at the endpoints are made on behalf of 235 the principals that control the endpoints. To reuse OAuth and UMA 236 terminology, the present document calls C's controlling principal the 237 Requesting Party (RqP), and calls RS's controlling principal the 238 Resource Owner (RO). Each principal makes authorization decisions 239 (possibly encapsulating them into security policies) which the 240 endpoint it controls then enforces. 242 The specific security objectives will vary, but for any specific 243 version of this scenario will include one or more of: 245 o Objectives of type 1: No entity not authorized by the RO has 246 access to (or otherwise gains knowledge of) R. 248 o Objectives of type 2: C is exchanging information with (sending a 249 request to, accepting a response from) a resource only where it 250 can ascertain that RqP has authorized the exchange with R. 252 Objectives of type 1 require performing authorization on the Resource 253 Server side while objectives of type 2 require performing 254 authorization on the Client side. 256 More on the security objectives of the principal level in 257 Section 5.2. 259 ------- ------- 260 | RqP | | RO | Principal Level 261 ------- ------- 262 | | 263 in charge of in charge of 264 | | 265 V V 266 ------- ------- 267 | C | -- requests resource --> | RS | Constrained Level 268 ------- <-- provides resource-- ------- 270 Figure 2: Constrained Level and Principal Level 272 The use cases defined in [I-D.ietf-ace-usecases] demonstrate that 273 constrained devices are often used for scenarios where their 274 principals are not present at the time of the communication, are not 275 able to communicate directly with the device because of a lack of 276 user interfaces or displays, or may prefer the device to communicate 277 autonomously. 279 Moreover, constrained endpoints may need support with tasks requiring 280 heavy processing, large memory or storage, or interfacing to humans, 281 such as management of security policies defined by a principal. The 282 principal, in turn, requires some agent maintaining the policies 283 governing how its endpoints will interact. 285 For these reasons, another level of nodes is introduced in the 286 architecture, the less-constrained level. Using OAuth terminology, 287 AS acts on behalf of the RO to control and support the RS in handling 288 access requests, employing a pre-existing security relationship with 289 RS. We complement this with CAS acting on behalf of RqP to control 290 and support the C in making resource requests and acting on the 291 responses received, employing a pre-existing security relationship 292 with C. To further relieve the constrained level, authorization (and 293 related authentication) mechanisms may be employed between CAS and AS 294 (Section 6.2). (Again, both CAS and AS are conceptual entities 295 controlled by their respective principals. Many of these entities, 296 often acting for different principals, can be combined into a single 297 server implementation; this of course requires proper segregration of 298 the control information provided by each principal.) 300 ------- ------- 301 | RqP | | RO | Principal Level 302 ------- ------- 303 | | 304 controls controls 305 | | 306 V V 307 -------- ------- 308 | CAS | <- AuthN and AuthZ -> | AS | Less-Constrained Level 309 -------- ------- 310 | | 311 controls and supports controls and supports 312 authentication authentication 313 and authorization and authorization 314 | | 315 V V 316 ------- ------- 317 | C | -- requests resource --> | RS | Constrained Level 318 ------- <-- provides resource-- ------- 320 Figure 3: Overall architecture 322 2.2. Architecture Variants 324 The elements of the architecture described above are architectural. 325 In a specific scenario, several elements can share a single device or 326 even be combined in a single piece of software. If C is located on a 327 more powerful device, it can be combined with CAS: 329 ------- -------- 330 | RqP | | RO | Principal Level 331 ------- -------- 332 | | 333 in charge of in charge of 334 | | 335 V V 336 ------------ -------- 337 | CAS + C | <- AuthN and AuthZ -> | AS | Less-Constrained Level 338 ------------ -------- 339 ^ | 340 \__ | 341 \___ authentication 342 \___ and authorization 343 requests resource/ \___ support 344 provides resource \___ | 345 \___ | 346 V V 347 ------- 348 | RS | Constrained Level 349 ------- 351 Figure 4: Combined C and CAS 353 If RS is located on a more powerful device, it can be combined with 354 AS: 356 ------- ------- 357 | RqP | | RO | Principal Level 358 ------- ------- 359 | | 360 in charge of in charge of 361 | | 362 V V 363 ---------- ----------- 364 | CAS | <- AuthN and AuthZ -> | RS + AS | Less-Constrained Level 365 ---------- ----------- 366 | ^ 367 authentication ___/ 368 and authorization ___/ 369 support ___/ request resource / provides resource 370 | ___/ 371 V ___/ 372 ------- / 373 | C | <- 374 ------- 376 Figure 5: Combined AS and RS 378 If C and RS have the same principal, CAS and AS can be combined. 380 ------------ 381 | RqP = RO | Principal Level 382 ------------ 383 | 384 in charge of 385 | 386 V 387 -------------- 388 | CAS + AS | Less-Constrained Level 389 -------------- 390 / \ 391 / \ 392 authentication authentication 393 and authorization and authorization 394 support support 395 / \ 396 V V 397 ------- ------- 398 | C | -- requests resource --> | RS | Constrained Level 399 ------- <-- provides resource -- ------- 401 Figure 6: CAS combined with AS 403 2.3. Information flows 405 In this subsection, we complement the abstracted architecture 406 described above with a discussion of the information flows in scope, 407 mentioning that each endpoint may assume both a client and a server 408 role and that communication may be via intermediaries. 410 The less-constrained nodes, CAS and AS, control the interactions 411 between the endpoints by supporting the potentially constrained nodes 412 with control information, for example permissions of clients, 413 conditions on resources, attributes of client and resource servers, 414 keys and credentials. The control information may be rather 415 different for C and RS, reflecting the intrinsic asymmetry with C 416 initiating the request for access to a resource, and RS acting on a 417 received request, and C finally acting on the received response. 419 The information flows are shown in Figure 7. The arrows with control 420 information only indicate origin and destination of information, 421 actual message flow may pass intermediary nodes (both nodes that are 422 identified in the architecture and other nodes). 424 ------- ------ ------- ------ 425 | CAS | | AS | | CAS | | AS | 426 ------- ------ ------- ------ 427 | | | | 428 | | | | 429 | | control | | control 430 | | information | | information 431 | | | | 432 ------------------- ------------------- 433 | | | | | | | | 434 | v | | | | v 435 | ------- ---------- request -----------> ------- | 436 | | C1 | <---------- response ------------ | RS2 | | 437 | ------- | | | | ------- | 438 | v | | v | 439 | ------- | | ------- | 440 | | RS1 | <---- request ----- | C2 | | 441 | ------- ----- response ---> ------- | 442 | | | | 443 | Endpoint 1 | | Endpoint 2 | 444 ------------------- ------------------- 446 Figure 7: Information flows that need to be protected 448 o We assume that the necessary keys/credentials for protecting the 449 control information between the potentially constrained nodes and 450 their associated less-constrained nodes are pre-established, for 451 example as part of the commissioning procedure. 453 o The messages between the endpoints also need to be protected, 454 potentially end-to-end through intermediary nodes (Section 3.1). 455 Any necessary keys/credentials for protecting the interaction 456 between the endpoints will need to be established and maintained 457 as part of a solution. 459 2.4. Problem statement 461 The problem statement for authorization in constrained environments 462 can be summarized as follows: 464 o The interaction between potentially constrained endpoints is 465 controlled by control information provided by less-constrained 466 nodes on behalf of the principals of the endpoints. 468 o The interaction between the endpoints needs to be secured, as well 469 as the establishment of the necessary keys for securing the 470 interaction, potentially end-to-end through intermediary nodes. 472 o The mechanism for transferring control information needs to be 473 secured, potentially end-to-end through intermediary nodes. Pre- 474 established keying material may need to be employed for 475 establishing the keys used to protect these information flows. 477 3. Security Objectives 479 The security objectives that are addressed by an authorization 480 solution include confidentiality and integrity. Additionally, 481 allowing only selected entities limits the burden on system 482 resources, thus helping to achieve availability. Misconfigured or 483 wrongly designed authorization solutions can result in availability 484 breaches: Users might no longer be able to use data and services as 485 they are supposed to. 487 Authentication mechanisms can achieve additional security objectives 488 such as non-repudiation and accountability. These additional 489 objectives are not related to authorization and thus are not in scope 490 of this draft, but may nevertheless be relevant. Non-repudiation and 491 accountability may require authentication on a device level, if it is 492 necessary to determine which device performed an action. In other 493 cases it may be more important to find out who is responsible for the 494 device's actions. 496 The security objectives and their relative importance differ for the 497 various constrained environment applications and use cases 498 [I-D.ietf-ace-usecases]. 500 In many cases, one participating party has different security 501 objectives than another. To achieve a security objective of one 502 party, another party may be required to provide a service. E.g., if 503 RqP requires the integrity of representations of a resource R that RS 504 is hosting, both C and RS need to partake in integrity-protecting the 505 transmitted data. Moreover, RS needs to protect any write access to 506 this resource as well as to relevant other resources (such as 507 configuration information, firmware update resources) to prevent 508 unauthorized users from manipulating R. 510 3.1. End-to-End Security Objectives 512 In many cases, the information flows described in Section 2.3 need to 513 be protected end-to-end. For example, AS may not be connected to RS 514 (or may not want to exercise such a connection), relying on C for 515 transferring authorization information. As the authorization 516 information is related to the permissions granted to C, C must not be 517 in a position to manipulate this information, which therefore 518 requires integrity protection on the way between AS and RS. 520 As another example, resource representations sent between endpoints 521 may be stored in intermediary nodes, such as caching proxies or pub- 522 sub brokers. Where these intermediaries cannot be relied on to 523 fulfill the security objectives of the endpoints, these will need to 524 protect the exchanges end-to-end. 526 Note that there may also be cases of intermediary nodes that very 527 much partake in the security objectives to be achieved. What is the 528 endpoint to which communication needs end-to-end protection is 529 defined by the use case. 531 In order to support the required communication and application 532 security, keying material needs to be established between the 533 relevant nodes in the architecture. 535 4. Authentication and Authorization 537 Server-side authorization solutions aim at protecting the access to 538 items of interest, e.g. hardware or software resources or data: They 539 enable the resource owner to control who can access it and how. 541 To determine if an entity is authorized to access a resource, an 542 authentication mechanism is needed. According to the Internet 543 Security Glossary [RFC4949], authentication is "the process of 544 verifying a claim that a system entity or system resource has a 545 certain attribute value." Examples for attribute values are the ID 546 of a device, the type of the device or the name of its owner. 548 The security objectives the authorization mechanism aims at can only 549 be achieved if the authentication and the authorization mechanism 550 work together correctly. We speak of authenticated authorization to 551 refer to the required synthesis of mechanism for authentication and 552 authorization. 554 Where used for authorization, the set of authenticated attributes 555 must be meaningful for this purpose, i.e., authorization decisions 556 must be possible based on these attributes. If the authorization 557 policy assigns permissions to an individual entity, the set of 558 authenticated attributes must be suitable to uniquely identify this 559 entity. 561 In scenarios where devices are communicating autonomously there is 562 often less need to uniquely identify an individual device: For a 563 principal, the fact that a device belongs to a certain company or 564 that it has a specific type (e.g. light bulb) or location may be more 565 important than that it has a unique identifier. 567 (As a special case for the authorization of read access to a 568 resource, RS may simply make an encrypted representation available to 569 anyone [OSCAR]. In this case, controlling read access to that 570 resource can be reduced to controlling read access to the key; 571 partially removing access also requires a timely update of the key 572 for RS and all participants still authorized.) 574 Principals (RqP and RO) need to decide about the required level of 575 granularity for the authorization. For example, we distinguish 576 device authorization from owner authorization, and flat authorization 577 from unrestricted authorization. In the first case different access 578 permissions are granted to individual devices while in the second 579 case individual owners are authorized. If flat authorization is 580 used, all authenticated entities are implicitly authorized and have 581 the same access permissions. Unrestricted authorization for an item 582 of interest means that no authorization mechanism is used for 583 accessing this resource (not even by authentication) and all entities 584 are able to access the item as they see fit (note that an 585 authorization mechanism may still be used to arrive at the decision 586 to employ unrestricted authorization). 588 More fine-grained authorization does not necessarily provide more 589 security but can be more flexible. Principals need to consider that 590 an entity should only be granted the permissions it really needs 591 (principle of least privilege), to ensure the confidentiality and 592 integrity of resources. 594 For all cases where an authorization solution is needed (all but 595 Unrestricted Authorization), the enforcing party needs to be able to 596 authenticate the party that is to be authorized. Authentication is 597 therefore required for messages that contain (or otherwise update) 598 representations of an accessed item. More precisely: The enforcing 599 party needs to make sure that the receiver of a message containing a 600 representation is authorized to receive it, both in the case of a 601 client sending a representation to a server and vice versa. In 602 addition, it needs to ensure that the actual sender of a message 603 containing a representation is indeed the one authorized to send this 604 message, again for both the client-to-server and server-to-client 605 case. To achieve this, integrity protection of these messages is 606 required: Authenticity cannot be assured if it is possible for an 607 attacker to modify the message during transmission. 609 In some cases, only one side (client or server side) requires the 610 integrity and / or confidentiality of a resource value. Principals 611 may decide to omit authentication (unrestricted authorization), or 612 use flat authorization (just employing an authentication mechanism). 613 However, as indicated in Section 3, the security objectives of both 614 sides must be considered, which can often only be achieved when the 615 the other side can be relied on to perform some security service. 617 5. Actors and their Tasks 619 This and the following section look at the resulting architecture 620 from two different perspectives: This section provides a more 621 detailed description of the various "actors" in the architecture, the 622 logical functional entities performing the tasks required. The 623 following section then will focus on the protocols run between these 624 functional entities. 626 For the purposes of this document, an actor consists of a set of 627 tasks and additionally has a security domain (client domain or server 628 domain) and a level (constrained, principal, less-constrained). 629 Tasks are assigned to actors according to their security domain and 630 required level. 632 Note that actors are a concept to understand the security 633 requirements for constrained devices. The architecture of an actual 634 solution might differ as long as the security requirements that 635 derive from the relationship between the identified actors are 636 considered. Several actors might share a single device or even be 637 combined in a single piece of software. Interfaces between actors 638 may be realized as protocols or be internal to such a piece of 639 software. 641 5.1. Constrained Level Actors 643 As described in the problem statement (see Section 2), either C or RS 644 or both of them may be located on a constrained node. We therefore 645 define that C and RS must be able to perform their tasks even if they 646 are located on a constrained node. Thus, C and RS are considered to 647 be Constrained Level Actors. 649 C performs the following tasks: 651 o Communicate in a secure way (provide for confidentiality and 652 integrity of messages), including access requests. 654 o Validate that an entity is an authorized server for R. 656 RS performs the following tasks: 658 o Communicate in a secure way (provide for confidentiality and 659 integrity of messages), including responses to access requests. 661 o Validate the authorization of the requester to access the 662 requested resource as requested. 664 R is an item of interest such as a sensor or actuator value. R is 665 considered to be part of RS and not a separate actor. The device on 666 which RS is located might contain several resources of different ROs. 667 For simplicity of exposition, these resources are described as if 668 they had separate RS. 670 As C and RS do not necessarily know each other they might belong to 671 different security domains. 673 (See Figure 8.) 675 ------- -------- 676 | C | -- requests resource ---> | RS | Constrained Level 677 ------- <-- provides resource--- -------- 679 Figure 8: Constrained Level Actors 681 5.2. Principal Level Actors 683 Our objective is that C and RS are under control of principals in the 684 physical world, the Requesting Party (RqP) and the Resource Owner 685 (RO) respectively. The principals decide about the security policies 686 of their respective endpoints and belong to the same security domain. 688 RqP is in charge of C, i.e. RqP specifies security policies for C, 689 e.g. with whom C is allowed to communicate. By definition, C and RqP 690 belong to the same security domain. 692 RqP must fulfill the following task: 694 o Configure for C authorization information for sources for R. 696 RO is in charge of R and RS. RO specifies authorization policies for 697 R and decides with whom RS is allowed to communicate. By definition, 698 R, RS and RO belong to the same security domain. 700 RO must fulfill the following task: 702 o Configure for RS authorization information for accessing R. 704 (See Figure 2.) 706 5.3. Less-Constrained Level Actors 708 Constrained level actors can only fulfill a limited number of tasks 709 and may not have network connectivity all the time. To relieve them 710 from having to manage keys for numerous endpoints and conducting 711 computationally intensive tasks, another complexity level for actors 712 is introduced. An actor on the less-constrained level belongs to the 713 same security domain as its respective constrained level actor. They 714 also have the same principal. 716 The Client Authorization Server (CAS) belongs to the same security 717 domain as C and RqP. CAS acts on behalf of RqP. It assists C in 718 authenticating RS and determining if RS is an authorized server for 719 R. CAS can do that because for C, CAS is the authority for claims 720 about RS. 722 CAS performs the following tasks: 724 o Validate on the client side that an entity has certain attributes. 726 o Obtain authorization information about an entity from C's 727 principal (RqP) and provide it to C. 729 o Negotiate means for secure communication to communicate with C. 731 The Authorization Server (AS) belongs to the same security domain as 732 R, RS and RO. AS acts on behalf of RO. It supports RS by 733 authenticating C and determining C's permissions on R. AS can do 734 that because for RS, AS is the authority for claims about C. 736 AS performs the following tasks: 738 o Validate on the server side that an entity has certain attributes. 740 o Obtain authorization information about an entity from RS' 741 principal (RO) and provide it to RS. 743 o Negotiate means for secure communication to communicate with RS. 745 6. Kinds of Protocols 747 Devices on the less-constrained level potentially are more powerful 748 than constrained level devices in terms of processing power, memory, 749 non-volatile storage. This results in different characteristics for 750 the protocols used on these levels. 752 6.1. Constrained Level Protocols 754 A protocol is considered to be on the constrained level if it is used 755 between the actors C and RS which are considered to be constrained 756 (see Section 5.1). C and RS might not belong to the same security 757 domain. Therefore, constrained level protocols need to work between 758 different security domains. 760 Commonly used Internet protocols can not in every case be applied to 761 constrained environments. In some cases, tweaking and profiling is 762 required. In other cases it is beneficial to define new protocols 763 which were designed with the special characteristics of constrained 764 environments in mind. 766 On the constrained level, protocols need to address the specific 767 requirements of constrained environments. Examples for protocols 768 that consider these requirements is the transfer protocol CoAP 769 (Constrained Application Protocol) [RFC7252] and the Datagram 770 Transport Layer Security Protocol (DTLS) [RFC6347] which can be used 771 for channel security. 773 Constrained devices have only limited storage space and thus cannot 774 store large numbers of keys. This is especially important because 775 constrained networks are expected to consist of thousands of nodes. 777 Protocols on the constrained level should keep this limitation in 778 mind. 780 6.1.1. Cross Level Support Protocols 782 Protocols which operate between a constrained device on one side and 783 the corresponding less-constrained device on the other are considered 784 to be (cross level) support protocols. Protocols used between C and 785 CAS or RS and AS are therefore support protocols. 787 Support protocols must consider the limitations of their constrained 788 endpoint and therefore belong to the constrained level protocols. 790 6.2. Less-Constrained Level Protocols 792 A protocol is considered to be on the less-constrained level if it is 793 used between the actors CAS and AS. CAS and AS might belong to 794 different security domains. 796 On the less-constrained level, HTTP [RFC7230] and Transport Layer 797 Security (TLS) [RFC5246] can be used alongside or instead of CoAP and 798 DTLS. Moreover, existing security solutions for authentication and 799 authorization such as the OAuth web authorization framework [RFC6749] 800 and Kerberos [RFC4120] can likely be used without modifications and 801 there are no limitations for the use of a Public Key Infrastructure 802 (PKI). 804 7. Elements of a Solution 806 Without anticipating specific solutions, the following considerations 807 may be helpful in discussing them. 809 7.1. Authorization 811 The core problem we are trying to solve is authorization. The 812 following problems related to authorization need to be addressed: 814 o AS needs to transfer authorization information to RS and CAS needs 815 to transfer authorization information to C. 817 o The transferred authorization information needs to follow a 818 defined format and encoding, which must be efficient for 819 constrained devices, considering size of authorization information 820 and parser complexity. 822 o C and RS need to be able to verify the authenticity of the 823 authorization information they receive. Here as well, there is a 824 trade-off between processing complexity and deployment complexity. 826 o The RS needs to enforce the authorization decisions of the AS, 827 while C needs to abide with the authorization decisions of the 828 CAS. The authorization information might require additional 829 policy evaluation (e.g. matching against local access control 830 lists, evaluating local conditions). The required "policy 831 evaluation" at the constrained actors needs to be adapted to the 832 capabilities of the devices implementing them. 834 o Finally, as is indicated in the previous bullet, for a particular 835 authorization decision there may be different kinds of 836 authorization information needed, and these pieces of information 837 may be transferred to C and RS at different times and in different 838 ways prior to or during the client request. 840 7.2. Authentication 842 The following problems need to be addressed, when considering 843 authentication: 845 o RS needs to authenticate AS, and C needs to authenticate CAS, to 846 ensure that the authorization information and related data comes 847 from the correct source. 849 o CAS and AS may need to to authenticate each other, both to perform 850 the required business logic and to ensure that CAS gets security 851 information related to the resources from the right source. 853 o In some use cases RS needs to authenticate some property of C, in 854 order to map it to the relevant authorization information. In 855 other use cases, authentication and authorization of C may be 856 implicit, e.g. by encrypting the resource representation the RS 857 only providing access to those who possess the key to decrypt. 859 o C may need to authenticate RS, in order to ensure that it is 860 interacting with the right resources. Alternatively C may just 861 verify the integrity of a received resource representation. 863 o CAS and AS need to authenticate their communication partner (C or 864 RS), in order to ensure it serves the correct device. 866 7.3. Communication Security 868 There are different alternatives to provide communication security, 869 and the problem here is to choose the optimal one for each scenario. 870 We list the available alternatives: 872 o Session-based security at transport layer such as DTLS [RFC6347] 873 offers security, including integrity and confidentiality 874 protection, for the whole application layer exchange. However, 875 DTLS may not provide end-to-end security over multiple hops. 876 Another problem with DTLS is the cost of the handshake protocol, 877 which may be too expensive for constrained devices especially in 878 terms of memory and power consumption for message transmissions. 880 o An alternative is object security at application layer, e.g. 881 using [I-D.selander-ace-object-security] Secure objects can be 882 stored or cached in network nodes and provide security for a more 883 flexible communication model such as publish/subscribe (compare 884 e.g. CoRE Mirror Server [I-D.koster-core-coap-pubsub]). A 885 problem with object security is that it can not provide 886 confidentiality for the message headers. 888 o Hybrid solutions using both session-based and object security are 889 also possible. An example of a hybrid is where authorization 890 information and cryptographic keys are provided by AS in the 891 format of secure data objects, but where the resource access is 892 protected by session-based security. 894 7.4. Cryptographic Keys 896 With respect to cryptographic keys, we see the following problems 897 that need to be addressed: 899 Symmetric vs Asymmetric Keys 900 We need keys both for protection of resource access and for 901 protection of transport of authentication and authorization 902 information. Do we want to support solutions based on asymmetric 903 keys or symmetric keys in both cases? There are classes of 904 devices that can easily perform symmetric cryptography, but 905 consume considerably more time/battery for asymmetric operations. 906 On the other hand asymmetric cryptography has benefits e.g. in 907 terms of deployment. 909 Key Establishment 910 How are the corresponding cryptographic keys established? 911 Considering Section 7.1 there must be a mapping between these keys 912 and the authorization information, at least in the sense that AS 913 must be able to specify a unique client identifier which RS can 914 verify (using an associated key). One of the use cases of 915 [I-D.ietf-ace-usecases] describes spontaneous change of access 916 policies - e.g. giving a hitherto unknown client the right to 917 temporarily unlock your house door. In this case C is not 918 previously known to RS and a key must be provisioned by AS. 920 Revocation and Expiration 921 How are keys replaced and how is a key that has been compromised 922 revoked in a manner that reaches all affected parties, also 923 keeping in mind scenarios with intermittent connectivity? 925 8. Assumptions and Requirements 927 In this section we list a set of candidate assumptions and 928 requirements to make the problem description in the previous sections 929 more concise and precise. 931 8.1. Architecture 933 The architecture consists of at least the following types of nodes: 935 o RS hosting resources, and responding to access requests 937 o C requesting access to resources 939 o AS supporting the access request/response procedure by providing 940 authorization information to RS 942 * AS may support this by aiding RS in authenticating C, or 943 providing cryptographic keys or credentials to C and/or RS to 944 secure the request/response procedure. 946 o CAS supporting the access request/response procedure by providing 947 authorization information to C 949 * CAS may support this by aiding C in authenticating RS, 950 forwarding information between AS and C (possibly ultimately 951 for RS), or providing cryptographic keys or credentials to C 952 and/or RS to secure the request/response procedure. 954 o The architecture allows for intermediary nodes between any pair of 955 C, RS, AS, and CAS, such as forward or reverse proxies in the CoRE 956 architecture. (Solutions may or may not support all 957 combinations.) 959 * The architecture does not make a choice between session based 960 security and data object security. 962 8.2. Constrained Devices 964 o C and/or RS may be constrained in terms of power, processing, 965 communication bandwidth, memory and storage space, and moreover: 967 * unable to manage complex authorization policies 968 * unable to manage a large number of secure connections 970 * without user interface 972 * without constant network connectivity 974 * unable to precisely measure time 976 * required to save on wireless communication due to high power 977 consumption 979 o CAS and AS are not assumed to be constrained devices. 981 o All devices under consideration can process symmetric cryptography 982 without incurring an excessive performance penalty. 984 * We assume the use of a standardized symmetric key algorithm, 985 such as AES. 987 * Except for the most constrained devices we assume the use of a 988 standardized cryptographic hash function such as SHA-256. 990 o Public key cryptography requires additional resources (e.g. RAM, 991 ROM, power, specialized hardware). 993 o A DTLS handshake involves significant computation, communication, 994 and memory overheads in the context of constrained devices. 996 * The RAM requirements of DTLS handshakes with public key 997 cryptography are prohibitive for certain constrained devices. 999 * Certificate-based DTLS handshakes require significant volumes 1000 of communication, RAM (message buffers) and computation. 1002 o A solution will need to consider support for a simple scheme for 1003 expiring authentication and authorization information on devices 1004 which are unable to measure time (cf. section Section 9.2). 1006 8.3. Authentication 1008 o RS needs to authenticate AS to ensure that the authorization 1009 information and related data comes from the correct source. 1011 o Similary, C needs to authenticate CAS to ensure that the 1012 authorization information and related data comes from the correct 1013 source. 1015 o Depending on use case and authorization requirements, C, RS, CAS, 1016 or AS may need to authenticate messages from each other. 1018 8.4. Server-side Authorization 1020 o RS enforces authorization for access to a resource based on 1021 credentials presented by C, the requested resource, the REST 1022 method, and local context in RS at the time of the request, or on 1023 any subset of this information. 1025 o The credentials presented by C may have been provided by CAS. 1027 o The underlying authorization decision is taken either by AS or RS. 1029 o The authorization decision is enforced by RS. 1031 * RS needs to have authorization information in order to verify 1032 that C is allowed to access the resource as requested. 1034 * RS needs to make sure that it provides resource access only to 1035 authorized clients. 1037 o Apart from authorization for access to a resource, authorization 1038 may also be required for access to information about a resource 1039 (e.g. resource descriptions). 1041 o The solution may need to be able to support the delegation of 1042 access rights. 1044 8.5. Client-side Authorization Information 1046 o C enforces client-side authorization by protecting its requests to 1047 RS and by authenticating results from RS, making use of decisions 1048 and policies as well as keying material provided by CAS. 1050 8.6. Server-side Authorization Information 1052 o Authorization information is transferred from AS to RS using 1053 Agent, Push or Pull mechanisms [RFC2904]. 1055 o RS needs to authenticate that the authorization information is 1056 coming from AS (integrity). 1058 o The authorization information may also be encrypted end-to-end 1059 between AS and RS (confidentiality). 1061 o The architecture supports the case where RS may not be able to 1062 communicate with AS at the time of the request from C. 1064 o RS may store or cache authorization information. 1066 o Authorization information may be pre-configured in RS. 1068 o Authorization information stored or cached in RS needs to be 1069 possible to change. The change of such information needs to be 1070 subject to authorization. 1072 o Authorization policies stored on RS may be handled as a resource, 1073 i.e. information located at a particular URI, accessed with 1074 RESTful methods, and the access being subject to the same 1075 authorization mechanics. AS may have special privileges when 1076 requesting access to the authorization policy resources on RS. 1078 o There may be mechanisms for C to look up the AS which provides 1079 authorization information about a particular resource. 1081 8.7. Resource Access 1083 o Resources are accessed in a RESTful manner using GET, PUT, POST, 1084 DELETE. 1086 o By default, the resource request needs to be integrity protected 1087 and may be encrypted end-to-end from C to RS. It needs to be 1088 possible for RS to detect a replayed request. 1090 o By default, the response to a request needs to be integrity 1091 protected and encrypted end-to-end from RS to C. It needs to be 1092 possible for C to detect a replayed response. 1094 o RS needs to be able to verify that the request comes from an 1095 authorized client 1097 o C needs to be able to verify that the response to a request comes 1098 from the intended RS. 1100 o There may be resources whose access need not be protected (e.g. 1101 for discovery of the responsible AS). 1103 8.8. Keys and Cipher Suites 1105 o A constrained node and its authorization manager (i.e., RS and AS, 1106 and C and CAS) have established cryptographic keys. For example, 1107 they share a secret key or each have the other's public key. 1109 o The transfer of authorization information is protected with 1110 symmetric and/or asymmetric keys. 1112 o The access request/response can be protected with symmetric and/or 1113 asymmetric keys. 1115 o There must be a mechanism for RS to establish the necessary key(s) 1116 to verify and decrypt the request and to protect the response. 1118 o There must be a mechanism for C to establish the necessary key(s) 1119 to protect the request and to verify and decrypt the response. 1121 o There must be a mechanism for C to obtain the supported cipher 1122 suites of a RS. 1124 8.9. Network Considerations 1126 o A solution will need to consider network overload due to avoidable 1127 communication of a constrained node with its authorization manager 1128 (C with CAS, RS with AS). 1130 o A solution will need to consider network overload by compact 1131 authorization information representation. 1133 o A solution may want to optimize the case where authorization 1134 information does not change often. 1136 o A solution may consider support for an efficient mechanism for 1137 providing authorization information to multiple RSs, for example 1138 when multiple entities need to be configured or change state. 1140 8.10. Legacy Considerations 1142 o A solution may consider interworking with existing infrastructure. 1144 o A solution may consider supporting authorization of access to 1145 legacy devices. 1147 9. Security Considerations 1149 This document discusses authorization-related tasks for constrained 1150 environments and describes how these tasks can be mapped to actors in 1151 the architecture. 1153 The entire document is about security. Security considerations 1154 applicable to authentication and authorization in RESTful 1155 environments are provided in e.g. OAuth 2.0 [RFC6749]. 1157 In this section we focus on specific security aspects related to 1158 authorization in constrained-node networks. Section 11.6 of 1159 [RFC7252], "Constrained node considerations", discusses implications 1160 of specific constraints on the security mechanisms employed. A wider 1161 view of security in constrained-node networks is provided in 1162 [I-D.garcia-core-security]. 1164 9.1. Physical Attacks on Sensor and Actuator Networks 1166 The focus of this work is on constrained-node networks consisting of 1167 connected sensors and actuators. The main function of such devices 1168 is to interact with the physical world by gathering information or 1169 performing an action. We now discuss attacks performed with physical 1170 access to such devices. 1172 The main threats to sensors and actuator networks are: 1174 o Unauthorized access to data to and from sensors and actuators, 1175 including eavesdropping and manipulation of data. 1177 o Denial-of-service making the sensor/actuator unable to perform its 1178 intended task correctly. 1180 A number of attacks can be made with physical access to a device 1181 including probing attacks, timing attacks, power attacks, etc. 1182 However, with physical access to a sensor or actuator device it is 1183 possible to directly perform attacks equivalent of eavesdropping, 1184 manipulating data or denial of service. For example: 1186 o Instead of eavesdropping the sensor data or attacking the 1187 authorization system to gain access to the data, the attacker 1188 could make its own measurements on the physical object. 1190 o Instead of manipulating the sensor data the attacker could change 1191 the physical object which the sensor is measuring, thereby 1192 changing the payload data which is being sent. 1194 o Instead of manipulating data for an actuator or attacking the 1195 authorization system, the attacker could perform an unauthorized 1196 action directly on the physical object. 1198 o A denial-of-service attack could be performed physically on the 1199 object or device. 1201 All these attacks are possible by having physical access to the 1202 device, since the assets are related to the physical world. 1203 Moreover, this kind of attacks are in many cases straightforward 1204 (requires no special competence or tools, low cost given physical 1205 access, etc.) 1206 As a conclusion, if an attacker has full physical access to a 1207 sensor or actuator device, then much of the security functionality 1208 elaborated in this draft is not effective to protect the asset 1209 during the physical attack. 1211 Since it does not make sense to design a solution for a situation 1212 that cannot be protected against we assume there is no need to 1213 protect assets which are exposed during a physical attack. In 1214 other words, either an attacker does not have physical access to 1215 the sensor or actuator device, or if it has, the attack shall only 1216 have effect during the period of physical attack, and shall be 1217 limited in extent to the physical control the attacker exerts 1218 (e.g., must not affect the security of other devices.) 1220 9.2. Time Measurements 1222 Measuring time with certain accuracy is important to achieve certain 1223 security properties, for example to determine whether a public key 1224 certificate, access token or some other assertion is valid. 1226 Dynamic authorization in itself requires the ability to handle expiry 1227 or revocation of authorization decisions or to distinguish new 1228 authorization decisions from old. 1230 For certain categories of devices we can assume that there is an 1231 internal clock which is sufficiently accurate to handle the time 1232 measurement requirements. If RS can connect directly to AS it could 1233 get updated in terms of time as well as revocation information. 1235 If RS continuously measures time but can't connect to AS or other 1236 trusted source, time drift may have to be accepted and it may not be 1237 able to manage revocation. However, it may still be able to handle 1238 short lived access rights within some margins, by measuring the time 1239 since arrival of authorization information or request. 1241 Some categories of devices in scope may be unable measure time with 1242 any accuracy (e.g. because of sleep cycles). This category of 1243 devices is not suitable for the use cases which require measuring 1244 validity of assertions and authorizations in terms of absolute time. 1246 10. IANA Considerations 1248 This document has no actions for IANA. 1250 11. Acknowledgements 1252 The authors would like to thank Olaf Bergmann, Robert Cragie, Klaus 1253 Hartke, Sandeep Kumar, John Mattson, Corinna Schmitt, Mohit Sethi, 1254 Hannes Tschofenig, Vlasios Tsiatsis and Erik Wahlstroem for 1255 contributing to the discussion, giving helpful input and commenting 1256 on previous forms of this draft. The authors would also like to 1257 specifically acknowledge input provided by Hummen and others 1258 [HUM14delegation]. 1260 12. Informative References 1262 [HUM14delegation] 1263 Hummen, R., Shafagh, H., Raza, S., Voigt, T., and K. 1264 Wehrle, "Delegation-based Authentication and Authorization 1265 for the IP-based Internet of Things", 11th IEEE 1266 International Conference on Sensing, Communication, and 1267 Networking (SECON'14), June 30 - July 3, 2014. 1269 [I-D.garcia-core-security] 1270 Garcia-Morchon, O., Kumar, S., Keoh, S., Hummen, R., and 1271 R. Struik, "Security Considerations in the IP-based 1272 Internet of Things", draft-garcia-core-security-06 (work 1273 in progress), September 2013. 1275 [I-D.hardjono-oauth-umacore] 1276 Hardjono, T., Maler, E., Machulak, M., and D. Catalano, 1277 "User-Managed Access (UMA) Profile of OAuth 2.0", draft- 1278 hardjono-oauth-umacore-13 (work in progress), April 2015. 1280 [I-D.ietf-ace-usecases] 1281 Seitz, L., Gerdes, S., Selander, G., Mani, M., and S. 1282 Kumar, "ACE use cases", draft-ietf-ace-usecases-03 (work 1283 in progress), March 2015. 1285 [I-D.koster-core-coap-pubsub] 1286 Koster, M., Keranen, A., and J. Jimenez, "Publish- 1287 Subscribe Broker for the Constrained Application Protocol 1288 (CoAP)", draft-koster-core-coap-pubsub-01 (work in 1289 progress), March 2015. 1291 [I-D.selander-ace-object-security] 1292 Selander, G., Mattsson, J., and L. Seitz, "March 9, 2015", 1293 draft-selander-ace-object-security-01 (work in progress), 1294 March 2015. 1296 [OSCAR] Vucinic, M., Tourancheau, B., Rousseau, F., Duda, A., 1297 Damon, L., and R. Guizzetti, "OSCAR: Object Security 1298 Architecture for the Internet of Things", CoRR vol. 1299 abs/1404.7799, 2014. 1301 [RFC2904] Vollbrecht, J., Calhoun, P., Farrell, S., Gommans, L., 1302 Gross, G., de Bruijn, B., de Laat, C., Holdrege, M., and 1303 D. Spence, "AAA Authorization Framework", RFC 2904, August 1304 2000. 1306 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The 1307 Kerberos Network Authentication Service (V5)", RFC 4120, 1308 July 2005. 1310 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", RFC 1311 4949, August 2007. 1313 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1314 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 1316 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1317 Security Version 1.2", RFC 6347, January 2012. 1319 [RFC6749] Hardt, D., "The OAuth 2.0 Authorization Framework", RFC 1320 6749, October 2012. 1322 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 1323 Constrained-Node Networks", RFC 7228, May 2014. 1325 [RFC7230] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol 1326 (HTTP/1.1): Message Syntax and Routing", RFC 7230, June 1327 2014. 1329 [RFC7231] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol 1330 (HTTP/1.1): Semantics and Content", RFC 7231, June 2014. 1332 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 1333 Application Protocol (CoAP)", RFC 7252, June 2014. 1335 Authors' Addresses 1336 Stefanie Gerdes 1337 Universitaet Bremen TZI 1338 Postfach 330440 1339 Bremen D-28359 1340 Germany 1342 Phone: +49-421-218-63906 1343 Email: gerdes@tzi.org 1345 Ludwig Seitz 1346 SICS Swedish ICT AB 1347 Scheelevaegen 17 1348 Lund 223 70 1349 Sweden 1351 Email: ludwig@sics.se 1353 Goeran Selander 1354 Ericsson 1355 Faroegatan 6 1356 Kista 164 80 1357 Sweden 1359 Email: goran.selander@ericsson.com 1361 Carsten Bormann (editor) 1362 Universitaet Bremen TZI 1363 Postfach 330440 1364 Bremen D-28359 1365 Germany 1367 Phone: +49-421-218-63921 1368 Email: cabo@tzi.org