idnits 2.17.00 (12 Aug 2021) /tmp/idnits51481/draft-seitz-ace-core-authz-00.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 (June 29, 2015) is 2511 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'ChangeCipherSpec' is mentioned on line 631, but not defined == Outdated reference: A later version (-01) exists of draft-schaad-cose-msg-00 == Outdated reference: A later version (-06) exists of draft-selander-ace-object-security-01 ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) == Outdated reference: A later version (-09) exists of draft-bormann-core-ace-aif-02 == Outdated reference: A later version (-04) exists of draft-gerdes-ace-dcaf-authorize-02 == Outdated reference: draft-ietf-ace-usecases has been published as RFC 7744 -- Obsolete informational reference (is this intentional?): RFC 7049 (Obsoleted by RFC 8949) -- Obsolete informational reference (is this intentional?): RFC 7159 (Obsoleted by RFC 8259) Summary: 1 error (**), 0 flaws (~~), 7 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ACE Working Group L. Seitz 3 Internet-Draft SICS 4 Intended status: Standards Track G. Selander 5 Expires: December 31, 2015 Ericsson 6 M. Vucinic 7 STMicroelectronics 8 June 29, 2015 10 Authorization for Constrained RESTful Environments 11 draft-seitz-ace-core-authz-00 13 Abstract 15 This memo defines a framework for authorization in constrained-node 16 networks, i.e. networks where some devices have severe constraints on 17 memory, processing, power and communication bandwidth. The main goal 18 is to offload constrained devices by providing them access control 19 support from trusted parties that are less constrained. The approach 20 is based on RESTful requests to dedicated access management 21 resources, supporting different authorization schemes and 22 communication security paradigms. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on December 31, 2015. 41 Copyright Notice 43 Copyright (c) 2015 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 59 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 2.1. Example A: Access to an Actuator . . . . . . . . . . . . 4 62 2.2. Example B: Multiple Devices Accessing Sensor Data . . . . 5 63 2.3. The Authentication and Authorization Problem . . . . . . 5 64 2.4. Solution Overview . . . . . . . . . . . . . . . . . . . . 6 65 3. Information Flows . . . . . . . . . . . . . . . . . . . . . . 7 66 3.1. Message Sequences . . . . . . . . . . . . . . . . . . . . 7 67 3.2. Access Management Resources . . . . . . . . . . . . . . . 9 68 4. Communication Security . . . . . . . . . . . . . . . . . . . 11 69 4.1. AS - RS . . . . . . . . . . . . . . . . . . . . . . . . . 12 70 4.2. AS - C . . . . . . . . . . . . . . . . . . . . . . . . . 13 71 4.3. C - RS . . . . . . . . . . . . . . . . . . . . . . . . . 13 72 4.4. Authorization Information transfer in the DTLS Handshake 13 73 5. Authorization Request Format . . . . . . . . . . . . . . . . 15 74 5.1. ARF Information Model . . . . . . . . . . . . . . . . . . 15 75 5.2. ARF Data Model . . . . . . . . . . . . . . . . . . . . . 15 76 6. Authorization Information Format . . . . . . . . . . . . . . 16 77 6.1. AIF Information Model . . . . . . . . . . . . . . . . . . 16 78 6.2. AIF Data Model . . . . . . . . . . . . . . . . . . . . . 17 79 7. Client Information Format . . . . . . . . . . . . . . . . . . 18 80 7.1. CIF for the Push scheme . . . . . . . . . . . . . . . . . 18 81 7.2. CIF for the Client-Pull scheme . . . . . . . . . . . . . 19 82 8. Message Processing . . . . . . . . . . . . . . . . . . . . . 20 83 8.1. Unauthorized Access Attempt . . . . . . . . . . . . . . . 20 84 8.2. Authorization Request . . . . . . . . . . . . . . . . . . 21 85 8.3. Receiving Authorization Information . . . . . . . . . . . 22 86 8.4. Receiving Client Information . . . . . . . . . . . . . . 23 87 8.5. Resource Request and Response . . . . . . . . . . . . . . 23 88 9. Security Considerations . . . . . . . . . . . . . . . . . . . 24 89 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 90 11. Acknowledmgents . . . . . . . . . . . . . . . . . . . . . . . 24 91 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 92 12.1. Normative References . . . . . . . . . . . . . . . . . . 25 93 12.2. Informative References . . . . . . . . . . . . . . . . . 25 94 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 26 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 97 1. Introduction 99 Authorization is the process of deciding what an entity ought to be 100 allowed to do. Authorization management and processing access 101 control policies in order to reach an authorization decision is often 102 a heavyweight task, involving e.g. database lookups, credential 103 verification and matching large sets of values against each other. 104 Constrained devices are ill-equipped to handle this on their own, 105 therefore the logical approach is to offload authorization management 106 and part of the decision process to a less constrained, trusted third 107 party. 109 This memo describes an approach to authorization in constrained-node 110 networks using dedicated resources for access management. The 111 various entities in the architecture handle authorization information 112 by making RESTful requests (GET/PUT/POST/DELETE) to these resources 113 and thereby establish the necessary security contexts for 114 interactions between endpoints. 116 The approach is based on the use cases from [I-D.ietf-ace-usecases] 117 and on the architecture and problem description from 118 [I-D.gerdes-ace-actors]. It introduces protocols for requesting 119 authorization information from a trusted third party, encodings for 120 such authorization information and protocols for transferring it to 121 the affected device(s). We assume that CoAP [RFC7252] is the 122 preferred application-layer protocol and that constrained devices 123 implementing these mechanisms can be as resource constrained as class 124 1 according to the definitions in [RFC7228]. 126 An important goal in the design of this framework is to preserve end- 127 to-end security in the presence of untrusted intermediate nodes in 128 the communication of requests, responses and related authorization 129 information. 131 1.1. Terminology 133 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 134 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 135 document are to be interpreted as described in [RFC2119]. 137 Certain security-related terms are to be understood in the sense 138 defined in [RFC4949]. These terms include, but are not limited to, 139 "authentication", "authorization", "confidentiality", "(data) 140 integrity", "message authentication code", and "verify". 142 RESTful terms including "resource", "representation", etc. are to be 143 understood as used in HTTP [RFC7231] and CoAP [RFC7252]. 145 Terminology for constrained environments including "constrained 146 device", "constrained-node network", "class 1", etc. is defined in 147 [RFC7228]. 149 Terminology for entities in the architecture is defined in 150 [I-D.gerdes-ace-actors], such as the constrained nodes Client (C) and 151 Resource Server (RS), and the less constrained nodes Client 152 Authorization Server (CAS) and Authorization Server (AS). 154 Since this draft focuses on the problem of access control to 155 resources it is for simplicity assumed that the Client Authorization 156 Server functionality is not stand-alone but subsumed by either the 157 Authorization Server or the Client (see section 2.2 in 158 [I-D.gerdes-ace-actors]). 160 We use the term "authorization token" for authorization information 161 that is protected with object security. 163 2. Overview 165 This section contains an overview of the authentication and 166 authorization problem and the solution described in this memo. We 167 begin with two generic examples. 169 2.1. Example A: Access to an Actuator 171 Consider an actuator, e.g. in an industrial control system. Set in 172 the terms of the architecture [I-D.gerdes-ace-actors], the actuator 173 is hosted in one endpoint, acting RS, and another endpoint, acting C, 174 is requesting access to the actuation resource. 176 Security requirements of special importance are: 178 o RS needs to verify that the requesting Client is authorized to 179 access the resource. 181 o Integrity and replay protection of request. Assuming CoAP, 182 integrity protection applies to Payload but also to other fields 183 such as for example the CoAP option Uri-path. 185 o C must be able to verify the integrity of the response, and that 186 the received message is the response to the previously made 187 request, in order for C to verify that the actuation was 188 performed. 190 o It must be possible to confidentiality protect the request and 191 response, e.g. for privacy reasons. 193 2.2. Example B: Multiple Devices Accessing Sensor Data 195 Consider a constrained sensor performing measurements consumed by 196 multiple devices. Since the communication of a duty-cycled sensor 197 with each consuming device would require energy expensive radio 198 receptions and transmissions, it is favorable to minimize the number 199 of devices that directly interact with the sensor. Therefore the 200 sensor publishes (e.g. sends notifications with) measurements to a 201 message broker, which forwards the measurements to subscribing 202 devices. Access control is performed by only giving plaintext access 203 to authorized subscribers. 205 In the terminology of [I-D.gerdes-ace-actors] this means that the 206 sensor acts RS and the subscribing devices are Clients. In this 207 case, the RS may neither be able to verify integrity nor replay of 208 individual client requests, nor authorize individual clients, since 209 it isn't necessarily interacting directly with any clients. For the 210 same reason the client is not able to match a publication against a 211 request. The main relevant security requirements here are: 213 o Access to plaintext publications must be restricted to authorized 214 Clients. 216 o A Client needs to verify the origin of the publication, and that 217 it is not a replay of an old publication. 219 2.3. The Authentication and Authorization Problem 221 Both examples in the previous subsections are encompassed by the 222 problem statement described in [I-D.gerdes-ace-actors] but their 223 security requirements are quite different. On a high level, the 224 authentication and authorization problem can be broken down into 225 three sub-problems: 227 1. The policy for resource access as defined by the Resource Owner 228 (RO) and managed by the Authorization Server (AS) needs to be 229 translated into authorization information following an 230 Authorization Information Format (AIF) that the RS can parse and 231 act upon. 233 2. Similarly, the Client may need to acquire keys/credentials or 234 other information from the AS to securely access the resource. 235 Such client information is encoded following a Client Information 236 Format (CIF). 238 3. In order for Client and RS to authenticate and authorize 239 according to policy, the communication of the various information 240 elements needs to be protected appropriately end-to-end: from AS 241 to C, from AS to RS, and between C and RS. 243 To access an actuator, as in example A, the authorization information 244 could be an authorization decision that C is granted access to a 245 certain resource, or attributes of C that RS can match against 246 internal access policies. The client information could be 247 cryptographic keys which C could use to establish secure 248 communication with RS. 250 In the publish-subscribe scenario of example B, the authorization 251 information (if present) could be cryptographic keys that must be 252 used for protection of published resource representations. The 253 client information could be cryptographic keys/credentials with which 254 publications of certain resource representations can be verified and 255 decrypted. 257 Communication security could be addressed with a session security 258 based protocol such as DTLS [RFC6347], or an object security solution 259 based on e.g. COSE [I-D.schaad-cose-msg] (see Section 4). 261 The other sub-problems listed in this section, AIF and CIF, are 262 further detailed in Section 6 and Section 7, respectively. 264 2.4. Solution Overview 266 Considering the large variety of use cases, it may be difficult to 267 address the authentication and authorization problem with one single 268 protocol instance. In this section we list some guiding principles 269 for a solution. The remainder of the document provides solution 270 components based on the principles listed in this section. In 271 Section 8 the detailed processing steps are presented. In Appendix A 272 examples of the proposed solution are given. 274 PRINCIPLE 1: Allow different order of information flows 276 The information flows, including AIF, CIF, and Resource Request/ 277 Response (RRR) (Figure 1), may take place in different order see 278 Section 3. 280 +---------------------------------+ 281 | Authorization | 282 | Server | 283 +---------------------------------+ 284 | | 285 CIF AIF 286 | | 287 V V 288 +--------+ +----------+ 289 | Client |<--- RRR --->| Resource | 290 | | | Server | 291 +--------+ +----------+ 293 Figure 1: Information flows 295 PRINCIPLE 2: Build upon REST 297 The information flows should leverage the RESTful architecture. For 298 RRR this is already assumed, but RESTful administrative resources for 299 managing access to e.g. AIF and CIF need to be defined. The support 300 for REST should not preclude optimizations for particular protocols, 301 for example some flows may be embedded within the DTLS handshake. 303 PRINCIPLE 3: Allow security at different layers 305 Leave to the application to decide about session based or object 306 based security for any given information flow. 308 3. Information Flows 310 This section gives an overview of information flows between the 311 entities in the architecture, and the use of access management 312 resources. 314 3.1. Message Sequences 316 The information flows in scope between the nodes (constrained to 317 constrained and constrained to less constrained) are described in 318 [I-D.gerdes-ace-actors]. Taking [RFC2904] as a starting point, there 319 are three authorization schemes, defining the message sequences for 320 the flow of request, response, and authorization data: 322 1. In the Push scheme, C first obtains authorization information 323 from AS and then transmits this data to RS together with its 324 request, and finally RS sends its reply. In this model RS does 325 not communicate with AS directly. 327 2. In the Pull scheme, C sends its request to RS directly, RS then 328 contacts AS in order to obtain authorization information, AS 329 provides authorization information, and finally RS sends back the 330 reply. In this model C does not communicate with AS directly. 332 3. In the Agent scheme, C sends its request to AS, which evaluates 333 C's access rights and, if authorized, executes the request on C's 334 behalf, transmitting RS's response back to C. In this model C 335 does not communicate with RS directly. 337 Depending on use case, different schemes may be more appropriate than 338 others. From a constrained-node network point of view we note the 339 following: 341 o The Push and Agent scheme requires C to connect to AS. 343 o The Pull and Agent scheme requires RS to connect to AS. 345 o The Pull scheme requires RS to handle two secure connections at 346 the same time (RS - AS and RS - C) in order to perform the real 347 time authorization check. 349 Considering processing and memory requirements of RS, the Push scheme 350 is more favorable than the Pull scheme. 352 The Agent scheme assumes constant connectivity with both C and RS and 353 is therefore not applicable to the constrained setting. 355 However, the publish-subscribe case from Section 2.2 is not covered 356 by any of the schemes so this memo defines a new scheme, called 357 Client-Pull. 359 4. In the Client-Pull scheme, RS first provides unconditional access 360 to a protected resource representation. C obtains this protected 361 resource representation and then contacts AS to obtain 362 authorization information (in this case cryptographic keys) for 363 access and verification of the resource representation. In this 364 model RS does not communicate with AS directly, and C does not 365 communicate with RS directly. 367 The Client-Pull scheme is only useful for GET access. However, it 368 offloads the RS considerably, since the RS neither receives any 369 requests from clients nor performs any access control verifications. 370 Furthermore it enables use cases, such as caching and publish- 371 subscribe, that can not be covered by the other schemes in a 372 satisfactory manner. 374 3.2. Access Management Resources 376 This section describes an approach for transferring authorization 377 information between the various entities in the architecture by 378 making RESTful requests to dedicated resources for access management. 379 The structure or naming of such "access management resources" is left 380 for a future version of this memo, and for simplicity we denote any 381 such resource "/authorize". 383 In this section we illustrate various message sequences for 384 transferring authorization information by means of requesting access 385 management resources. We assume, as in section 3.2 of 386 [I-D.gerdes-ace-dcaf-authorize], that the need for transferring 387 authorization information may be triggered by a request from C to RS 388 to access a resource. Figure 2 shows C making an access request (GET 389 /PUT/POST/DELETE) which cannot be granted by the RS because of 390 missing authorization information. 392 C RS 393 | | 394 | Request /resource | 395 | ------------------------> | 396 | <------------------------ | 397 | Unauthorized | 398 | | 400 Figure 2: Access request unauthorized. 402 Starting with the Pull scheme, if the RS can access the AS, then any 403 missing authorization information could be requested on the fly, see 404 Figure 3. The RS sends an authorization request in a specific 405 Authorization Request Format (ARF) to the /authorize resource at the 406 AS as detailed in Section 8 and receives authorization information in 407 a specific Authorization Information Format (AIF) in the response. 408 RS updates the stored authorization information based on the new 409 information and executes the client's resource request accordingly. 410 Note that C and RS need be mutually authenticated using pre- 411 established credentials in this scheme. 413 C RS AS 414 | | | 415 | Request /resource | | 416 | ------------------------> | | 417 | | POST /authorize ARF | 418 | | ------------------------> | 419 | | <------------------------ | 420 | | AIF | 421 | | | 422 | <------------------------ | | 423 | Granted | | 424 | | | 426 Figure 3: Pull Scheme 428 In use cases where the RS does not have connectivity with AS, or if 429 the RS cannot handle two secure connections at the same time, the 430 Push scheme provides an alternative, see Figure 4. C receives, in 431 the negative response to its resource request, information about 432 where to request the missing authorization information. In this case 433 it is C that requests the resource /authorize at the AS and receives 434 both authorization information, and client information in a specific 435 Client Information Format (CIF). The latter will be used by C to 436 establish communication security with RS. Next, C pushes the 437 authorization information to the /authorize resource at the RS. RS 438 updates the stored authorization information based on the new data 439 and confirms the change, after which C can repeat the resource 440 request to the RS with the new client information and authorization 441 information in place. 443 AS C RS 444 | | | 445 | | Request /resource | 446 | | ------------------------> | 447 | | <------------------------ | 448 | | Unauthorized | 449 | POST /authorize ARF | | 450 | <------------------------ | | 451 | ------------------------> | | 452 | AIF, CIF | | 453 | | | 454 | | POST /authorize AIF | 455 | | ------------------------> | 456 | | <------------------------ | 457 | | Changed | 458 | | | 459 | | Request /resource | 460 | | ------------------------> | 461 | | <------------------------ | 462 | | Granted | 463 | | | 465 Figure 4: Push Scheme 467 Note that in case there is connectivity between RS and AS, but RS has 468 not implemented the Pull scheme or cannot handle two secure 469 connections at the same time, then AS could POST the authorization 470 information to the /authorize resource of RS directly instead of 471 using C as intermediary node. 473 Also note that the authorization information needs to be integrity 474 protected during the transport between AS and RS. This is because 475 the client has access to it and would otherwise be able to change its 476 permissions. How this is done is described in Section 4. 478 Finally the Client-Pull scheme, which only requires C to request a 479 Protected Resource Representation from the RS, and client information 480 (e.g. cryptographic keys) from the AS. 482 AS C RS 483 | | | 484 | | GET /resource | 485 | | ------------------------> | 486 | | <------------------------ | 487 | | Protected Resource | 488 | | Representation | 489 | | | 490 | POST /authorize ARF | | 491 | <------------------------ | | 492 | ------------------------> | | 493 | CIF | | 494 | | | 496 Figure 5: Client-Pull Scheme 498 Note that the order of the information flows is different for the 499 different authorization schemes. The authorization scheme is defined 500 at design time, so an RS would typically support one specific message 501 sequence suitable for the particular application. 503 4. Communication Security 505 In this section we address the third sub-problem of Section 2.3, the 506 authentication and communication security problem, based on the 507 assumptions made in [I-D.gerdes-ace-actors]: 509 o AS and RS are assumed to have established security contexts (keys, 510 credentials, security protocols, parameters). How this was 511 established is out of scope for this work. 513 o AS is assumed to have a policy for how C is allowed to access the 514 resources of RS, including information for how to authenticate C, 515 such as a shared secret key, public key or other credential. 517 o Both session based and object based security solutions shall be 518 supported. 520 Since CoAP is the default communication protocol, DTLS [RFC6347] is 521 the default session based security protocol. DTLS MUST NOT be used 522 with untrusted intermediary nodes. For object security in 523 constrained environments, COSE [I-D.schaad-cose-msg] is the main 524 candidate. OSCOAP [I-D.selander-ace-object-security] defines a 525 profile of COSE, suitable for securing individual CoAP messages, and 526 two Modes of operation: 528 o Mode:PAYL for (CoAP) Payload confidentiality, integrity and replay 529 protection. 531 o Mode:COAP for additional protection of CoAP Headers (Code) and 532 Options (Uri-Path, Uri-Query etc.) and for securing request- 533 response pair. 535 4.1. AS - RS 537 The main purpose of this communication is to provide authorization 538 information from AS to RS. There are three communication patterns: 540 1. RS: POST /authorize to AS (ARF in request, AIF in response) 542 2. AS: POST /authorize to RS (AIF in request) 544 3. C: POST /authorize to AS (ARF in request, AIF in response) 545 followed by C: POST /authorize to RS (AIF in request) 547 Pattern 1. and 2. SHALL be protected by DTLS or COSE Mode:COAP, 548 leveraging the pre-established security context. In pattern 3., 549 since C is an untrusted intermediary node, the authorization 550 information SHALL be protected end-to-end from AS to RS with COSE 551 Mode:PAYL, leveraging the pre-established credentials. 553 Pattern 2. with COSE Mode:COAP includes the case of POST via an 554 intermediary untrusted Forward Proxy, which in particular could be 555 the Client, if the Client supports Forward Proxy functionality. 557 In pattern 3. the use of transport layer security (DTLS) or CoAP 558 message security (Mode:COAP) is optional, since Mode:PAYL protected 559 authorization information is in itself a confidential, integrity and 560 replay protected token. 562 If the subsequent communication between C and RS is going to be 563 protected by DTLS, then an OPTIONAL optimization of the message 564 exchange is to replace "C: POST /authorize to RS (AIF in request)" 565 with a transfer of the protected authorization in the DTLS Handshake, 566 see Section 4.4. 568 4.2. AS - C 570 The main purpose of this communication is to provide client 571 information from the AS to the C. The communication pattern is: 573 o C: POST /authorize to AS to (ARF in request, CIF in response) 575 This pattern SHALL be protected by DTLS or COSE Mode:COAP, leveraging 576 out of band established credentials. 578 4.3. C - RS 580 This is the original resource request/response problem. Since there 581 may be no pre-established keys between C and RS, it is the purpose of 582 AIF and CIF to provide information for authentication and 583 communication security. There are two communication patterns: 585 1. The Client makes a request (GET/PUT/POST/DELETE /resource) to RS 586 and receives a response. 588 2. The Client makes a GET request to the RS, or a cache, or message 589 broker and unconditionally receives a protected resource 590 representation 592 Pattern 1. SHALL be protected by DTLS or COSE Mode:COAP, leveraging 593 the established keys or credentials in authorization information and 594 client information. Pattern 2. SHALL be protected with COSE 595 Mode:PAYL. 597 4.4. Authorization Information transfer in the DTLS Handshake 599 In certain situations, a session security protocol like DTLS 600 [RFC6347] can be used directly to send the authorization information 601 to the RS and optimize the message exchange. The authorization 602 information MAY be embedded in the DTLS handshake. In this case the 603 authorization information SHOULD be transferred using the TLS 604 supplemental data extension [RFC4680]. 606 Figure 6 illustrates this approach for a DTLS handshake. The 607 messages marked with * are optional depending on the type of 608 handshake. 610 Client Resource Server 611 ------ --------------- 613 ClientHello (with extensions) -------> 615 <------- HelloVerifyRequest 617 ClientHello (with extensions) --------> 619 ServerHello 620 Certificate* 621 ServerKeyExchange* 622 CertificateRequest* 623 <-------- ServerHelloDone 625 SupplementalData (AIF) 626 Certificate* 627 ClientKeyExchange 628 CertificateVerify* 629 [ChangeCipherSpec] 630 Finished --------> 631 [ChangeCipherSpec] 632 <-------- Finished 633 Application Data <-------> Application Data 635 Figure 6: Authorization information Transfer in Handshake 637 The SupplementalDataType value SHOULD be set to 16386 (authz_data). 638 The Resource Server MUST verify the validity of the received 639 authorization information before accepting any application data from 640 the client. 642 The RS MUST verify that the authorization information transmitted in 643 the SupplementalData message is bound to the same key as the one the 644 Client used in the handshake (see Section 6 for the subject binding 645 in the AIF). Note that this also enables AS-asserted authorization 646 of the DTLS handshake. 648 5. Authorization Request Format 650 Authorization requests are represented in the Authorization Request 651 Format (ARF). They are produced either by the Client (Push, Client- 652 Pull) or the RS (Pull) and consumed by the AS. The ARF allows to 653 specify requests for several actions on several resources in a single 654 message. 656 5.1. ARF Information Model 658 The general information that needs to be contained in the ARF is the 659 following: 661 o The identifier of the subject of this authorization request 662 (usually the Client). 664 o The identifier of the host that provides the resources that are 665 requested in this authorization request (CoAP option URI-host). 666 Note that the ARF does not allow to specify more than one host. 668 o The requested resources and actions on these resources. 670 The resources can be represented by the "path-absolute" part of the 671 URI (In CoAP this would be the Uri-Path options). 673 5.2. ARF Data Model 675 For representing the ARF discussed in Section 5.1 the following steps 676 are performed: 678 o The subject identifier is encoded in a map that maps the type of 679 the identifier to its value. The type could e.g. be a raw public 680 key, or the key identifier of a secret key, or a X.509 681 distinguished name. 683 o The host identifier is encoded as second parameter. 685 o The third parameter is array of resource-actions tuples. The 686 structure of the entries is specified as follows: 688 * Requests that affect the same resource are merged into a single 689 entry that specifies the union of the permitted actions. 691 * The actions GET, POST, PUT, DELETE are represented as integer 692 0, 1, 2, and 3 respectively. 694 * The set of numbers is converted into a single number by taking 695 each number to the power of two and computing the inclusive OR 696 of the binary representations of all the numbers. 698 * Each entry is an array, containing the resource identifier, and 699 the number representing the actions. 701 This information can then be represented in CBOR [RFC7049] or JSON 702 [RFC7159] as an array of the elements listed above. An example JSON 703 representation of the ARF is given in Figure 7. 705 [{"subjectKeyId":"someKeyId1"}, "rs.example.com", 706 [["sensors/tempC",1], ["conf/sleepInterval", 5], 707 ["conf/sleepDuration", 5]]] 709 Figure 7: Example JSON representation of an access request 711 6. Authorization Information Format 713 Addressing the first sub-problem of Section 2.3, this section defines 714 an Authorization Information Format (AIF) for encoding authorization 715 information. AIF instances are either consumed directly by an RS 716 (Pull), or packaged into a COSE Mode:PAYL token and sent to the 717 Client, who forwards the token to the RS (Push). 719 This memo defines two different types of AIF that can be used by an 720 AS: 722 o One or more access control decisions, listing one or more tuples 723 of actions and resources similar to a capability list. This is a 724 simple super-set of the ARF. 726 o Group memberships for the Client. This type of AIF is used in a 727 configuration where the RS stores access control lists (ACLs) 728 corresponding to a number of groups. The RS will resolve a 729 specific group to a specific set of ACLs which are then applied to 730 the request. 732 6.1. AIF Information Model 734 The general information that needs to be contained in the AIF is the 735 following: 737 o The identifier of the subject of this authorization information 738 (usually the Client) 740 o The identifier of the host that provides the resources for which 741 this authorization information applies (CoAP option URI-host). 742 Note that the AIF does not allow to specify more than one host. 744 If the authorization information represents one or more group 745 memberships, the only other information needed is the group names. 746 If the authorization information represents access control decisions, 747 the affected resources and the actions are needed. 749 Authorization decisions can also MAY contain local conditions, that 750 can only be evaluated by the RS at access time (e.g. 751 "NotBefore='09:00', NotAfter='18:00'"). This memo does not define 752 the format of these local conditions, as it is expected that these 753 will be application specific. The RS MUST reject any authorization 754 information that contains local conditions that it does not 755 understand. 757 6.2. AIF Data Model 759 For representing the AIF discussed in Section 6.1 the following steps 760 are performed: 762 o The subject identifier is encoded in a map that maps the type of 763 the identifier to its value. The type could e.g. be a raw public 764 key, or the key identifier of a secret key, or a X.509 765 distinguished name. Section 4.3 defines how this is used to bind 766 the authorization information to a specific client. 768 o The host identifier is encoded as second parameter. 770 o The third parameter is either an array of access control 771 decisions, or if group memberships are asserted, a map, mapping 772 the key 'grp' to the array of group names. The structure of the 773 entries in the access control decision array is the same as for 774 the ARF, except that is may also contain local conditions 775 represented as strings. 777 o Each entry is an array, containing the resource identifier, the 778 number representing the actions, and optionally the local 779 conditions. 781 This information can then be represented in CBOR [RFC7049] or JSON 782 [RFC7159] as an array of the elements listed above. An example JSON 783 representation of the AIF with access control decisions is given in 784 Figure 8, while an example of the AIF containing group membership 785 assertions is shown in Figure 9. 787 [{"SubjectKeyId":"someKeyId2"}, "rs.example.com", 788 [["actuators/doorLock", 5, "not-before:'07:00';not-after:'18:00'"]]] 790 Figure 8: Example JSON representation of access control decisions 792 [{"SubjectPublicKey":"MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEJG4m93 793 ED8tPK2CpkhrrtKNx1vXDbml4Fun1628Qkl1U_aIB5zUfqPwaacznbqoMJ6vQVZ7 794 4X9HpfynouLK_ujw"}, "rs.example.com", 795 {"grp":["admin","user"]}] 797 Figure 9: Example JSON representation of group memberships 799 Note that different subject identifiers might be used in instances of 800 the ARF and the AIF in the same Push scheme. This is due to the fact 801 that the credential the Client uses towards the AS may not be the 802 same as the one later used towards the RS. 804 7. Client Information Format 806 This section addresses the second sub-problem of Section 2.3, and 807 describes a format for client information. Two types of client 808 information are defined in this section: 810 1. Client Information related to the Push scheme, which encodes keys 811 and related parameters, that allow the Client to communicate 812 securely with the RS and prove that it is the legitimate subject 813 of some authorization information. 815 2. Client Information related to the Client-Pull scheme represent 816 keys and related parameters that allow the Client to access and 817 verify a resource representation protected with object security. 819 For the Push scheme, the CIF must be able to encode instructions to 820 the Client on how secure the connection between Client and RS, and 821 how to transfer the authorization information to the RS. 823 7.1. CIF for the Push scheme 825 The encoding of the client information in a Push scheme is an array 826 with the following elements: 828 1. The type of this client information, here the string 'push'. 830 2. The method to be used for securing the transfer. Either the 831 string 'coaps' (for CoAP over DTLS) or the string 'oscoap' (for 832 CoAP with object security). 834 3. The method of transferring the authorization information. Either 835 the string 'suppl' (for supplemental data) or the URI of the 836 resource on the RS to which the authorization information should 837 be transferred. 839 4. The type of key to be used for coaps of oscoap. This can either 840 be a raw public key denoted by the string 'rpk', or a pre-shared 841 key denoted by the string 'psk'. 843 5. If the key type was 'psk', then the next element is the 844 identifier of this key. If the key type was 'rpk' this element 845 is the raw public key of the RS. The encoding here should follow 846 the SubjectPublicKeyInfo defined in RFC 7250 [RFC7250]. 848 6. If the key type was 'psk', then the next element is the pre- 849 shared key that the Client should use either for DTLS or object 850 security. The encoding of this key depends on the representation 851 format. For CBOR it is raw bytes, for JSON it is Base64 encoded 852 bytes. 854 Figure Figure 10 shows an example representation of the CIF for a 855 Push scheme, using JSON. 857 ["push", "oscoap", "/authorize", "psk", 858 "someKeyId", "Z4LXBNbOeeOJOYglBLb4pg"] 860 Figure 10: CIF example for the Push scheme 862 7.2. CIF for the Client-Pull scheme 864 The encoding of the CIF for a Client-Pull scheme is an array with the 865 following elements: 867 1. The type of this client information, here the string 'cpull'. 869 2. The public key of the RS used to sign the resource 870 representation. The encoding here should follow the 871 SubjectPublicKeyInfo defined in RFC 7250 [RFC7250]. 873 3. The secret key used to encrypt the resource representation. The 874 encoding of this key depends on the representation format. For 875 CBOR it is raw bytes, for JSON it is Base64 encoded bytes. 877 Note that further parameters are provided in the secure object 878 itself, such as e.g. algorithm identifiers and initialization 879 vectors. 881 Figure Figure 11 shows an example representation of the CIF for a 882 Client-Pull scheme, using JSON. 884 ["cpull", "MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEJG4m93 885 ED8tPK2CpkhrrtKNx1vXDbml4Fun1628Qkl1U_aIB5zUfqPwaaczn 886 bqoMJ6vQVZ74X9HpfynouLK_ujw", "eyJhbGciOiJIUzI1NiIsIm"] 888 Figure 11: CIF example for the Client-Pull scheme 890 8. Message Processing 892 This section puts together the pieces from previous sections and 893 specifies more in detail the processing steps for the authorization 894 schemes defined in Section 3. 896 8.1. Unauthorized Access Attempt 898 All schemes can start with the Client requesting access at the RS 899 without any established authorization information. Depending on 900 which authorization scheme (Push, Pull, Client Pull) the RS has 901 implemented, the RS can either: 903 o Query the AS using the Pull scheme. 905 o Instruct the Client to use the Push scheme. 907 o In case the Client-Pull scheme, provide an encrypted 908 representation of the resource that was requested, without 909 performing any access control. 911 If the RS wants the Client to use the Push scheme, the RS MUST 912 respond with an error message using the response code 4.01 913 (Unauthorized). The error message MUST contain information that 914 allows the Client to locate the AS responsible for the requested 915 resource, and other information needed to make an Authorization 916 Request. For example: 918 4.01 Unauthorized 919 Content-Format: application/json 920 ["oscoap", "as.example.com/authorize"] 922 The response payload MAY be protected, e.g. signed with the private 923 key of RS, using COSE Mode:PAYL. The response MAY include 924 authentication information of AS, such as the (hash of the) public 925 key of AS. The public key of RS or AS be retrieved in different ways 926 e.g. from a Resource Directory 927 The initial exchange described in this section may be omitted, and 928 the client can start with the Authorization Request to AS as 929 described in Section 8.2 if the Client has obtained information about 930 the relevant AS in some other way, e.g. using a Resource Directory. 932 If the RS has access to authorization information about the Client, 933 but it does not apply to the requested resource, the RS MUST answer 934 with an error message using the response code 4.03 (Forbidden). If 935 the RS has authorization information for the Client that applies to 936 the requested resource, but that does not cover the requested action, 937 the RS MUST reply with an error message using the response code 4.05 938 (Method Not Allowed). 940 8.2. Authorization Request 942 Either the Client (Push scheme) or the RS (Pull scheme) can POST an 943 request to the /authorize resource at the AS, specifying the Client's 944 request(s) for authorization using the ARF defined in Section 5. 946 Upon receiving a POST request to /authorize, the AS MUST perform the 947 following steps: 949 o Ensure that the request was received over a secure channel (DTLS) 950 or uses object security. If object security was used the AS MUST 951 perform the necessary verifications. 953 o Ensure that the requesting party is authenticated. This is either 954 the Client (as described in Section 4.2) or the RS (as described 955 in Section 4.1). For DTLS this is supposed to have happened 956 during the handshake, for object security this is accomplished by 957 a signature or MAC over the request, produced by the requesting 958 party. 960 o Control that the requesting party is authorized to submit this 961 kind of authorization request 963 If the integrity verification fails, the AS MUST respond with an 964 error message using the response code 4.00 (Bad Request) 966 If the requesting party is not correctly authenticated, the AS MUST 967 respond with an error message using the response code 4.01 968 (Unauthorized). 970 If the requesting party is not authorized to perform this request for 971 authorization information, the AS MUST respond with an error message 972 using the response code 4.03 (Forbidden). 974 If the evaluation is successful the AS MUST respond with a 2.05 975 (Content) message code. The response can contain one of the 976 following payloads: 978 o If any part of the access requested by the Client was not 979 authorized, the payload MUST be empty. 981 o If all parts of the access requested by the Client were 982 authorized, the payload MUST be either in AIF, CIF or both, 983 depending on the authorization scheme: 985 1. If the Authorization Scheme is Pull, then the payload MUST be in 986 AIF, as defined in Section 6. 988 2. If the Authorization Scheme is Client-Pull, then the payload MUST 989 be in CIF as defined in Section 7. 991 3. If the Authorization Scheme is Push, then the payload MUST be an 992 array containing first CIF, then AIF, as defined in Section 7 and 993 Section 6 respectively. 995 8.3. Receiving Authorization Information 997 The RS may receive authorization information in a response to a POST 998 to an Authorization Request as described in the previous section. 1000 As an alternative this section describes how to push this information 1001 to the RS. This is done with a POST of the authorization information 1002 to the /authorize resource on the RS. This request may come from the 1003 Client in the Pull scheme, as defined in Pattern 3 in Section 4.1. 1004 The request may also come from the AS directly. 1006 Figure 12 illustrates the successful execution of such a request. 1008 C/AS RS 1009 | | 1010 | POST /authorize AIF | 1011 | ------------------------> | 1012 | <------------------------ | 1013 | 2.01 Created | 1014 | | 1016 Figure 12: POST AIF to /authorize 1018 A third OPTIONAL method is to include the authorization information 1019 in a DTLS handshake as supplemental data, as described in 1020 Section 4.4. 1022 Irrespective of how the authorization information is received by the 1023 AS, upon receiving it, RS MUST verify that it is valid, by doing the 1024 following: 1026 o Check that the authorization information comes from a trusted AS 1028 o Check that the host in the authorization information corresponds 1029 to itself 1031 o Check that the authorization information is not expired or 1032 revoked, if the object security encapsulation allows this 1034 o Verify the integrity of the authorization information 1036 If the validation succeeds, RS MUST store the authorization 1037 information and use it to determine the authorization of future 1038 requests. 1040 If the authorization information is invalid, RS MUST respond with an 1041 error message using the error code 4.03 (Forbidden). 1043 8.4. Receiving Client Information 1045 The Client receives client information in a response to a POST of an 1046 authorization request to an AS as described in Section 8.2. The 1047 Client MUST make sure that it is communicating with a trusted AS. If 1048 the communication is protected with COSE Mode:COAP, the Client MUST 1049 verify the authenticity and integrity of the client information, 1050 before using it. 1052 8.5. Resource Request and Response 1054 The final resource request is handled differently based on which 1055 authorization scheme is implemented. In the Pull scheme this is an 1056 unauthorized request as described in Section 8.1. For resources 1057 configured to use the Client-Pull scheme for GET access, the RS MUST 1058 unconditionally provide an encrypted and signed representation of the 1059 requested resource to any requesting Client. 1061 In the Push scheme the RS MUST perform the following steps: 1063 o If the communication is secured with DTLS, verify that the 1064 handshake included client authentication. If the communication is 1065 protected with Mode:COAP, verify the object security of the 1066 request. 1068 o Verify the present authorization information to see if it has data 1069 that matches the Client, the requested resource, and the actions 1070 requested on that resource. Note specifically that the binding 1071 between the authorization information and the Client is provided 1072 either by comparing with the keys used in the DTLS handshake, or 1073 with the keys used for object security of the request. 1075 o If some matching authorization information contains local 1076 conditions, verify that these are fulfilled. 1078 If any of these verifications fail, the RS treat the request as 1079 specified in Section 8.1. 1081 If all of these verifications succeed, the RS MUST process the 1082 request as required by the underlying application. 1084 If the request was protected with Mode:COAP, the RS MUST follow the 1085 response protecting scheme for this mode. 1087 9. Security Considerations 1089 The entire document is about security. Security considerations 1090 applicable to authentication and authorization in RESTful 1091 environments provided in OAuth 2.0 [RFC6749] apply to this work, as 1092 well as the security considerations from [I-D.gerdes-ace-actors]. 1094 10. IANA Considerations 1096 This document has no actions for IANA yet. 1098 11. Acknowledmgents 1100 Some of the ideas of this document were originally described in a now 1101 expired Internet Draft: draft-selander-core-access-control-01. The 1102 authors would also like to thank Carsten Bormann, Stefanie Gerdes and 1103 Olaf Bergmann for the inspiration drawn from draft-bormann-core-ace- 1104 aif [I-D.bormann-core-ace-aif] and [I-D.gerdes-ace-dcaf-authorize]. 1106 This work has further drawn inspriation from [OSCAR] which presents 1107 another scheme for securing resource request and response using 1108 object security and where access key transport is performed by means 1109 of RESTful requests to dedicated resources. 1111 12. References 1113 12.1. Normative References 1115 [I-D.schaad-cose-msg] 1116 Schaad, J., "CBOR Encoded Message Syntax", draft-schaad- 1117 cose-msg-00 (work in progress), June 2015. 1119 [I-D.selander-ace-object-security] 1120 Selander, G., Mattsson, J., and L. Seitz, "March 9, 2015", 1121 draft-selander-ace-object-security-01 (work in progress), 1122 March 2015. 1124 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1125 Requirement Levels", BCP 14, RFC 2119, March 1997. 1127 [RFC4680] Santesson, S., "TLS Handshake Message for Supplemental 1128 Data", RFC 4680, October 2006. 1130 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1131 Security Version 1.2", RFC 6347, January 2012. 1133 [RFC7250] Wouters, P., Tschofenig, H., Gilmore, J., Weiler, S., and 1134 T. Kivinen, "Using Raw Public Keys in Transport Layer 1135 Security (TLS) and Datagram Transport Layer Security 1136 (DTLS)", RFC 7250, June 2014. 1138 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 1139 Application Protocol (CoAP)", RFC 7252, June 2014. 1141 12.2. Informative References 1143 [I-D.bormann-core-ace-aif] 1144 Bormann, C., "An Authorization Information Format (AIF) 1145 for ACE", draft-bormann-core-ace-aif-02 (work in 1146 progress), March 2015. 1148 [I-D.gerdes-ace-actors] 1149 Gerdes, S., Seitz, L., Selander, G., and C. Bormann, "An 1150 architecture for authorization in constrained 1151 environments", draft-gerdes-ace-actors-05 (work in 1152 progress), April 2015. 1154 [I-D.gerdes-ace-dcaf-authorize] 1155 Gerdes, S., Bergmann, O., and C. Bormann, "Delegated CoAP 1156 Authentication and Authorization Framework (DCAF)", draft- 1157 gerdes-ace-dcaf-authorize-02 (work in progress), March 1158 2015. 1160 [I-D.ietf-ace-usecases] 1161 Seitz, L., Gerdes, S., Selander, G., Mani, M., and S. 1162 Kumar, "ACE use cases", draft-ietf-ace-usecases-04 (work 1163 in progress), June 2015. 1165 [OSCAR] Vucinic, M., Tourancheau, B., Rousseau, F., Duda, A., 1166 Damon, L., and R. Guizzetti, "OSCAR: Object security 1167 architecture for the Internet of Things", Ad Hoc Networks 1168 Vol. 32, September 2015. 1170 [RFC2904] Vollbrecht, J., Calhoun, P., Farrell, S., Gommans, L., 1171 Gross, G., de Bruijn, B., de Laat, C., Holdrege, M., and 1172 D. Spence, "AAA Authorization Framework", RFC 2904, August 1173 2000. 1175 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", RFC 1176 4949, August 2007. 1178 [RFC6749] Hardt, D., "The OAuth 2.0 Authorization Framework", RFC 1179 6749, October 2012. 1181 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 1182 Representation (CBOR)", RFC 7049, October 2013. 1184 [RFC7159] Bray, T., "The JavaScript Object Notation (JSON) Data 1185 Interchange Format", RFC 7159, March 2014. 1187 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 1188 Constrained-Node Networks", RFC 7228, May 2014. 1190 [RFC7231] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol 1191 (HTTP/1.1): Semantics and Content", RFC 7231, June 2014. 1193 Appendix A. Examples 1195 The following examples show an overview the different authorization 1196 schemes presented in Section 3. The notation is as follows: 1198 A -> B : POST {blah} (request) 1199 \__ __/ \_ _/ \__ __/ \___ ___/ 1200 V V V V 1201 Communication RESTful Payload Type of 1202 partners and method payload 1203 direction of 1204 communication 1206 Messages protected with COSE Mode:COAP are denoted by adding 1207 'CoseC(Key)', where 'Key' is the key used to protect the message. 1209 Payload protected with COSE Mode:PAYL is denoted by 1210 'CoseP(Key){payload}', where 'Key' is the key used to protect the 1211 payload. 1213 Note that we use POST to request authorization information instead of 1214 GET, since with the latter, the request would need to be transported 1215 in CoAP options (e.g. Uri-Query), and it could potentially become 1216 larger than the maximum CoAP packet size. Since CoAP options can not 1217 be fragmented this would be extremely problematic. 1219 Example A (using the Push scheme) 1221 1. C -> RS : GET /sensors/tempC {} (request) 1223 2. RS -> C : 4.01 Unauthorized {"oscoap", "as.example.com/ 1224 authorize"} (response) 1226 3. C -> AS : POST /authorize CoseC(Key_C-AS) { [{"subjectKeyId 1227 ":"Key_C-AS"}, "rs.example.com", [['sensors/tempC', 1(= GET)]]] } 1228 (ARF) 1230 4. AS -> C : 2.05 CoseC(Key_C-AS) { ["push", "oscoap", "/authorize", 1231 "psk", "someKeyId", "Z4LXBNbOeeOJOYglBLb4pg"], CoseP(Key_AS-RS){ 1232 [{"SubjectKeyId":"someKeyId"}, "rs.example.com", [["sensors/ 1233 tempC", 1(= GET)]]] } } (CIF, AIF) 1235 5. C -> RS : POST /authorize CoseC(someKeyId) { CoseP(Key_AS- 1236 RS){[{"SubjectKeyId":"someKeyId"}, "rs.example.com", [["sensors/ 1237 tempC", 1(= GET)]]]} } (AIF) 1239 6. C -> RS : GET /sensors/tempC CoseC(someKeyId) {} (request) 1241 7. RS -> C : 2.05 CoseC(someKeyId) {37.5} (response) 1243 Example B (using the Pull scheme) 1245 1. C -> RS : POST /actuators/doorLock CoseC(someClientKey) {open} 1246 (request) 1248 2. RS -(DTLS)-> AS : POST /authorize { 1249 [{"subjectKeyId":"someClientKey"}, "rs.example.com", [['actuators 1250 /doorLock', 2(= POST)]]] } (ARF) 1252 3. AS -(DTLS)-> RS : 2.05 { [{"subjectKeyId":"someClientKey"}, 1253 "rs.example.com", [['actuators/doorLock', 2(= POST)]]] } (AIF) 1255 4. RS -> C : 2.04 (response) 1256 Example C (using the Client-Pull scheme) 1258 1. C -> RS : GET /sensors/tempC {} (request) 1260 2. RS -> C : 2.05 { CoseP(someKey){39.2} } (response) 1262 3. C -> AS : POST /authorize CoseC(Key_C-AS) { [{"subjectKeyId 1263 ":"Key_C-AS"}, "rs.example.com", [['sensors/tempC', 1(= GET)]]] } 1264 (ARF) 1266 4. AS -> C : 2.05 CoseC(Key_C-AS) { ["cpull", "RS_PublicKey", 1267 "someKey] } (CIF) 1269 The authorizon schemes defining these flows are introduced in 1270 Section 3, and detailed in Section 8. The message structures for 1271 ARF, AIF and CIF are introduced in Section 5, Section 6, and 1272 Section 7. 1274 Authors' Addresses 1276 Ludwig Seitz 1277 SICS 1278 Scheelevaegen 17 1279 Lund 223 70 1280 SWEDEN 1282 Email: ludwig@sics.se 1284 Goeran Selander 1285 Ericsson 1286 Faroegatan 6 1287 Kista 164 80 1288 SWEDEN 1290 Email: goran.selander@ericsson.com 1292 Malisa Vucinic 1293 STMicroelectronics 1294 850 Rue Jean Monnet 1295 Crolles 38920 1296 FRANCE 1298 Email: malisa.vucinic@st.com