idnits 2.17.1 draft-gerdes-core-dcaf-authorize-02.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 (February 14, 2014) is 3723 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: 'RFC-XXXX' is mentioned on line 1387, but not defined ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) ** Obsolete normative reference: RFC 7049 (Obsoleted by RFC 8949) == Outdated reference: A later version (-09) exists of draft-bormann-core-ace-aif-00 == Outdated reference: A later version (-21) exists of draft-ietf-core-block-14 == Outdated reference: A later version (-16) exists of draft-ietf-core-observe-12 == Outdated reference: A later version (-28) exists of draft-ietf-core-resource-directory-01 == Outdated reference: A later version (-01) exists of draft-schmertmann-dice-codtls-00 -- Obsolete informational reference (is this intentional?): RFC 5988 (Obsoleted by RFC 8288) Summary: 2 errors (**), 0 flaws (~~), 7 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CoRE Working Group S. Gerdes 3 Internet-Draft O. Bergmann 4 Intended status: Standards Track C. Bormann 5 Expires: August 18, 2014 Universitaet Bremen TZI 6 February 14, 2014 8 Delegated CoAP Authentication and Authorization Framework (DCAF) 9 draft-gerdes-core-dcaf-authorize-02 11 Abstract 13 This specification defines a protocol for delegating client 14 authentication and authorization in a constrained environment for 15 establishing a Datagram Transport Layer Security (DTLS) channel 16 between resource-constrained nodes. The protocol relies on DTLS to 17 transfer authorization information and shared secrets for symmetric 18 cryptography between entities in a constrained network. A resource- 19 constrained node can use this protocol to delegate authentication of 20 communication peers and management of authorization information to a 21 trusted host with less severe limitations regarding processing power 22 and memory. 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 August 18, 2014. 41 Copyright Notice 43 Copyright (c) 2014 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. Features . . . . . . . . . . . . . . . . . . . . . . . . 3 60 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 61 1.2.1. Roles . . . . . . . . . . . . . . . . . . . . . . . . 4 62 1.2.2. Other Terms . . . . . . . . . . . . . . . . . . . . . 4 63 2. System Overview . . . . . . . . . . . . . . . . . . . . . . . 5 64 3. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . 6 65 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 6 66 3.2. Unauthorized Resource Request Message . . . . . . . . . . 7 67 3.3. AS Information Message . . . . . . . . . . . . . . . . . 8 68 3.4. Access Request . . . . . . . . . . . . . . . . . . . . . 9 69 3.5. Ticket Request Message . . . . . . . . . . . . . . . . . 10 70 3.6. Ticket Grant Message . . . . . . . . . . . . . . . . . . 11 71 3.7. Ticket Transfer Message . . . . . . . . . . . . . . . . . 12 72 3.8. DTLS Channel Setup Between C and RS . . . . . . . . . . . 13 73 3.9. Authorized Resource Request Message . . . . . . . . . . . 13 74 3.10. Dynamic Update of Authorization Information . . . . . . . 14 75 3.10.1. Handling of Ticket Transfer Messages . . . . . . . . 15 76 4. Ticket . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 77 4.1. Face . . . . . . . . . . . . . . . . . . . . . . . . . . 16 78 4.2. Verifier . . . . . . . . . . . . . . . . . . . . . . . . 17 79 4.3. Revocation . . . . . . . . . . . . . . . . . . . . . . . 17 80 4.3.1. Lifetime . . . . . . . . . . . . . . . . . . . . . . 17 81 4.3.2. Revocation Messages . . . . . . . . . . . . . . . . . 17 82 5. Payload Format and Encoding (application/dcaf+cbor) . . . . . 18 83 5.1. Examples . . . . . . . . . . . . . . . . . . . . . . . . 19 84 6. DTLS PSK Generation Methods . . . . . . . . . . . . . . . . . 21 85 6.1. DTLS PSK Transfer . . . . . . . . . . . . . . . . . . . . 21 86 6.2. Distributed Key Derivation . . . . . . . . . . . . . . . 22 87 7. Authorization Configuration . . . . . . . . . . . . . . . . . 22 88 8. Trust Relationships . . . . . . . . . . . . . . . . . . . . . 22 89 9. Listing Authorization Server Information in a Resource 90 Directory . . . . . . . . . . . . . . . . . . . . . . . . . . 23 91 9.1. The "auth-request" Link Relation . . . . . . . . . . . . 23 92 10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 24 93 10.1. Access Granted . . . . . . . . . . . . . . . . . . . . . 24 94 10.2. Access Denied . . . . . . . . . . . . . . . . . . . . . 26 95 10.3. Access Restricted . . . . . . . . . . . . . . . . . . . 27 96 10.4. Implicit Authorization . . . . . . . . . . . . . . . . . 27 98 11. Security Considerations . . . . . . . . . . . . . . . . . . . 28 99 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 100 12.1. dcaf+cbor Media Type Registration . . . . . . . . . . . 29 101 12.2. CoAP Content Format Registration . . . . . . . . . . . . 30 102 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 30 103 13.1. Normative References . . . . . . . . . . . . . . . . . . 30 104 13.2. Informative References . . . . . . . . . . . . . . . . . 31 105 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31 107 1. Introduction 109 The Constrained Application Protocol (CoAP) [I-D.ietf-core-coap] is a 110 transfer protocol similar to HTTP which is designed for the special 111 requirements of constrained environments. A serious problem with 112 constrained devices is the realization of secure communication. The 113 devices only have limited resources such as memory, stable storage 114 (such as disk space) and transmission capacity and often lack input/ 115 output devices such as keyboards or displays. Therefore, they are 116 not readily capable of using common protocols. Especially 117 authentication mechanisms are difficult to realize, because the lack 118 of stable storage severely limits the number of keys the system can 119 store. Moreover, CoAP has no mechanism to distinguish access rights 120 for different clients (authorization). 122 The DCAF architecture is designed to relieve the constrained nodes 123 from managing keys for numerous devices by introducing authorization 124 servers which conduct the authentication and authorization for their 125 nodes. To achieve this, access tokens are used. A device which 126 wants to access a constrained node's resource first has to gain 127 permission in the form of a token from the node's authorization 128 server. 130 As fine-grained authorization is not always needed on constrained 131 devices, DCAF supports an implicit authorization mode where no 132 authorization information is exchanged. 134 The main goals of DCAF are the setup of a Datagram Transport Layer 135 Security (DTLS) [RFC6347] channel with symmetric pre-shared keys 136 (PSK) [RFC4279] and to securely transmit authorization tickets. 138 1.1. Features 140 o Utilize DTLS communication with pre-shared keys. 142 o Authenticated exchange of authorization information. 144 o Simplified authentication on constrained nodes by handing the more 145 sophisticated authentication over to less-constrained devices. 147 o Simplified authorization mechanism for cases where implicit 148 authorization is sufficient. 150 o Using only symmetric encryption on constrained nodes. 152 1.2. Terminology 154 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 155 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 156 document are to be interpreted as described in RFC 2119 [RFC2119]. 158 1.2.1. Roles 160 Resource Server (RS): A constrained device that hosts resources the 161 Client wants to access. 163 Client (C): A device that wants to access resources on the Resource 164 Server. 166 Authorization Server (AS): The node that conducts authentication and 167 authorization for a Resource Server. An Authorization Server can be 168 responsible for a single or multiple devices or even for a whole 169 network. A Resource Server can have multiple Authorization Servers. 171 Authentication Manager (AM): The node that conducts authentication on 172 behalf of the Client. 174 Resource Owner: The principal that owns the resource and controls its 175 access permissions. 177 1.2.2. Other Terms 179 Access ticket: Contains the authentication and, if necessary, the 180 authorization information needed to access a resource. A Ticket 181 consists of the Ticket Face and the Ticket Verifier 183 Authorization information: Contains all information needed by RS to 184 decide if C is privileged to access a resource in a specific way. 186 Authentication information: Contains all information needed by RS to 187 decide if the entity in possession of a certain key is verified by 188 the authorization server. 190 Access information: Contains authentication information and, if 191 necessary, authorization information. 193 Ticket Face: The part of the ticket which is generated for the 194 Resource Server. It contains the authorization information and all 195 information needed by the Resource Server to verify that it was 196 granted by AS. 198 Ticket Verifier: The part of the ticket which is generated for the 199 Client. It enables the client to verify that it is communicating 200 with an appropriate RS. 202 Explicit authorization: The Authorization Server informs the Resource 203 Server in detail which privileges are granted to the Client. 205 Implicit authorization: The Authorization Server informs the Resource 206 Server that the Client is authorized to access any resource on RS in 207 any way, without specifying the privileges in detail. 209 2. System Overview 211 Within the DCAF Architecture each Resource Server (RS) has one or 212 more Authorization Servers (AS) which conduct the authentication and 213 authorization for RS. RS and AS share a symmetric key which has to 214 be exchanged initially to provide for a secure channel. The 215 mechanism used for this is not in the scope of this document. 217 To gain access to a specific resource on a Resource Server, a client 218 (C) has to request an access ticket from one of the Authorization 219 Servers serving RS either directly or, if it is a constrained device, 220 using its Authentication Manager (AM). In the following, we always 221 discuss the AM role separately, even if that is co-located within a 222 (more powerful) C. 224 If AS decides that C is allowed to access the resource, it generates 225 a DTLS pre-shared key (PSK) for the communication between C and RS 226 and wraps it into an access ticket. For explicit access control, AS 227 adds the detailed access permissions to the ticket in a way that RS 228 can interpret. After presenting the ticket to RS, C and RS can 229 communicate securely. 231 To be able to provide for the authentication and authorization 232 services, the Authorization Servers have to fulfill several 233 requirements: 235 o An AS must have enough stable storage (such as disk space) to 236 store the necessary number of credentials (matching the number of 237 clients and Resource Servers). 239 o An AS must possess means for user interaction, for example 240 directly or indirectly connected input/output devices like 241 keyboard and display, to allow for configuration of authorization 242 information by the Resource Owner. 244 o An AS must have enough processing power to handle the 245 authorization requests for all RS devices it is responsible for. 247 3. Protocol 249 The DCAF protocol comprises three parts: 251 1. transfer of authentication and, if necessary, authorization 252 information between C and RS; 254 2. transfer of access requests and the respective ticket grants 255 between C and AM; and 257 3. transfer of access requests and the respective ticket grants 258 between AS and AM. 260 3.1. Overview 262 In Figure 1, a DCAF protocol flow is depicted (messages in square 263 brackets are optional): 265 AM C RS AS 266 | <== DTLS chan. ==> | | <== DTLS chan. ==> | 267 | | [Resource Req.-->] | | 268 | | | | 269 | | [<-- AS Info.] | | 270 | | | | 271 | <-- Access Req. | | | 272 | | | | 273 | <===== TLS/DTLS channel (AM/AS Mutual Authentication) =====> | 274 | | | | 275 | Ticket Request ------------------------------------------> | 276 | | | | 277 | <------------------------------------------ Ticket Grant | 278 | | | | 279 | Ticket Transm. --> | | | 280 | | | | 281 | | <== DTLS chan. ==> | | 282 | | Auth. Res. Req. -> | | 284 Figure 1: Protocol Overview 286 To determine the Authorization Server in charge of a resource hosted 287 at the Resource Server (RS), the Client (C) MAY send an initial 288 Unauthorized Resource Request message to RS. RS then denies the 289 request and sends the address of its Authorization Server (AS) back 290 to the Client. 292 Instead of the initial Unauthorized Resource Request message, C MAY 293 look up the desired resource in a resource directory (cf. 294 [I-D.ietf-core-resource-directory]) that lists RS's resources as 295 discussed in Section 9. 297 Once C knows AS' address, it can send a request for authorization to 298 AS using its own Authentication Manager (AM). AS authenticates AM, 299 who serves as a trusted introducer for C, and decides if C is allowed 300 to communicate with RS and access the requested resource. If it is, 301 AS generates an access ticket for C. The ticket contains keying 302 material for the establishment of a secure channel and, if necessary, 303 a representation of the permissions C has for the resource. C keeps 304 one part of the access ticket and presents the other part to RS to 305 prove its right to access. With their respective parts of the 306 ticket, C and RS are able to establish a secure channel. 308 The following sections specify how CoAP is used to interchange 309 access-related data between RS and AS so that AS can provide C and RS 310 with sufficient information to establish a secure channel, and 311 simultaneously convey authorization information specific for this 312 communication relationship to RS. 314 This document uses Concise Binary Object Representation (CBOR, 315 [RFC7049]) to express authorization information as set of attributes 316 passed in CoAP payloads. Notation and encoding options are discussed 317 in Section 5. 319 3.2. Unauthorized Resource Request Message 321 The optional Unauthorized Resource Request message is a request for a 322 resource hosted by RS for which no proper authorization is granted. 323 RS MUST treat any CoAP request as Unauthorized Resource Request 324 message when any of the following holds: 326 o The request has been received on an insecure channel. 328 o RS has no valid access information for the sender of the request 329 regarding the requested action on that resource. 331 o RS has valid access information for the sender of the request, but 332 this does not allow the requested action on the requested 333 resource. 335 Note: These conditions ensure that RS can handle requests 336 autonomously once access was granted and a secure channel has been 337 established between C and RS. 339 Unauthorized Resource Request messages MUST be denied with a client 340 error response. In this response, the Resource Server MUST provide 341 proper AS Information to enable the Client to request an access 342 ticket from RS's Authorization Server as described in Section 3.3. 344 The response code MUST be 4.01 (Unauthorized) in case the sender of 345 the Unauthorized Resource Request message is not authenticated, or if 346 RS has no valid access ticket for C. If RS has authorization 347 information for C but not for the resource that C has requested, RS 348 MUST reject the request with a 4.03 (Forbidden). If RS has 349 authorization information for C but they do not cover the action C 350 requested on the resource, RS MUST reject the request with a 4.05 351 (Method Not Allowed). 353 Note: The use of the response codes 4.03 and 4.05 is intended to 354 prevent infinite loops where a dumb Client optimistically tries to 355 access a requested resource with any access token received from 356 the AS. As malicious clients could pretend to be C to determine 357 C's privileges, these detailed response codes must be used only 358 when a certain level of security is already available which can be 359 achieved only when the Client is authenticated. 361 3.3. AS Information Message 363 The AS Information Message is sent by RS as a response to an 364 Unauthorized Resource Request message (see Section 3.2) to point the 365 sender of the Unauthorized Resource Request message to RS's 366 Authorization Server. The AS information is a set of attributes 367 containing an absolute URI (see Section 4.3 of [RFC3986]) that 368 specifies the Authorization Server in charge of RS. 370 The message MAY also contain a timestamp generated by RS. 372 Figure 2 shows an example for an AS Information message payload using 373 CBOR diagnostic notation. (Refer to Section 5 for a detailed 374 description of the available attributes and their semantics.) 376 4.01 Unauthorized 377 Content-Format: application/dcaf+cbor 378 {"AS": "coaps://as-rs.example.com/authorize", "TS": 168537} 380 Figure 2: AS Information Payload Example 382 In this example, the attribute AS points the receiver of this message 383 to the URI "coaps://as-rs.example.com/authorize" to request access 384 permissions. The originator of the AS Information payload (i.e. RS) 385 uses a local clock that is loosely synchronized with a time scale 386 common between RS and AS (e.g., wall clock time). Therefore, it has 387 included a time stamp on its own time scale that is used as a nonce 388 for replay attack prevention. Refer to Section 4.1 for more details 389 concerning the usage of time stamps to ensure freshness of access 390 tickets. 392 The examples in this document are written in CBOR diagnostic notation 393 to improve readability. Figure 3 illustrates the binary encoding of 394 the message payload shown in Figure 2. 396 a2 # map(2) 397 62 # text(2) 398 4153 # "AS" 399 78 23 # text(35) 400 636f6170733a2f2f61732d72732e6578 401 616d706c652e636f6d2f617574686f72 402 697a65 # "coaps://as-rs.example.com/authorize" 403 62 # text(2) 404 5453 # "TS" 405 1a 00029259 # unsigned(168537) 407 Figure 3: AS Information Payload Example encoded in CBOR 409 3.4. Access Request 411 To retrieve an access ticket for the resource that C wants to access, 412 C sends an Access Request to its authentication manager AM. The 413 Access Request is constructed as follows: 415 1. The request method is POST. 417 2. The request URI is set as described below. 419 3. The message payload contains a data structure that describes the 420 action and resource for which C requests an access ticket. 422 The request URI identifies a resource at AM for handling 423 authorization requests from C. The URI SHOULD be announced by AM in 424 its resource directory as described in Section 9. 426 Note: Where capacity limitations of C do not allow for resource 427 directory lookups, the request URI in Access Requests could be 428 hard-coded during provisioning or set in a specific device 429 configuration profile. 431 The message payload is constructed from the AS information that RS 432 has returned in its AS Information message (see Section 3.3) and 433 information that C provides to describe its intended request(s). The 434 Access Request MUST contain the following attributes: 436 1. Contact information for the AS to use. 438 2. An absolute URI of the resource that C wants to access. 440 3. The actions that C wants to perform on the resource. 442 4. Any time stamp generated by RS. 444 An example Access Request from C to AM is depicted in Figure 4. 445 (Refer to Section 5 for a detailed description of the available 446 attributes and their semantics.) 448 POST client-authorize 449 Content-Format: application/dcaf+cbor 450 { 451 "AS": "coaps://as-rs.example.com/authorize", 452 "AI": ["coaps://temp451.example.com/s/tempC", 5], 453 "TS": 168537 454 } 456 Figure 4: Access Request Message Example 458 The example shows an Access Request message payload for the resource 459 "/s/tempC" on the Resource Server "temp451.example.com". Requested 460 operations in attribute AR are GET and PUT. 462 The attributes AS (that denotes the Authorization Server to use) and 463 TS (a nonce generated by RS) are taken from the AS Information 464 message from RS. 466 The response to an Authorization Request is delivered by AM back to C 467 in a Ticket Transfer message. 469 3.5. Ticket Request Message 471 When AM receives an Access Request message from C it MAY return a 472 cached response if it is known to be fresh. Otherwise, it checks 473 whether the request payload is of type "application/dcaf+cbor and 474 contains at least the fields AS and AI. AM MUST respond with 4.00 475 (Bad Request) if the type is "application/dcaf+cbor and any of these 476 fields is missing or does not conform to the format described in 477 Section 5. Content formats other than application/dcaf+cbor are out 478 of scope of this specification. 480 When the payload is correct, AM creates a Ticket Request message from 481 the Access Request received from C as follows: 483 1. The destination of the Ticket Request message is derived from the 484 authority information in the URI contained in field "AS" of the 485 Access Request message payload. 487 2. The request method is POST. 489 3. The request URI is constructed from the AS field received in the 490 Access Request message payload. 492 4. The payload is copied from the Access Request sent by C. 494 5. A label that describes the Client is added to the payload 496 To send the Ticket Request message to AS a secure channel between AM 497 and AS MUST be used. Depending on the URI scheme used in the AS 498 field of the Access Request message payload (the less-constrained 499 devices AM and AS do not necessarily use coap to communicate with 500 each other), this could be, e.g., a DTLS channel (for "coaps") or a 501 TLS connection (for "https"). AM and AS MUST be able to mutually 502 authenticate each other, e.g. based on a public key infrastructure. 503 (Refer to Section 8 for a detailed discussion of the trust 504 relationship between authentication managers and authorization 505 servers.) 507 The descriptive label of C included in the Ticket Request is used to 508 distinguish the clients within AS's namespace and MUST NOT be used 509 for authenticating the client. 511 3.6. Ticket Grant Message 513 When AS has received a Ticket Request message it has to evaluate the 514 access request information contained therein. First, it checks 515 whether the request payload is of type "application/dcaf+cbor" and 516 contains at least the fields AS, D, and AI. AS MUST respond with 517 4.00 (Bad Request) for CoAP (or 400 for HTTP) if the type is 518 "application/dcaf+cbor" and any of these fields is missing or does 519 not conform to the format described in Section 5. 521 AS decides whether or not access is granted to the requested resource 522 and then creates a Ticket Grant message that reflects the result. To 523 grant access to the requested resource, AS creates an access ticket 524 comprised of a Face and a Verifier as described in Section 4.1. 526 The Ticket Grant message then is constructed as a success response 527 indicating attached content, i.e. 2.05 for CoAP, or 200 for HTTP, 528 respectively. The payload of the Ticket Grant message is a data 529 structure that contains the result of the access request. When 530 access is granted, the data structure contains the ticket's Face, the 531 Verifier and the Session Key Generation Method. 533 The Ticket Grant message MAY provide cache-control options to enable 534 intermediaries to cache the response. The message MAY be cached 535 according to the rules defined in [I-D.ietf-core-coap] to facilitate 536 ticket retrieval when C has crashed and wants to recover the DTLS 537 session with RS. 539 AS sets Max-Age according to the ticket lifetime in its response 540 (Ticket Grant Message). 542 Figure 5 shows an example Ticket Grant message using CoAP. The Face/ 543 Verifier information is transferred as a CBOR data structure as 544 specified in Section 5. The Max-Age option tells the receiving AM 545 how long this ticket will be valid. 547 2.05 Content 548 Content-Format: application/dcaf+cbor 549 Max-Age: 86400 550 { "F": { 551 "AI": [ "/s/tempC", 7 ], 552 "D": "2001:db8:ab9:1234:7920:3133:ae5f:87", 553 "TS": 0("2013-07-10T10:04:12.391"), 554 "L": 86400, 555 "G": "hmac_sha256" 556 }, 557 "V": h'b2dd4e409c2d36a7423da3c87e571999 558 0b778ebd2c7d3730729a7fcde26c7201' 559 } 561 Figure 5: Example Ticket Grant Message 563 A Ticket Grant message that declines any operation on the requested 564 resource is illustrated in Figure 6. As no ticket needs to be 565 issued, an empty payload is included with the response. 567 2.05 Content 568 Content-Format: application/dcaf+cbor 570 Figure 6: Example Ticket Grant Message With Reject 572 3.7. Ticket Transfer Message 573 A Ticket Transfer message delivers the access information sent by AS 574 in a Ticket Grant message to the requesting client C. The Ticket 575 Transfer message is the response to the Access Request message sent 576 from C to AM and includes any access information from AS contained in 577 the Ticket Grant message. 579 3.8. DTLS Channel Setup Between C and RS 581 Using the information contained in a positive response to its Access 582 Request (i.e. a Ticket Transfer message that contains a Face and a 583 Verifier), C can initiate establishment of a new DTLS channel with 584 RS. To use DTLS with pre-shared keys, C follows the PSK key exchange 585 algorithm specified in Section 2 of [RFC4279], with the following 586 additional requirements: 588 1. C sets the psk_identity field of the ClientKeyExchange message to 589 the ticket Face received in the Ticket Transfer message. 591 2. C uses the ticket Verifier as PSK when constructing the premaster 592 secret. 594 Note1: As RS cannot provide C with a meaningful PSK identity hint in 595 response to C's ClientHello message, RS SHOULD NOT send a 596 ServerKeyExchange message. 598 Note2: According to [I-D.ietf-core-coap], CoAP implementations MUST 599 support the ciphersuite TLS_PSK_WITH_AES_128_CCM_8 [RFC6655]. C is 600 therefore expected to offer at least this ciphersuite to RS. 602 Note3: The ticket is constructed by AS such that RS can derive the 603 authorization information as well as the PSK (refer to Section 6 for 604 details). 606 3.9. Authorized Resource Request Message 608 Successful establishment of the DTLS channel between C and RS ties 609 the authorization information contained in the psk_identity field to 610 this channel. Any request that RS receives on this channel is 611 checked against these authorization rules. Incoming CoAP requests 612 that are not Authorized Resource Requests MUST be rejected by RS with 613 4.01 response as described in Section 3.2. 615 RS SHOULD treat an incoming CoAP request as Authorized Resource 616 Request if the following holds: 618 1. The message was received on a secure channel that has been 619 established using the procedure defined in Section 3.8. 621 2. The authorization information tied to the secure channel is 622 valid. 624 3. The request is destined for RS. 626 4. The resource URI specified in the request is covered by the 627 authorization information. 629 5. The request method is an authorized action on the resource with 630 respect to the authorization information. 632 Note that the authorization information is not restricted to a single 633 resource URI. For example, role-based authorization can be used to 634 authorize a collection of semantically connected resources 635 simultaneously. Implicit authorization also provides access rights 636 to authenticated clients for all actions on all resources that RS 637 offers. As a result, C can use the same DTLS channel not only for 638 subsequent requests for the same resource (e.g. for block-wise 639 transfer as defined in [I-D.ietf-core-block] or refreshing observe- 640 relationships [I-D.ietf-core-observe]) but also for requests to 641 distinct resources. 643 Incoming CoAP requests received on a secure channel according to the 644 procedure defined in Section 3.8 MUST be rejected 646 1. with response code 4.03 (Forbidden) when the resource URI 647 specified in the request is not covered by the authorization 648 information, and 650 2. with response code 4.05 (Method Not Allowed) when the resource 651 URI specified in the request covered by the authorization 652 information but not the requested action. 654 Since AS may limit the set of requested actions in its Ticket Grant 655 message, C cannot know a priori if a an Authorized Resource Request 656 will succeed. 658 3.10. Dynamic Update of Authorization Information 660 Once a security association exists between a Client and a Resource 661 Server, the Client can update the Authorization Information stored at 662 the Resource Server at any time. To do so, the Client creates a new 663 Access Request for the intended action on the respective resource and 664 sends this request to its Authentication Manager which relays this 665 request to the Resource Server's Authorization Server as described in 666 Section 3.4. 668 Note: Requesting a new Access Ticket also can be a Client's reaction 669 on a 4.03 or 4.05 error that it has received in response to an 670 Authorized Resource Request. 672 Figure 7 depicts the message flow where C requests a new Access 673 Tickets after a security association between C and RS has been 674 established using this protocol. 676 AM C RS AS 677 | <== DTLS chan. ==> | <== DTLS chan. ==> | <== DTLS chan. ==> | 678 | | | | 679 | | [Unauth. R. Req->] | | 680 | | [<- 4.0x+AS Info.] | | 681 | | | | 682 | <-- Access Req. | | | 683 | | | | 684 | <===== TLS/DTLS channel (AM/AS Mutual Authentication) =====> | 685 | | | | 686 | Ticket Request ------------------------------------------> | 687 | | | | 688 | <------------------------------------------ Ticket Grant | 689 | | | | 690 | Ticket Transf. --> | | | 691 | | | | 692 | | <== Update AI ===> | | 694 Figure 7: Overview of Dynamic Update Operation 696 Processing the Ticket Request is done at the Authorization Server as 697 specified in Section 3.6, i.e. the AS checks whether or not the 698 requested operation is permitted by the Resource Owner's policy, and 699 then return a Ticket Grant message with the result of this check. If 700 access is granted, the Ticket Grant message contains an Access Ticket 701 comprised of a public Ticket Face and a private Ticket Verifier. 702 This authorization payload is relayed by the Authorization Manager to 703 the Client in a Ticket Transfer Message as defined in Section 3.7. 705 The major difference between dynamic update of Authorization 706 Information and the initial handshake is the handling of a Ticket 707 Transfer message by the Client that is described in Section 3.10.1. 709 3.10.1. Handling of Ticket Transfer Messages 711 If the security association with RS still exists and RS has indicated 712 support for session renegotiation according to [RFC5746], the ticket 713 Face SHOULD be used to renegotiate the existing DTLS session. In 714 this case, the ticket Face is used as psk_identity as defined in 715 Section 3.8. Otherwise, the Client MUST perform a new DTLS handshake 716 according to Section 3.8 that replaces the existing DTLS session. 718 After successful completion of the DTLS handshake RS updates the 719 existing Authorization Information for C according to the contents of 720 the ticket Face. 722 Note: No mutual authentication between C and RS is required for 723 dynamic updates when a DTLS channel exists that has been 724 established as defined in Section 3.8. RS only needs to verify 725 the authenticity and integrity of the ticket Face issued by AS 726 which is achieved by having performed a successful DTLS handshake 727 with the ticket Face as psk_identity. This could even be done 728 within the existing DTLS session by tunneling a CoDTLS 729 [I-D.schmertmann-dice-codtls] handshake. 731 4. Ticket 733 Access tokens in DCAF are tickets that consist of two parts, namely 734 the Face and the Verifier. The Face goes to RS, the Verifier goes to 735 the Client. The Face and the Verifier are parts of the same ticket. 737 RS only needs the information contained in the Ticket Face to 738 authorize the client and make sure that AS generated the Ticket Face 739 (RS cannot make authorization decisions by itself and hence needs AS 740 to do it). No additional information about the Client is needed. RS 741 keeps the Ticket Face as long as it is valid. 743 4.1. Face 745 Face is the part of the ticket generated for RS. Face MUST contain 746 all information needed for authorized access to a resource: 748 o Authorization Information 750 o Descriptive label 752 o A timestamp generated by AS 754 Optionally, Face MAY also contain: 756 o A lifetime (optional) 758 o A DTLS pre-shared key (optional) 760 RS MUST verify the integrity of Face, i.e. the information contained 761 in Face stems from AS and was not manipulated by anyone else. 763 Face MUST contain a timestamp to verify that the contained 764 information is fresh. As constrained devices may not have a clock, 765 timestamps MAY be generated using the clock ticks since the last 766 reboot. To circumvent synchronization problems the timestamp MAY be 767 generated by RS and included in the first AS Information message. 768 Alternatively, AS MAY generate the timestamp. In this case, AS and 769 RS MUST use a time synchronization mechanism to make sure that RS 770 interprets the timestamp correctly. 772 Face MAY be encrypted. If Face contains a DTLS PSK, the whole 773 content of Face MUST be encrypted. 775 Note: The integrity of Face can be ensured by various means. Face 776 may be encrypted by AS with a key it shares with RS. Alternatively, 777 RS can use a mechanism to generate the DTLS PSK which includes Face 778 and is only able to calculate the correct key with the correct Face 779 (refer to Section 6 for details). 781 4.2. Verifier 783 The Verifier part of the ticket is generated for C. It contains the 784 DTLS PSK for C. The Verifier MUST NOT be transmitted over insecure 785 channels. 787 4.3. Revocation 789 The existence of access tickets SHOULD be limited in time. This can 790 be achieved either by explicit Revocation Messages to invalidate a 791 ticket or implicitly by attaching a lifetime to the ticket. 793 4.3.1. Lifetime 795 Tickets MAY have a lifetime. AS is responsible for defining the 796 ticket lifetime. If AS sets a lifetime for a ticket, AS and RS MUST 797 use a time synchronization method to ensure that RS is able to 798 interpret the lifetime correctly. RS SHOULD end the DTLS connection 799 to C if the lifetime of a ticket has run out and it MUST NOT accept 800 new requests. RS MUST NOT accept tickets with an invalid lifetime. 802 Note: Defining reasonable ticket lifetimes is difficult to 803 accomplish. How long a client needs to access a resource depends 804 heavily on the application scenario and may be difficult to decide 805 for AS. 807 4.3.2. Revocation Messages 808 AS MAY revoke tickets by sending a ticket revocation message to RS. 809 If RS receives a ticket revocation message, it MUST end the DTLS 810 connection to C and MUST NOT accept any further requests from C. 812 If ticket revocation messages are used, RS MUST check regularly if AS 813 is still available. If RS cannot contact AS, it MUST end all DTLS 814 connections and reject any further requests from C. 816 Note: The loss of the connection between RS and AS prevents all 817 access to RS. This might especially be a severe problem if AS is 818 responsible for several Resource Servers or even a whole network. 820 5. Payload Format and Encoding (application/dcaf+cbor) 822 Various messages types of the DCAF protocol carry payloads to express 823 authorization information and parameters for generating the DTLS PSK 824 to be used by C and RS. In this section, a representation in Concise 825 Binary Object Representation (CBOR, [RFC7049]) is defined. 827 DCAF data structures are defined as CBOR maps that contain key value 828 pairs. The following list describes the semantics of the keys 829 defined in DCAF: 831 AS: Authorization Server. This attribute denotes the authorization 832 server that is in charge of the resource specified in attribute R. 833 The attribute's value is a string that contains an absolute URI 834 according to Section 4.3 of [RFC3986]. 836 AI: Authorization Information. A data structure used to convey 837 authorization information from AS to RS and to describe the 838 permissions requested from AS in a Ticket Request. The AI 839 attribute contains an AIF object as defined in 840 [I-D.bormann-core-ace-aif]. 842 D: Description. A descriptive label of the initiator of the 843 authorization request. This label MAY be a fully qualified domain 844 name, an IP address, or any other character literal that is used 845 by the Authorization Server to decide whether or not access is 846 granted to the requesting entity. 848 E: Encrypted Ticket Face. A binary string containing an encrypted 849 ticket Face. 851 K: Key. A string that identifies the shared key between RS and AS 852 that can be used to decrypt the contents of E. If the attribute E 853 is present and no attribute K has been specified, the default is 854 to use the current session key for the secured channel between RS 855 and AS. 857 TS: Time Stamp. An optional time stamp that indicates the instant 858 when the access ticket request was formed. This attribute can be 859 used by the resource server in an AS Information message to convey 860 a time stamp in its local time scale (e.g. when it does not have a 861 real time clock with synchronized global time). When the 862 attribute's value is encoded as a string, it MUST contain a valid 863 UTC timestamp without time zone information. When encoded as 864 integer, TS contains a system timestamp relative to the local time 865 scale of its generator, usually RS. 867 L: Lifetime. A lifetime of the ticket. When encoded as a string, L 868 MUST denote the ticket's expiry time as a valid UTC timestamp 869 without time zone information. When encoded as an integer, L MUST 870 denote the ticket's validity period in seconds relative to TS. 872 G: DTLS PSK Generation Method. A string that identifies the method 873 that RS MUST use to derive the DTLS PSK from the ticket Face. 874 This attribute MUST NOT be used when attribute V is present within 875 the contents of F. 877 F: Ticket Face. An object containing the fields AI, D, TS, and 878 optionally G, L and V. 880 V: Ticket Verifier. A binary string containing the shared secret 881 between C and RS. 883 5.1. Examples 885 The following example specifies an Authorization Server that will be 886 accessed using HTTP over TLS. The request URI is set to "/ 887 a?ep=%5B2001:DB8::dcaf:1234%5D" (hence denoting the endpoint address 888 to authorize). TS denotes a local timestamp in UTC. 890 POST /a?ep=%5B2001:DB8::dcaf:1234%5D HTTP/1.1 891 Host: as-rs.example.com 892 Content-Type: application/dcaf+cbor 893 {"AS": "https://as-rs.example.com/a?ep=%5B2001:DB8::dcaf:1234%5D", 894 "D": "2001:DB8::dcaf:1234", 895 "AI": ["coaps://temp451.example.com/s/tempC", 1], 896 "TS": 0("2013-07-14T11:58:22.923")} 898 The following example shows a ticket for the distributed key 899 generation method (cf. Section 6.2), comprised of a Face (F) and a 900 Verifier (V). The Face data structure contains authorization 901 information AI, a client descriptor, a timestamp using the local time 902 scale of RS, and a lifetime relative to RS's time scale. 904 The DTLS PSK Generation Method is set to "hmac_sha256" denoting that 905 the distributed key derivation is used as defined in Section 6.2 with 906 SHA-256 as HMAC function. 908 The Verifier V contains a shared secret to be used as DTLS PSK 909 between C and RS. 911 HTTP/1.1 200 OK 912 Content-Type: application/dcaf+cbor 913 { 914 "F": { 915 "AI": [ "/s/tempC", 1 ], 916 "D": "2001:db8:ab9:1234:7920:3133:ae5f:87", 917 "TS": 2938749, 918 "L": 3600, 919 "G": "hmac_sha256" 920 }, 921 "V": h'93b9448d4380304d5a574fc50b944958 922 55bbd5ba1422cc09fde61665aa519cf9' 923 } 925 The Face may be encrypted as illustrated in the following example. 926 Here, the field E carries an encrypted Face data structure that 927 contains the same information as the previous example, and an 928 additional Verifier. Encryption was done with a secret shared by AS 929 and RS. (This example uses AES128_CCM with the secret { 0x00, 0x01, 930 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08, 0x09, 0x0a, 0x0b, 0x0c, 931 0x0d, 0x0e, 0x0f } and RS's timestamp { 0x00, 0x2C, 0xD7, 0x7D } as 932 nonce.) Line breaks have been inserted to improve readability. 934 The attribute K describes the identity of the key to be used by RS to 935 decrypt the contents of attribute E. Here, The value "key0" in this 936 example is used to indicate that the shared session key between RS 937 and AS was used for encrypting E. 939 { 940 "E": h'2e1c0c0ae1915711f1073f34e44bfc81 941 db12167f5bdbd8801d07686615b0b434 942 cdca7a5453d0d582565e2f236948235d 943 d353cef1114d64d138949f7ab01b92f0 944 b6f2caccce3a43cb0a32f270a82cde0a 945 98250e6ac2b79a26fb47c09ef4cb366f 946 1aa38017cd8b891a6d796fa684294a60 947 64f3665527c5890b65a33af73a5c66ef 948 66cbb9e28ea30c89' 949 ', 950 "K": "key0", 951 "V": h'93b9448d4380304d5a574fc50b944958 952 55bbd5ba1422cc09fde61665aa519cf9' 953 } 955 The decrypted contents of E are depicted below (whitespace has been 956 added to improve readability). The presence of the attribute V 957 indicates that the DTLS PSK Transfer is used to convey the session 958 key (cf. Section 6.1). 960 { 961 "F": { 962 "AI": [ "/s/tempC", 1 ], 963 "D": "2001:db8:ab9:1234:7920:3133:ae5f:87", 964 "TS": 2938749, 965 "L": 3600, 966 "G": "hmac_sha256" 967 }, 968 "V": h'93b9448d4380304d5a574fc50b944958 969 55bbd5ba1422cc09fde61665aa519cf9' 970 } 972 6. DTLS PSK Generation Methods 974 One goal of the DCAF protocol is to provide for a DTLS PSK shared 975 between C and RS. AS and RS MUST negotiate the method for the DTLS 976 PSK generation. 978 6.1. DTLS PSK Transfer 980 The DTLS PSK is generated by AS and transmitted to C and RS using a 981 secure channel. 983 The DTLS PSK transfer method is defined as follows: 985 o AS generates the DTLS PSK using an algorithm of its choice 987 o AS MUST include a representation of the DTLS PSK in Face and 988 encrypt it together with all other information in Face with a key 989 K(AS,RS) it shares with RS. How AS and RS exchange K(AS,RS) is 990 not in the scope of this document. AS and RS MAY use their 991 preshared key as K(AS,RS). 993 o AS MUST include a representation of the DTLS PSK in the Verifier. 995 o As AS and C do not have a shared secret, the Verifier MUST be 996 transmitted to C using encrypted channels. 998 o RS MUST decrypt Face using K(AS,RS) 1000 6.2. Distributed Key Derivation 1002 AS generates a DTLS PSK for C which is transmitted using a secure 1003 channel. RS generates its own version of the DTLS PSK using the 1004 information contained in Face (see also Section 4.1). 1006 The distributed key derivation method is defined as follows: 1008 o AS and RS both generate the DTLS PSK using the information. 1009 included in Face. They use an HMAC algorithm on Face with a 1010 shared key. The result serves as the DTLS PSK. How AS and RS 1011 negotiate the used HMAC algorithm is not in the scope of this 1012 document. They MAY however use the HMAC algorithm they use for 1013 their DTLS connection. 1015 o AS MUST include a representation of the DTLS PSK in the Verifier. 1017 o As AS and C do not have a shared secret, the Verifier MUST be 1018 transmitted to C using encrypted channels. 1020 o AS MUST NOT include a representation of the DTLS PSK in Face. 1022 o AS MUST NOT encrypt Face. 1024 7. Authorization Configuration 1026 For the protocol defined in this document, proper configuration of AS 1027 is crucial. The principal who owns the resources hosted by RS (i.e. 1028 the Resource Owner) needs to define permissions for the resources. 1029 The data representation of these permissions are not in the scope of 1030 this document. 1032 8. Trust Relationships 1034 C trusts AM, and RS trusts AS. Obviously, AM trusts C with the 1035 specific permissions it hands over to it. How this trust is 1036 established, is not in the scope of this document. It may be 1037 achieved by using a bootstrapping mechanism similar to [bergmann12]. 1039 Additionally, AS and AM need to have a trust relationship 1040 established. Its establishment is also not in the scope of this 1041 document. It fulfills the following conditions: 1043 1. AS has means to authenticate AM (e.g. it has a certificate of AM 1044 or a PKI in which AM is included) and vice versa 1046 2. As far as AS needs to rely on the different clients of AM to 1047 receive different permissions, it can be sure that AM correctly 1048 identifies these clients towards AS and does not leak tickets 1049 that have been generated for a specific client C to another 1050 client. 1052 AS trusts C indirectly because it trusts AM and AM vouches for C. The 1053 DCAF Protocol does not provide any means for AS to validate that a 1054 resource requests stems from C. 1056 C indirectly trusts AS with some potentially confidential 1057 information, and that AS correctly represents RS, because AM trusts 1058 AS. 1060 AM trusts RS indirectly because it trusts AS and AS vouches for RS. 1062 C implicitly trusts RS with some potentially confidential information 1063 because it trusts AM and because RS can prove that it shares a key 1064 with AS. 1066 AM <--------------------> AS 1068 /|\ /|\ 1069 | | 1070 \|/ \|/ 1072 C ..................... RS 1074 9. Listing Authorization Server Information in a Resource Directory 1076 CoAP utilizes the Web Linking format [RFC5988] to facilitate 1077 discovery of services in an M2M environment. [RFC6690] defines 1078 specific link parameters that can be used to describe resources to be 1079 listed in a resource directory [I-D.ietf-core-resource-directory]. 1081 9.1. The "auth-request" Link Relation 1083 This section defines a resource type "auth-request" that can be used 1084 by clients to retrieve the request URI for a server's authorization 1085 service. When used with the parameter rt in a web link, "auth- 1086 request" indicates that the corresponding target URI can be used in a 1087 POST message to request authorization for the resource and action 1088 that are described in the request payload. 1090 The Content-Format "application/dcaf+cbor with numeric identifier 1091 TBD1 defined in this specification MAY be used to express access 1092 requests and their responses. 1094 The following example shows the web link used by AM in this document 1095 to relay incoming Authorization Request messages to AS. (Whitespace 1096 is included only for readability.) 1098 ;rt="auth-request";ct=TBD1 1099 ;title="Contact Remote Authorization Server" 1101 The resource directory that hosts the resource descriptions of RS 1102 could list the following description. In this example, the URI "ep/ 1103 node138/a/switch2941" is relative to the resource context "coaps 1104 ://as-rs.example.com/", i.e. the authorization server AS. 1106 ;rt="auth-request";ct=TBD1;ep="node138" 1107 ;title="Request Client Authorization" 1108 ;anchor="coaps://as-rs.example.com/" 1110 10. Examples 1112 This section gives a number of short examples with message flows for 1113 the initial Unauthorized Resource Request and the subsequent 1114 retrieval of a ticket from AS. The notation here follows the role 1115 conventions defined in Section 1.2.1. The payload format is encoded 1116 as proposed in Section 5. The IP address of AS is 2001:DB8::1, the 1117 IP address of RS is 2001:DB8::dcaf:1234, and C's IP address is 1118 2001:DB8::c. 1120 10.1. Access Granted 1122 This example shows an Unauthorized PUT request from C to RS that is 1123 answered with an AS Information message. C then sends a POST request 1124 to AM with a description of its intended request. AM forwards this 1125 request to AS using CoAP over a DTLS-secured channel. The response 1126 from AS contains an access ticket that is relayed back to AM. 1128 C --> RS 1129 PUT a/switch2941 [Mid=1234] 1130 Content-Format: application/senml+json 1131 {e: [{"bv": "1"}]} 1133 C <-- RS 1134 4.01 Unauthorized [Mid=1234] 1135 Content-Format: application/dcaf+cbor 1136 {"AS": "coaps://[2001:DB8::1]/ep/node138/a/switch2941"} 1138 C --> AM 1139 POST client-authorize [Mid=1235,Token="tok"] 1140 Content-Format: application/dcaf+cbor 1141 { 1142 "AS": "coaps://[2001:DB8::1]/ep/node138/a/switch2941", 1143 "AI": ["coaps://[2001:DB8::dcaf:1234]/a/switch2941", 4] 1144 } 1146 AM --> AS [Mid=23146] 1147 POST ep/node138/a/switch2941 1148 Content-Format: application/dcaf+cbor 1149 { 1150 "AS": "coaps://[2001:DB8::1]/ep/node138/a/switch2941", 1151 "D": "2001:DB8::c", 1152 "AI": ["coaps://[2001:DB8::dcaf:1234]/a/switch2941", 4] 1153 } 1155 AM <-- AS 1156 2.05 Content [Mid=23146] 1157 Content-Format: application/dcaf+cbor 1158 { "F": { 1159 "AI": ["a/switch2941", 5], 1160 "D": "2001:DB8::c", 1161 "TS": 0("2013-07-04T20:17:38.002"), 1162 "G": "hmac_sha256" 1163 }, 1164 "V": h'50f18bf1d6f084eb0fd9d2ee6ec882d8 1165 a87ef66a332c86a45bff8f67fe19bc47' 1166 } 1168 C <-- AM 1169 2.05 Content [Mid=1235,Token="tok"] 1170 Content-Format: application/dcaf+cbor 1171 { "F": { 1172 "AI": ["a/switch2941", 5], 1173 "D": "2001:DB8::c", 1174 "TS": 0("2013-07-04T20:17:38.002"), 1175 "G": "hmac_sha256" 1176 }, 1177 "V": h'50f18bf1d6f084eb0fd9d2ee6ec882d8 1178 a87ef66a332c86a45bff8f67fe19bc47' 1179 } 1181 C --> RS 1182 ClientHello (TLS_PSK_WITH_AES_128_CCM_8) 1184 C <-- RS 1185 ServerHello (TLS_PSK_WITH_AES_128_CCM_8) 1186 ServerHelloDone 1188 C --> RS 1189 ClientKeyExchange 1190 psk_identity=0x6146a4624149826c612f737769746368 1191 0x323934310561446b323030313a444238 1192 0x3a3a63625453c077323031332d30372d 1193 0x30345432303a31373a33382e30303261 1194 0x476b686d61635f736861323536 1196 (C decodes the contents of V and uses the result as PSK) 1197 ChangeCipherSpec 1198 Finished 1200 (RS calculates PSK from AI, D, TS and its session key 1201 HMAC_sha256(0x6146a4624149826c612f737769746368 1202 0x323934310561446b323030313a444238 1203 0x3a3a63625453c077323031332d30372d 1204 0x30345432303a31373a33382e30303261 1205 0x476b686d61635f736861323536, 1206 0x66736563726574) 1207 = 0x0e70158e... 1208 ) 1210 C <-- RS 1211 ChangeCipherSpec 1212 Finished 1214 10.2. Access Denied 1216 This example shows a denied Authorization request for the DELETE 1217 operation. 1219 C --> RS 1220 DELETE a/switch2941 1222 C <-- RS 1223 4.01 Unauthorized 1224 Content-Format: application/dcaf+cbor 1225 {"AS": "coaps://[2001:DB8::1]/ep/node138/a/switch2941"} 1227 C --> AM 1228 POST client-authorize 1229 Content-Format: application/dcaf+cbor 1230 { 1231 "AS": "coaps://[2001:DB8::1]/ep/node138/a/switch2941", 1232 "AI": ["coaps://[2001:DB8::dcaf:1234]/a/switch2941", 8] 1233 } 1235 AM --> AS 1236 POST ep/node138/a/switch2941 1237 Content-Format: application/dcaf+cbor 1238 { 1239 "AS": "coaps://[2001:DB8::1]/ep/node138/a/switch2941", 1240 "D": "2001:DB8::c", 1241 "AI": ["coaps://[2001:DB8::dcaf:1234]/a/switch2941", 8] 1242 } 1244 AM <-- AS 1245 2.05 Content 1246 Content-Format: application/dcaf+cbor 1248 C <-- AM 1249 2.05 Content 1250 Content-Format: application/dcaf+cbor 1252 10.3. Access Restricted 1254 This example shows a denied Authorization request for the operations 1255 GET, PUT, and DELETE. AS grants access for PUT only. 1257 AM --> AS 1258 POST ep/node138/a/switch2941 1259 Content-Format: application/dcaf+cbor 1260 { 1261 "AS": "coaps://[2001:DB8::1]/ep/node138/a/switch2941", 1262 "D": "2001:DB8::c", 1263 "AI": ["coaps://[2001:DB8::dcaf:1234]/a/switch2941", 13] 1264 } 1266 AM <-- AS 1267 2.05 Content 1268 Content-Format: application/dcaf+cbor 1269 { "F": { 1270 "AI": ["a/switch2941", 5], 1271 "D": "2001:DB8::c", 1272 "TS": 0("2013-07-04T21:33:11.930"), 1273 "G": "hmac_sha256" 1274 }, 1275 "V": h'f5628265ec99349d2b1f3a1020223793 1276 7098512d555f085a775f1ae6a9c66950' 1277 } 1279 10.4. Implicit Authorization 1280 This example shows an Authorization request using implicit 1281 authorization. AM initially requests the actions GET and POST on the 1282 resource "coaps://[2001:DB8::dcaf:1234]/a/switch2941". AS returns a 1283 ticket that has no AI field in its ticket Face, hence implicitly 1284 authorizing C. 1286 AM --> AS 1287 POST ep/node138/a/switch2941 1288 Content-Format: application/dcaf+cbor 1289 { 1290 "AS": "coaps://[2001:DB8::1]/ep/node138/a/switch2941", 1291 "D": "2001:DB8::c", 1292 "AI": ["coaps://[2001:DB8::dcaf:1234]/a/switch2941", 3] 1293 } 1295 AM <-- AS 1296 2.05 Content 1297 Content-Format: application/dcaf+cbor 1298 { "F": { 1299 "D": "2001:DB8::c", 1300 "TS": 0("2013-07-16T10:15:43.663"), 1301 "G": "hmac_sha256" 1302 }, 1303 "V": h'6d30f6162b54cd50c8b7421674d46150 1304 1baba2a34c0a86a7aacc0cfe3c2f2643' 1305 } 1307 11. Security Considerations 1309 As this protocol builds on transitive trust between authorization 1310 servers as mentioned in Section 8, AS has no direct means to validate 1311 that a resource request originates from C. It has to trust AM that it 1312 correctly vouches for C and that it does not give authorization 1313 tickets meant for C to another client nor disclose the contained 1314 session key. 1316 The Authorization Server also could constitute a single point of 1317 failure. If the Authorization Server fails, the resources on all 1318 Resource Servers it is responsible for cannot be accessed any more. 1319 Thus, it is crucial for large networks to use Authorization Servers 1320 in a redundant setup. 1322 12. IANA Considerations 1324 The following registrations are done following the procedure 1325 specified in [RFC6838]. 1327 Note to RFC Editor: Please replace all occurrences of "[RFC-XXXX]" 1328 with the RFC number of this specification. 1330 12.1. dcaf+cbor Media Type Registration 1332 Type name: application 1334 Subtype name: dcaf+cbor 1336 Required parameters: none 1338 Optional parameters: none 1340 Encoding considerations: Must be encoded as using a subset of the 1341 encoding allowed in [RFC7049]. Specifically, only the primitive data 1342 types String and Number are allowed. The type Number is restricted 1343 to unsigned integers (i.e., no negative numbers, fractions or 1344 exponents are allowed). Encoding MUST be UTF-8. These restrictions 1345 simplify implementations on devices that have very limited memory 1346 capacity. 1348 Security considerations: TBD 1350 Interoperability considerations: TBD 1352 Published specification: [RFC-XXXX] 1354 Applications that use this media type: TBD 1356 Additional information: 1358 Magic number(s): none 1360 File extension(s): dcaf 1362 Macintosh file type code(s): none 1364 Person & email address to contact for further information: TBD 1366 Intended usage: COMMON 1368 Restrictions on usage: None 1370 Author: TBD 1372 Change controller: IESG 1374 12.2. CoAP Content Format Registration 1376 This document specifies a new media type application/dcaf+cbor (cf. 1377 Section 12.1). For use with CoAP, a numeric Content-Format 1378 identifier is to be registered in the "CoAP Content-Formats" sub- 1379 registry within the "CoRE Parameters" registry. 1381 Note to RFC Editor: Please replace all occurrences of "RFC-XXXX" with 1382 the RFC number of this specification. 1384 +-----------------------+----------+------+------------+ 1385 | Media type | Encoding | Id. | Reference | 1386 +-----------------------+----------+------+------------+ 1387 | application/dcaf+cbor | - | TBD1 | [RFC-XXXX] | 1388 +-----------------------+----------+------+------------+ 1390 13. References 1392 13.1. Normative References 1394 [I-D.ietf-core-coap] 1395 Shelby, Z., Hartke, K., and C. Bormann, "Constrained 1396 Application Protocol (CoAP)", draft-ietf-core-coap-18 1397 (work in progress), June 2013. 1399 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1400 Requirement Levels", BCP 14, RFC 2119, March 1997. 1402 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1403 Resource Identifier (URI): Generic Syntax", STD 66, RFC 1404 3986, January 2005. 1406 [RFC4279] Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites 1407 for Transport Layer Security (TLS)", RFC 4279, December 1408 2005. 1410 [RFC5746] Rescorla, E., Ray, M., Dispensa, S., and N. Oskov, 1411 "Transport Layer Security (TLS) Renegotiation Indication 1412 Extension", RFC 5746, February 2010. 1414 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1415 Security Version 1.2", RFC 6347, January 2012. 1417 [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type 1418 Specifications and Registration Procedures", BCP 13, RFC 1419 6838, January 2013. 1421 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 1422 Representation (CBOR)", RFC 7049, October 2013. 1424 13.2. Informative References 1426 [I-D.bormann-core-ace-aif] 1427 Bormann, C., "An Authorization Information Format (AIF) 1428 for ACE", draft-bormann-core-ace-aif-00 (work in 1429 progress), January 2014. 1431 [I-D.ietf-core-block] 1432 Bormann, C. and Z. Shelby, "Blockwise transfers in CoAP", 1433 draft-ietf-core-block-14 (work in progress), October 2013. 1435 [I-D.ietf-core-observe] 1436 Hartke, K., "Observing Resources in CoAP", draft-ietf- 1437 core-observe-12 (work in progress), February 2014. 1439 [I-D.ietf-core-resource-directory] 1440 Shelby, Z., Bormann, C., and S. Krco, "CoRE Resource 1441 Directory", draft-ietf-core-resource-directory-01 (work in 1442 progress), December 2013. 1444 [I-D.schmertmann-dice-codtls] 1445 Schmertmann, L., Hartke, K., and C. Bormann, "CoDTLS: DTLS 1446 handshakes over CoAP", draft-schmertmann-dice-codtls-00 1447 (work in progress), February 2014. 1449 [RFC5988] Nottingham, M., "Web Linking", RFC 5988, October 2010. 1451 [RFC6655] McGrew, D. and D. Bailey, "AES-CCM Cipher Suites for 1452 Transport Layer Security (TLS)", RFC 6655, July 2012. 1454 [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link 1455 Format", RFC 6690, August 2012. 1457 [bergmann12] 1458 Bergmann, O., Gerdes, S., Schaefer, S., Junge, F., and C. 1459 Bormann, "Secure Bootstrapping of Nodes in a CoAP 1460 Network", IEEE Wireless Communications and Networking 1461 Conference Workshops (WCNCW), April 2012. 1463 Authors' Addresses 1464 Stefanie Gerdes 1465 Universitaet Bremen TZI 1466 Postfach 330440 1467 Bremen D-28359 1468 Germany 1470 Phone: +49-421-218-63906 1471 Email: gerdes@tzi.org 1473 Olaf Bergmann 1474 Universitaet Bremen TZI 1475 Postfach 330440 1476 Bremen D-28359 1477 Germany 1479 Phone: +49-421-218-63904 1480 Email: bergmann@tzi.org 1482 Carsten Bormann 1483 Universitaet Bremen TZI 1484 Postfach 330440 1485 Bremen D-28359 1486 Germany 1488 Phone: +49-421-218-63921 1489 Email: cabo@tzi.org