idnits 2.17.1 draft-gerdes-core-dcaf-authorize-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 21, 2013) is 3833 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 1282, but not defined ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) == Outdated reference: A later version (-21) exists of draft-ietf-core-block-13 == Outdated reference: A later version (-16) exists of draft-ietf-core-observe-11 == Outdated reference: A later version (-28) exists of draft-ietf-core-resource-directory-00 -- Obsolete informational reference (is this intentional?): RFC 4627 (Obsoleted by RFC 7158, RFC 7159) -- Obsolete informational reference (is this intentional?): RFC 5988 (Obsoleted by RFC 8288) Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 3 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: April 24, 2014 Universitaet Bremen TZI 6 October 21, 2013 8 Delegated CoAP Authentication and Authorization Framework (DCAF) 9 draft-gerdes-core-dcaf-authorize-01 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 April 24, 2014. 41 Copyright Notice 43 Copyright (c) 2013 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 1.1. Features . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 61 1.2.1. Roles . . . . . . . . . . . . . . . . . . . . . . . . 5 62 1.2.2. Other terms . . . . . . . . . . . . . . . . . . . . . 5 63 2. System Overview . . . . . . . . . . . . . . . . . . . . . . . 6 64 3. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 65 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 7 66 3.2. Unauthorized Resource Request Message . . . . . . . . . . 8 67 3.3. AS Information Message . . . . . . . . . . . . . . . . . . 9 68 3.4. Access Request . . . . . . . . . . . . . . . . . . . . . . 10 69 3.5. Ticket Request Message . . . . . . . . . . . . . . . . . . 11 70 3.6. Ticket Grant Message . . . . . . . . . . . . . . . . . . . 12 71 3.7. Ticket Transfer Message . . . . . . . . . . . . . . . . . 13 72 3.8. DTLS Channel Setup Between C and RS . . . . . . . . . . . 13 73 3.9. Authorized Resource Request Message . . . . . . . . . . . 14 74 4. Ticket . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 75 4.1. Face . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 76 4.2. Verifier . . . . . . . . . . . . . . . . . . . . . . . . . 16 77 4.3. Revocation . . . . . . . . . . . . . . . . . . . . . . . . 17 78 4.3.1. Lifetime . . . . . . . . . . . . . . . . . . . . . . . 17 79 4.3.2. Revocation Messages . . . . . . . . . . . . . . . . . 17 80 5. Payload Format and Encoding (application/dcaf+json) . . . . . 18 81 5.1. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 19 82 6. DTLS PSK Generation Methods . . . . . . . . . . . . . . . . . 22 83 6.1. DTLS PSK Transfer . . . . . . . . . . . . . . . . . . . . 22 84 6.2. Distributed Key Derivation . . . . . . . . . . . . . . . . 22 85 7. Authorization Configuration . . . . . . . . . . . . . . . . . 24 86 8. Trust Relationships . . . . . . . . . . . . . . . . . . . . . 25 87 9. Listing Authorization Server Information in a Resource 88 Directory . . . . . . . . . . . . . . . . . . . . . . . . . . 26 89 10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 90 10.1. Access Granted . . . . . . . . . . . . . . . . . . . . . . 27 91 10.2. Access Denied . . . . . . . . . . . . . . . . . . . . . . 29 92 10.3. Access Restricted . . . . . . . . . . . . . . . . . . . . 29 93 10.4. Implicit Authorization . . . . . . . . . . . . . . . . . . 30 94 11. Security Considerations . . . . . . . . . . . . . . . . . . . 31 95 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 96 12.1. dcaf+json Media Type Registration . . . . . . . . . . . . 32 97 12.2. CoAP Content Format Registration . . . . . . . . . . . . . 33 98 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34 99 13.1. Normative References . . . . . . . . . . . . . . . . . . . 34 100 13.2. Informative References . . . . . . . . . . . . . . . . . . 34 101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36 103 1. Introduction 105 The Constrained Application Protocol (CoAP) [I-D.ietf-core-coap] is a 106 transfer protocol similar to HTTP which is designed for the special 107 requirements of constrained environments. A serious problem with 108 constrained devices is the realization of secure communication. The 109 devices only have limited resources such as memory, stable storage 110 (such as disk space) and transmission capacity and often lack input/ 111 output devices such as keyboards or displays. Therefore, they are 112 not readily capable of using common protocols. Especially 113 authentication mechanisms are difficult to realize, because the lack 114 of stable storage severely limits the number of keys the system can 115 store. Moreover, CoAP has no mechanism to distinguish access rights 116 for different clients (authorization). 118 The DCAF architecture is designed to relieve the constrained nodes 119 from managing keys for numerous devices by introducing authorization 120 servers which conduct the authentication and authorization for their 121 nodes. To achieve this, access tokens are used. A device which 122 wants to access a constrained node's resource first has to gain 123 permission in the form of a token from the node's authorization 124 server. 126 As fine-grained authorization is not always needed on constrained 127 devices, DCAF supports an implicit authorization mode where no 128 authorization information is exchanged. 130 The main goals of DCAF are the setup of a Datagram Transport Layer 131 Security (DTLS) [RFC6347] channel with symmetric pre-shared keys 132 (PSK) [RFC4279] and to securely transmit authorization tickets. 134 1.1. Features 136 o Utilize DTLS communication with pre-shared keys. 138 o Authenticated exchange of authorization information. 140 o Simplified authorization mechanism for cases where implicit 141 authorization is sufficient. 143 o Using only symmetric encryption on constrained nodes. 145 1.2. Terminology 147 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 148 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 149 document are to be interpreted as described in RFC 2119 [RFC2119]. 151 1.2.1. Roles 153 Resource Server (RS): A constrained device that hosts resources the 154 Client wants to access. 156 Client (C): A device that wants to access resources on the Resource 157 Server. 159 Authorization Server (AS): The node that conducts authentication and 160 authorization for a Resource Server. An Authorization Server can be 161 responsible for a single or multiple devices or even for a whole 162 network. A Resource Server can have multiple Authorization Servers. 164 Authentication Manager (AM): The node that conducts authentication on 165 behalf of the Client. 167 Resource Owner: The principal that owns the resource and controls its 168 access permissions. 170 1.2.2. Other terms 172 Access ticket: Contains the authentication and, if necessary, the 173 authorization information needed to access a resource. 175 Authorization information: Contains all information needed by RS to 176 decide if C is privileged to access a resource in a specific way. 178 Authentication information: Contains all information needed by RS to 179 decide if the entity claiming to be C is to be trusted. 181 Access information: Contains authentication information and, if 182 necessary, authorization information. 184 Explicit authorization: The Authorization Server informs the Resource 185 Server in detail which privileges are granted to the Client. 187 Implicit authorization: The Authorization Server informs the Resource 188 Server that the Client is authorized to access any resource on RS in 189 any way, without specifying the privileges in detail. 191 2. System Overview 193 Within the DCAF Architecture each Resource Server (RS) has one or 194 more Authorization Servers (AS) which conduct the authentication and 195 authorization for RS. RS and AS share a symmetric key which has to 196 be exchanged initially to provide for a secure channel. The 197 mechanism used for this is not in the scope of this document. 199 To gain access to a specific resource on a Resource Server, a client 200 (C) has to request an access ticket from one of the Authorization 201 Servers serving RS either directly or, if it is a constrained device, 202 using its Authentication Manager (AM). In the following, we always 203 discuss the AM role separately, even if that is co-located within a 204 (more powerful) C. 206 If AS decides that C is allowed to access the resource, it generates 207 a DTLS pre-shared key (PSK) for the communication between C and RS 208 and wraps it into an access ticket. For explicit access control, AS 209 adds the detailed access permissions to the ticket in a way that RS 210 can interpret. After presenting the ticket to RS, C and RS can 211 communicate securely. 213 To be able to provide for the authentication and authorization 214 services, the Authorization Servers have to fulfill several 215 requirements: 217 o An AS must have enough stable storage (such as disk space) to 218 store the necessary number of credentials (matching the number of 219 clients and Resource Servers). 221 o An AS must possess means for user interaction, for example 222 directly or indirectly connected input/output devices like 223 keyboard and display, to allow for configuration of authorization 224 information by the Resource Owner. 226 o An AS must have enough processing power to handle the 227 authorization requests for all RS devices it is responsible for. 229 3. Protocol 231 The DCAF protocol comprises three parts: 233 1. transfer of authentication and, if necessary, authorization 234 information between C and RS; 236 2. transfer of access requests and the respective ticket grants 237 between C and AM; and 239 3. transfer of access requests and the respective ticket grants 240 between AS and AM. 242 3.1. Overview 244 In Figure 1, a DCAF protocol flow is depicted (messages in square 245 brackets are optional): 247 AM C RS AS 248 | <== DTLS chan. ==> | | <== DTLS chan. ==> | 249 | | [Resource Req.-->] | | 250 | | | | 251 | | [<-- AS Info.] | | 252 | | | | 253 | <-- Access Req. | | | 254 | | | | 255 | <===== TLS/DTLS channel (AM/AS Mutual Authentication) =====> | 256 | | | | 257 | Ticket Request ------------------------------------------> | 258 | | | | 259 | <------------------------------------------ Ticket Grant | 260 | | | | 261 | Ticket Transm. --> | | | 262 | | | | 263 | | <== DTLS chan. ==> | | 264 | | Auth. Res. Req. -> | | 266 Figure 1: Protocol Overview 268 To determine the Authorization Server in charge of a resource hosted 269 at the Resource Server (RS), the Client (C) MAY send an initial 270 Unauthorized Resource Request message to RS. RS then denies the 271 request and sends the address of its Authorization Server (AS) back 272 to the Client. 274 Instead of the initial Unauthorized Resource Request message, C MAY 275 look up the desired resource in a resource directory (cf. 277 [I-D.ietf-core-resource-directory]) that lists RS's resources as 278 discussed in Section 9. 280 Once C knows AS' address, it can send a request for authorization to 281 AS using its own Authentication Manager (AM). AS authenticates AM, 282 who serves as a trusted introducer for C, and decides if C is allowed 283 to communicate with RS and access the requested resource. If it is, 284 AS generates an access ticket for C. The ticket contains keying 285 material for the establishment of a secure channel and, if necessary, 286 a representation of the permissions C has for the resource. C keeps 287 one part of the access ticket and presents the other part to RS to 288 prove its right to access. With their respective parts of the 289 ticket, C and RS are able to establish a secure channel. 291 The following sections specify how CoAP is used to interchange 292 access-related data between RS and AS so that AS can provide C and RS 293 with sufficient information to establish a secure channel, and 294 simultaneously convey authorization information specific for this 295 communication relationship to RS. 297 This document uses JavaScript Object Notation (JSON, [RFC4627]) to 298 express authorization information as set of attributes passed in CoAP 299 payloads. Notation and encoding options are discussed in Section 5. 301 3.2. Unauthorized Resource Request Message 303 The optional Unauthorized Resource Request message is a request for a 304 resource hosted by RS for which no proper authorization is granted. 305 RS MUST treat any CoAP request as Unauthorized Resource Request 306 message when any of the following holds: 308 o The request has been received on an insecure channel. 310 o RS has no valid access information for the sender of the request 311 regarding the requested action on that resource. 313 o RS has valid access information for the sender of the request, but 314 this does not allow the requested action on the requested 315 resource. 317 Note: These conditions ensure that RS can handle requests 318 autonomously once access was granted and a secure channel has been 319 established between C and RS. 321 Unauthorized Resource Request messages MUST be denied with a client 322 error response. In this response, the Resource Server MUST provide 323 proper AS Information to enable the Client to request an access 324 ticket from RS's Authorization Server as described in Section 3.3. 326 The response code MUST be 4.01 (Unauthorized) in case the sender of 327 the Unauthorized Resource Request message is not authenticated, or if 328 RS has no valid access ticket for C. If RS has authorization 329 information for C but not for the resource that C has requested, RS 330 MUST reject the request with a 4.03 (Forbidden). If RS has 331 authorization information for C but they do not cover the action C 332 requested on the resource, RS MUST reject the request with a 4.05 333 (Method Not Allowed). 335 Editor's Note: The use of the response codes 4.03 and 4.05 is 336 intended to prevent infinite loops where a dumb Client 337 optimistically tries to access a requested resource with any 338 access token received from the AS. As malicious clients could 339 pretend to be C to determine C's privileges, these detailed 340 response codes must be used only when a certain level of security 341 is already available which can be achieved only when the Client is 342 authenticated. 344 3.3. AS Information Message 346 The AS Information Message is sent by RS as a response to an 347 Unauthorized Resource Request message (see Section 3.2) to point the 348 sender of the Unauthorized Resource Request message to RS's 349 Authorization Server. The AS information is a set of attributes 350 containing an absolute URI (see Section 4.3 of [RFC3986]) that 351 specifies the Authorization Server in charge of RS. 353 The message MAY also contain a timestamp generated by RS. 355 Figure 2 shows an example for an AS Information message payload using 356 JSON. (Refer to Section 5 for a detailed description of the 357 available attributes and their semantics.) 359 4.01 Unauthorized 360 Content-Format: application/dcaf+json 361 { 362 "AS": "coaps://as-rs.example.com/authorize", 363 "TS": 168537 364 } 366 Figure 2: AS Information Payload Example 368 In this example, the attribute AS points the receiver of this message 369 to the URI "coaps://as-rs.example.com/authorize" to request access 370 permissions. The originator of the AS Information payload (i.e. RS) 371 uses a local clock that is loosely synchronized with a time scale 372 common between RS and AS (e.g., wall clock time). Therefore, it has 373 included a time stamp on its own time scale that is used as a nonce 374 for replay attack prevention. Refer to Section 4.1 for more details 375 concerning the usage of time stamps to ensure freshness of access 376 tickets. 378 3.4. Access Request 380 To retrieve an access ticket for the resource that C wants to access, 381 C sends an Access Request to its authentication manager AM. The 382 Access Request is constructed as follows: 384 1. The request method is POST. 386 2. The request URI is set as described below. 388 3. The message payload contains a data structure that describes the 389 action and resource for which C requests an access ticket. 391 The request URI identifies a resource at AM for handling 392 authorization requests from C. The URI SHOULD be announced by AM in 393 its resource directory as described in Section 9. 395 Note: Where capacity limitations of C do not allow for resource 396 directory lookups, the request URI in Access Requests could be 397 hard-coded during provisioning or set in a specific device 398 configuration profile. 400 The message payload is constructed from the AS information that RS 401 has returned in its AS Information message (see Section 3.3) and 402 information that C provides to describe its intended request(s). The 403 Access Request MUST contain the following attributes: 405 1. Contact information for the AS to use. 407 2. An identifier of C that can be used by AS to distinguish Access 408 Requests from different Clients. 410 3. An absolute URI of the resource that C wants to access. 412 4. The actions that C wants to perform on the resource. 414 5. Any time stamp generated by RS. 416 The identifier of C included in the Access Request is used to 417 distinguish the Clients within AM's namespace. To decide if a Client 418 is allowed to access the requested resource, AS must rely on AM's 419 verification of that Client's identity because AS cannot authenticate 420 the Client by itself. (Refer to Section 8 for a detailed discussion 421 of the trust relationship between authentication managers and 422 authorization servers.) 424 Note: Whenever the Resource Owner wants to specify access permissions 425 for an individual client, the Authorization Server must be able to 426 relate those permissions to that respective client using an 427 identifier that is globally unique. 429 An example Access Request from C to AM is depicted in Figure 3. 430 (Refer to Section 5 for a detailed description of the available 431 attributes and their semantics.) 433 POST client-authorize 434 Content-Format: application/dcaf+json 435 { 436 "AS": coaps://as-rs.example.com/authorize", 437 "CI": "node-588", 438 "M": [ "GET", "PUT" ], 439 "R": "coaps://temp451.example.com/s/tempC", 440 "TS": 168537 441 } 443 Figure 3: Access Request Message Example 445 The example shows an Access Request message payload for the resource 446 "/s/tempC" on the Resource Server "temp451.example.com". Requested 447 operations in attribute M are GET and PUT. The requesting client is 448 identified as "node-588". 450 The attributes AS (that denotes the Authorization Server to use) and 451 TS (a nonce generated by RS) are taken from the AS Information 452 message from RS. 454 The response to an Authorization Request is delivered by AM back to C 455 in a Ticket Transfer message. 457 3.5. Ticket Request Message 459 When AM receives an Access Request message from C it MAY return a 460 cached response if it is known to be fresh. Otherwise, it checks 461 whether the request payload is of type "application/dcaf+json" and 462 contains at least the fields AS, CI, M, and R. AM MUST respond with 463 4.00 (Bad Request) if the type is "application/dcaf+json" and any of 464 these fields is missing or does not conform to the format described 465 in Section 5. Content formats other than application/dcaf+json are 466 out of scope of this specification. 468 When the payload is correct, AM creates a Ticket Request message from 469 the Access Request received from C as follows: 471 1. The destination of the Ticket Request message is derived from the 472 authority information in the URI contained in field "AS" of the 473 Access Request message payload. 475 2. The request method is POST. 477 3. The request URI is constructed from the AS field received in the 478 Access Request message payload. 480 4. The payload is copied from the Access Request sent by C. 482 To send the Ticket Request message to AS a secure channel between AM 483 and AS MUST be used. Depending on the URI scheme used in the AS 484 field of the Access Request message payload, this could be, e.g., a 485 DTLS channel (for "coaps") or a TLS connection (for "https"). AM and 486 AS MUST be able to mutually authenticate each other, e.g. based on a 487 public key infrastructure. (Refer to Section 8 for a detailed 488 discussion of the trust relationship between authentication managers 489 and authorization servers.) 491 3.6. Ticket Grant Message 493 When AS has received a Ticket Request message it has to evaluate the 494 access request information contained therein. First, it checks 495 whether the request payload is of type "application/dcaf+json" and 496 contains at least the fields AS, CI, M, and R. AS MUST respond with 497 4.00 (Bad Request) for CoAP (or 400 for HTTP) if the type is 498 "application/dcaf+json" and any of these fields is missing or does 499 not conform to the format described in Section 5. 501 AS decides whether or not access is granted to the requested resource 502 and then creates a Ticket Grant message that reflects the result. To 503 grant access to the requested resource, AS creates an access ticket 504 comprised of a Face and a Verifier as described in Section 4.1. 506 The Ticket Grant message then is constructed as a success response 507 indicating attached content, i.e. 2.05 for CoAP, or 200 for HTTP, 508 respectively. The payload of the Ticket Grant message is a data 509 structure that contains the result of the access request. When 510 access is granted, the data structure contains the ticket's Face, the 511 Verifier and the Session Key Generation Method. 513 The Ticket Grant message MAY provide cache-control options to enable 514 intermediaries to cache the response. The message MAY be cached 515 according to the rules defined in [I-D.ietf-core-coap] to facilitate 516 ticket retrieval when C has crashed and wants to recover the DTLS 517 session with RS. 519 AS sets Max-Age according to the ticket lifetime in its response 520 (Ticket Grant Message). 522 Figure 4 shows an example Ticket Grant message using CoAP. The Face/ 523 Verifier information is transferred as a JSON data structure as 524 specified in Section 5. The Max-Age option tells the receiving AM 525 how long this ticket will be valid. 527 2.05 Content 528 Content-Format: application/dcaf+json 529 Max-Age: 86400 530 { "F": { 531 "AI": { "Role" : 3 }, 532 "CI": "2001:db8:ab9:1234:7920:3133:ae5f:87", 533 "TS": "2013-07-10T10:04:12.391", 534 "L": 86400, 535 "G": "hmac_sha256" 536 }, 537 "V": "w+ZeJx5MxIEkt7yBMWjX6ztSYcIBTz+sv4z98m+PUEY=" 538 } 540 Figure 4: Example Ticket Grant Message 542 A Ticket Grant message that declines any operation on the requested 543 resource is illustrated in Figure 5. As no ticket needs to be 544 issued, an empty payload is included with the response. 546 2.05 Content 547 Content-Format: application/dcaf+json 549 Figure 5: Example Ticket Grant Message With Reject 551 3.7. Ticket Transfer Message 553 A Ticket Transfer message delivers the access information sent by AS 554 in a Ticket Grant message to the requesting client C. The Ticket 555 Transfer message is the response to the Access Request message sent 556 from C to AM and includes any access information from AS contained in 557 the Ticket Grant message. 559 3.8. DTLS Channel Setup Between C and RS 561 Using the information contained in a positive response to its Access 562 Request (i.e. a Ticket Transfer message that contains a Face and a 563 Verifier), C can initiate establishment of a new DTLS channel with 564 RS. To use DTLS with pre-shared keys, C follows the PSK key exchange 565 algorithm specified in Section 2 of [RFC4279], with the following 566 additional requirements: 568 1. C sets the psk_identity field of the ClientKeyExchange message to 569 the ticket Face received in the Ticket Transfer message. 571 2. C uses the ticket Verifier as PSK when constructing the premaster 572 secret. 574 Note1: As RS cannot provide C with a meaningful PSK identity hint in 575 response to C's ClientHello message, RS SHOULD NOT send a 576 ServerKeyExchange message. 578 Note2: According to [I-D.ietf-core-coap], CoAP implementations MUST 579 support the ciphersuite TLS_PSK_WITH_AES_128_CCM_8 [RFC6655]. C is 580 therefore expected to offer at least this ciphersuite to RS. 582 Note3: The ticket is constructed by AS such that RS can derive the 583 authorization information as well as the PSK (refer to Section 6 for 584 details). 586 3.9. Authorized Resource Request Message 588 Successful establishment of the DTLS channel between C and RS ties 589 the authorization information contained in the psk_identity field to 590 this channel. Any request that RS receives on this channel is 591 checked against these authorization rules. Incoming CoAP requests 592 that are not Authorized Resource Requests MUST be rejected by RS with 593 4.01 response as described in Section 3.2. 595 RS SHOULD treat an incoming CoAP request as Authorized Resource 596 Request if the following holds: 598 1. The message was received on a secure channel that has been 599 established using the procedure defined in Section 3.8. 601 2. The authorization information tied to the secure channel is 602 valid. 604 3. The request is destined for RS. 606 4. The resource URI specified in the request is covered by the 607 authorization information. 609 5. The request method is an authorized action on the resource with 610 respect to the authorization information. 612 Note that the authorization information is not restricted to a single 613 resource URI. For example, role-based authorization can be used to 614 authorize a collection of semantically connected resources 615 simultaneously. Implicit authorization also provides access rights 616 to authenticated clients for all actions on all resources that RS 617 offers. As a result, C can use the same DTLS channel not only for 618 subsequent requests for the same resource (e.g. for block-wise 619 transfer as defined in [I-D.ietf-core-block] or refreshing observe- 620 relationships [I-D.ietf-core-observe]) but also for requests to 621 distinct resources. 623 Incoming CoAP requests received on a secure channel according to the 624 procedure defined in Section 3.8 MUST be rejected 626 1. with response code 4.03 (Forbidden) when the resource URI 627 specified in the request is not covered by the authorization 628 information, and 630 2. with response code 4.05 (Method Not Allowed) when the resource 631 URI specified in the request covered by the authorization 632 information but not the requested action. 634 Since AS may limit the set of requested actions in its Ticket Grant 635 message, C cannot know a priori if a an Authorized Resource Request 636 will succeed. 638 4. Ticket 640 Access tokens in DCAF are tickets that consist of two parts, namely 641 the Face and the Verifier. 643 4.1. Face 645 Face is the part of the ticket generated for RS. Face MUST contain 646 all information needed for authorized access to a resource: 648 o Authorization Information 650 o Client Identifier 652 o A timestamp generated by AS 654 Optionally, Face MAY also contain: 656 o A lifetime (optional) 658 o A DTLS pre-shared key (optional) 660 RS MUST verify the integrity of Face, i.e. the information contained 661 in Face stems from AS and was not manipulated by anyone else. 663 Face MUST contain a timestamp to verify that the contained 664 information is fresh. As constrained devices may not have a clock, 665 timestamps MAY be generated using the clock ticks since the last 666 reboot. To circumvent synchronization problems the timestamp MAY be 667 generated by RS and included in the first AS Information message. 668 Alternatively, AS MAY generate the timestamp. In this case, AS and 669 RS MUST use a time synchronization mechanism to make sure that RS 670 interprets the timestamp correctly. 672 Face MAY be encrypted. If Face contains a DTLS PSK, the whole 673 content of Face MUST be encrypted. 675 Note: The integrity of Face can be ensured by various means. Face 676 may be encrypted by AS with a key it shares with RS. Alternatively, 677 RS can use a mechanism to generate the DTLS PSK which includes Face 678 and is only able to calculate the correct key with the correct Face 679 (refer to Section 6 for details). 681 4.2. Verifier 683 The Verifier part of the ticket is generated for C. It contains the 684 DTLS PSK for C. The Verifier MUST NOT be transmitted over insecure 685 channels. 687 4.3. Revocation 689 The existence of access tickets SHOULD be limited in time. This can 690 be achieved either by explicit Revocation Messages to invalidate a 691 ticket or implicitly by attaching a lifetime to the ticket. 693 4.3.1. Lifetime 695 Tickets MAY have a lifetime. AS is responsible for defining the 696 ticket lifetime. If AS sets a lifetime for a ticket, AS and RS MUST 697 use a time synchronization method to ensure that RS is able to 698 interpret the lifetime correctly. RS SHOULD end the DTLS connection 699 to C if the lifetime of a ticket has run out and it MUST NOT accept 700 new requests. RS MUST NOT accept tickets with an invalid lifetime. 702 Note: Defining reasonable ticket lifetimes is difficult to 703 accomplish. How long a client needs to access a resource depends 704 heavily on the application scenario and may be difficult to decide 705 for AS. 707 4.3.2. Revocation Messages 709 AS MAY revoke tickets by sending a ticket revocation message to RS. 710 If RS receives a ticket revocation message, it MUST end the DTLS 711 connection to C and MUST NOT accept any further requests from C. 713 If ticket revocation messages are used, RS MUST check regularly if AS 714 is still available. If RS cannot contact AS, it MUST end all DTLS 715 connections and reject any further requests from C. 717 Note: The loss of the connection between RS and AS prevents all 718 access to RS. This might especially be a severe problem if AS is 719 responsible for several Resource Servers or even a whole network. 721 5. Payload Format and Encoding (application/dcaf+json) 723 Various messages types of the DCAF protocol carry payloads to express 724 authorization information and parameters for generating the DTLS PSK 725 to be used by C and RS. In this section, a representation in 726 JavaScript Object Notation (JSON, [RFC4627]) is defined. 728 The following attributes are defined: 730 AS: Authorization Server. This attribute denotes the authorization 731 server that is in charge of the resource specified in attribute R. 732 The attribute's value is a string that contains an absolute URI 733 according to Section 4.3 of [RFC3986]. 735 AI: Authorization Information. A data structure used to convey 736 authorization information from AS to RS (see below). 738 CI: Client Identity. A string that identifies the initiator of the 739 authorization request. This label MAY be a fully qualified domain 740 name, an IP address, or any other character literal that is used 741 by the Authorization Server to decide whether or not access is 742 granted to the requesting entity. 744 E: Encrypted Ticket Face. A string containing an encrypted ticket 745 Face encoded as base64 according to Section 4 of [RFC4648]. 747 K: Key. A string that identifies the shared key between RS and AS 748 that can be used to decrypt the contents of E. If the attribute E 749 is present and no attribute K has been specified, the default is 750 to use the current session key for the secured channel between RS 751 and AS. 753 M: Methods. The list of actions to be performed on the resource R, 754 encoded as an array of strings. In an authorization request, this 755 list contains the actions that the initiator of the request wants 756 to perform. In an authorization ticket, this attribute denotes 757 the actions that are permitted. 759 R: Resource. A string that denotes the absolute URI of the resource 760 to be accessed. As the access ticket is requested in order to 761 establish a DTLS connection with the server that hosts this 762 resource, the URI scheme typically is "coaps". 764 TS: Time Stamp. An optional time stamp that indicates the instant 765 when the access ticket request was formed. This attribute can be 766 used by the resource server in an AS Information message to convey 767 a time stamp in its local time scale (e.g. when it does not have a 768 real time clock with synchronized global time). When the 769 attribute's value is encoded as a string, it MUST contain a valid 770 UTC timestamp without time zone information. When encoded as 771 integer, TS contains a system timestamp relative to the local time 772 scale of its generator, usually RS. 774 L: Lifetime. A lifetime of the ticket. When encoded as a string, L 775 MUST denote the ticket's expiry time as a valid UTC timestamp 776 without time zone information. When encoded as an integer, L MUST 777 denote the ticket's validity period in seconds relative to TS. 779 G: DTLS PSK Generation Method. A string that identifies the method 780 that RS MUST use to derive the DTLS PSK from the ticket Face. 781 This attribute MUST NOT be used when attribute V is present within 782 the contents of F. 784 F: Ticket Face. An object containing the fields AI, CI, TS, and 785 optionally G, L and V. 787 V: Ticket Verifier. A string containing the shared secret between C 788 and RS, encoded as base64 according to Section 4 of [RFC4648]. 790 The exact specification of AI is out of scope for this document. AI 791 may, e.g., contain a single role identifier known by RS, or an array 792 of pairs (M, R) with M and R defined as above. 794 As AI is used to authorize resource access as defined in Section 3.9, 795 RS MUST be able to interpret the contained information. 797 5.1. Examples 799 The following example specifies an Authorization Server that will be 800 accessed using HTTP over TLS. The request URI is set to "/a?ep=% 801 5B2001:DB8::dcaf:1234%5D" (hence denoting the endpoint address to 802 authorize). TS denotes a local timestamp in UTC. 804 POST /a?ep=%5B2001:DB8::dcaf:1234%5D HTTP/1.1 805 Host: as-rs.example.com 806 Content-Type: application/dcaf+json 808 { 809 "AS": "https://as-rs.example.com/a?ep=%5B2001:DB8::dcaf:1234%5D", 810 "CI": "2001:DB8::dcaf:1234", 811 "M": [ "GET" ], 812 "R": "coaps://temp451.example.com/s/tempC", 813 "TS": "2013-07-14T11:58:22.923" 814 } 816 The following example shows a ticket for the distributed key 817 generation method (cf. Section 6.2), comprised of a Face (F) and a 818 Verifier (V). The Face data structure contains authorization 819 information AI with an application-specific role identifier, a client 820 identifier, a timestamp using the local time scale of RS, and a 821 lifetime relative to RS's time scale. 823 The DTLS PSK Generation Method is set to "hmac_sha256" denoting that 824 the distributed key derivation is used as defined in Section 6.2 with 825 SHA-256 as HMAC function. 827 The Verifier V contains a shared secret to be used as DTLS PSK 828 between C and RS. 830 HTTP/1.1 200 OK 831 Content-Type: application/dcaf+json 833 { 834 "F": { 835 "AI": { "Role" : 3 }, 836 "CI": "2001:db8:ab9:1234:7920:3133:ae5f:87", 837 "TS": 2938749, 838 "L": 3600, 839 "G": "hmac_sha256" 840 }, 841 "V": "zrPOuc6xzr/Pjc+Bz4TOuSDOvM61IM68zq3Ou865Cg==" 842 } 844 The Face may be encrypted as illustrated in the following example. 845 Here, the field E carries an encrypted and base64-encoded Face data 846 structure that contains the same information as the previous example, 847 and an additional Verifier. Encryption was done with a secret shared 848 by AS and RS. (This example uses AES128_CCM with the secret { 0x00, 849 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08, 0x09, 0x0a, 0x0b, 850 0x0c, 0x0d, 0x0e, 0x0f } and RS's timestamp { 0x00, 0x2C, 0xD7, 0x7D 851 } as nonce.) Line breaks have been inserted to improve readability. 853 The attribute K describes the identity of the key to be used by RS to 854 decrypt the contents of attribute E. Here, The value "key0" in this 855 example is used to indicate that the shared session key between RS 856 and AS was used for encrypting E. 858 { 859 "E": "rjtolfjyX9q7Emxgsnz+nf0xTQhe1MjzZBRoIEW4vmSVlyJdW4KDgVtW 860 LyBnQSVX0lmVpxUYbdNuk/5PkCOJBeex0obiEBC1UmKoJfJfjy7bLQhq 861 k9HuJD7cvjHNOVZtNZf5qrxt7xJSoZFe6j/SJuxGNH/72SPDrdMQeXJI 862 pX6vCJB698FcRDOXh/ipi9KT8YWeo/ljUMgJc+LI", 863 "K": "key0", 864 "V": "zrPOuc6xzr/Pjc+Bz4TOuSDOvM61IM68zq3Ou865Cg==" 866 } 868 The decrypted contents of E are depicted below (whitespace has been 869 added to improve readability). The presence of the attribute V 870 indicates that the DTLS PSK Transfer is used to convey the session 871 key (cf. Section 6.1). 873 "F":{"AI":{"Role":3}, 874 "CI":"2001:db8:ab9:1234:7920:3133:ae5f:87", 875 "TS":2938749, 876 "L":3600, 877 "V":"zrPOuc6xzr/Pjc+Bz4TOuSDOvM61IM68zq3Ou865Cg=="} 879 6. DTLS PSK Generation Methods 881 One goal of the DCAF protocol is to provide for a DTLS PSK shared 882 between C and RS. AS and RS MUST negotiate the method for the DTLS 883 PSK generation. 885 6.1. DTLS PSK Transfer 887 The DTLS PSK is generated by AS and transmitted to C and RS using a 888 secure channel. 890 The DTLS PSK transfer method is defined as follows: 892 o AS generates the DTLS PSK using an algorithm of its choice 894 o AS MUST include a representation of the DTLS PSK in Face and 895 encrypt it together with all other information in Face with a key 896 K(AS,RS) it shares with RS. How AS and RS exchange K(AS,RS) is 897 not in the scope of this document. AS and RS MAY use their 898 preshared key as K(AS,RS). 900 o AS MUST include a representation of the DTLS PSK in the Verifier. 902 o As AS and C do not have a shared secret, the Verifier MUST be 903 transmitted to C using encrypted channels. 905 o RS MUST decrypt Face using K(AS,RS) 907 6.2. Distributed Key Derivation 909 AS generates a DTLS PSK for C which is transmitted using a secure 910 channel. RS generates its own version of the DTLS PSK using the 911 information contained in Face (see also Section 4.1). 913 The distributed key derivation method is defined as follows: 915 o AS and RS both generate the DTLS PSK using the information. 916 included in Face. They use an HMAC algorithm on Face with a 917 shared key. The result serves as the DTLS PSK. How AS and RS 918 negotiate the used HMAC algorithm is not in the scope of this 919 document. They MAY however use the HMAC algorithm they use for 920 their DTLS connection. 922 o AS MUST include a representation of the DTLS PSK in the Verifier. 924 o As AS and C do not have a shared secret, the Verifier MUST be 925 transmitted to C using encrypted channels. 927 o AS MUST NOT include a representation of the DTLS PSK in Face. 929 o AS MUST NOT encrypt Face. 931 7. Authorization Configuration 933 For the protocol defined in this document, proper configuration of AS 934 is crucial. The principal who owns the resources hosted by RS (i.e. 935 the Resource Owner) needs to define permissions for the resources. 936 The data representation of these permissions are not in the scope of 937 this document. 939 8. Trust Relationships 941 C trusts AM, and RS trusts AS. Obviously, AM trusts C with the 942 specific permissions it hands over to it. How this trust is 943 established, is not in the scope of this document. It may be 944 achieved by using a bootstrapping mechanism similar to [bergmann12]. 946 Additionally, AS and AM need to have a trust relationship 947 established. Its establishment is also not in the scope of this 948 document. It fulfills the following conditions: 950 1. AS has means to authenticate AM (e.g. it has a certificate of AM 951 or a PKI in which AM is included) and vice versa 953 2. As far as AS needs to rely on the different clients of AM to 954 receive different permissions, it can be sure that AM correctly 955 identifies these clients towards AS and does not leak tickets 956 that have been generated for a specific client C to another 957 client. 959 AS trusts C indirectly because it trusts AM and AM vouches for C. The 960 DCAF Protocol does not provide any means for AS to validate that a 961 resource requests stems from C. 963 C indirectly trusts AS with some potentially confidential 964 information, and that AS correctly represents RS, because AM trusts 965 AS. 967 AM trusts RS indirectly because it trusts AS and AS vouches for RS. 969 C implicitly trusts RS with some potentially confidential information 970 because it trusts AM and because RS can prove that it shares a key 971 with AS. 973 AM <--------------------> AS 975 /|\ /|\ 976 | | 977 \|/ \|/ 979 C ..................... RS 981 9. Listing Authorization Server Information in a Resource Directory 983 CoAP utilizes the Web Linking format [RFC5988] to facilitate 984 discovery of services in an M2M environment. [RFC6690] defines 985 specific link parameters that can be used to describe resources to be 986 listed in a resource directory [I-D.ietf-core-resource-directory]. 988 This section defines a resource type "auth-request" that can be used 989 by clients to retrieve the request URI for a server's authorization 990 service. When used with the parameter rt in a web link, "auth- 991 request" indicates that the corresponding target URI can be used in a 992 POST message to request authorization for the resource and action 993 that are described in the request payload. 995 The Content-Format "application/dcaf+json" with numeric identifier 996 TBD1 defined in this specification MAY be used to express access 997 requests and their responses. 999 The following example shows the web link used by AM in this document 1000 to relay incoming Authorization Request messages to AS. (Whitespace 1001 is included only for readability.) 1003 ;rt="auth-request";ct=TBD1 1004 ;title="Contact Remote Authorization Server" 1006 The resource directory that hosts the resource descriptions of RS 1007 could list the following description. In this example, the URI "ep/ 1008 node138/a/switch2941" is relative to the resource context 1009 "coaps://as-rs.example.com/", i.e. the authorization server AS. 1011 ;rt="auth-request";ct=TBD1;ep="node138" 1012 ;title="Request Client Authorization" 1013 ;anchor="coaps://as-rs.example.com/" 1015 10. Examples 1017 This section gives a number of short examples with message flows for 1018 the initial Unauthorized Resource Request and the subsequent 1019 retrieval of a ticket from AS. The notation here follows the role 1020 conventions defined in Section 1.2.1. The payload format is encoded 1021 as proposed in Section 5. The IP address of AS is 2001:DB8::1, the 1022 IP address of RS is 2001:DB8::dcaf:1234, and C's IP address is 2001: 1023 DB8::c. 1025 10.1. Access Granted 1027 This example shows an Unauthorized PUT request from C to RS that is 1028 answered with an AS Information message. C then sends a POST request 1029 to AM with a description of its intended request. AM forwards this 1030 request to AS using CoAP over a DTLS-secured channel. The response 1031 from AS contains an access ticket that is relayed back to AM. 1033 C --> RS 1034 PUT a/switch2941 [Mid=1234] 1035 Content-Format: application/senml+json 1036 {e: [{"bv": "1"}]} 1038 C <-- RS 1039 4.01 Unauthorized [Mid=1234] 1040 Content-Format: application/dcaf+json 1041 {"AS": "coaps://[2001:DB8::1]/ep/node138/a/switch2941"} 1043 C --> AM 1044 POST client-authorize [Mid=1235,Token="tok"] 1045 Content-Format: application/dcaf+json 1046 {"AS": "coaps://[2001:DB8::1]/ep/node138/a/switch2941", 1047 "CI": "2001:DB8::c", 1048 "M": [ "PUT" ], 1049 "R": "coaps://[2001:DB8::dcaf:1234]/a/switch2941" 1050 } 1052 AM --> AS [Mid=23146] 1053 POST ep/node138/a/switch2941 1054 Content-Format: application/dcaf+json 1055 {"AS": "coaps://[2001:DB8::1]/ep/node138/a/switch2941", 1056 "CI": "2001:DB8::c", 1057 "M": [ "PUT" ], 1058 "R": "coaps://[2001:DB8::dcaf:1234]/a/switch2941" 1059 } 1061 AM <-- AS 1062 2.05 Content [Mid=23146] 1063 Content-Format: application/dcaf+json 1064 { "F": { "AI": { "R" : "a/switch2941", "M" : [ "GET", "PUT" ] }, 1065 "CI": "2001:DB8::c", 1066 "TS": "2013-07-04T20:17:38.002, 1067 "G": "hmac_sha256" 1068 }, 1069 "V": "yYVLYZZ5Nssbn0by3fqel9WK6jHdoYyNej2d/kSuBLw=" 1070 } 1072 C <-- AM 1073 2.05 Content [Mid=1235,Token="tok"] 1074 Content-Format: application/dcaf+json 1075 { "F": { "AI": { "R" : "a/switch2941", "M" : [ "GET", "PUT" ] }, 1076 "CI": "2001:DB8::c", 1077 "TS": "2013-07-04T20:17:38.002", 1078 "G": "hmac_sha256" 1079 }, 1080 "V": "MR5TMrNngbSEAkFl0akmsdbmzF0gqxGI/d3KjwT8GxI=" 1081 } 1083 C --> RS 1084 ClientHello (TLS_PSK_WITH_AES_128_CCM_8) 1086 C <-- RS 1087 ServerHello (TLS_PSK_WITH_AES_128_CCM_8) 1088 ServerHelloDone 1090 C --> RS 1091 ClientKeyExchange 1092 psk_identity='"F":{"AI":{"R":"a/switch2941","M":["GET","PUT"]}, 1093 "CI": "2001:DB8::c", 1094 "TS": "2013-07-04T20:17:38.002", 1095 "G": "hmac_sha256"') 1097 (C decodes the contents of V and uses the result as PSK) 1098 ChangeCipherSpec 1099 Finished 1101 (RS calculates PSK from AI, CI, TS and its session key 1102 HMAC_sha256("{\"R\":\"a/switch2941\",\"M\":[\"GET\",\"PUT\"]}"+ 1103 "2001:DB8::c"+"2013-07-04T20:17:38.002", 1104 "secret") 1105 = 311e5332b36781b484024165d1a926b1d6e6cc5d20ab1188fdddca8f04fc1b12 1106 ) 1108 C <-- RS 1109 ChangeCipherSpec 1110 Finished 1112 10.2. Access Denied 1114 This example shows a denied Authorization request for the DELETE 1115 operation. 1117 C --> RS 1118 DELETE a/switch2941 1120 C <-- RS 1121 4.01 Unauthorized 1122 Content-Format: application/dcaf+json 1123 {"AS": "coaps://[2001:DB8::1]/ep/node138/a/switch2941"} 1125 C --> AM 1126 POST client-authorize 1127 Content-Format: application/dcaf+json 1128 {"AS": "coaps://[2001:DB8::1]/ep/node138/a/switch2941", 1129 "CI": "2001:DB8::c", 1130 "M": [ "DELETE" ], 1131 "R": "coaps://[2001:DB8::dcaf:1234]/a/switch2941" 1132 } 1134 AM --> AS 1135 POST ep/node138/a/switch2941 1136 Content-Format: application/dcaf+json 1137 {"AS": "coaps://[2001:DB8::1]/ep/node138/a/switch2941", 1138 "CI": "2001:DB8::c", 1139 "M": [ "DELETE" ], 1140 "R": "coaps://[2001:DB8::dcaf:1234]/a/switch2941" 1141 } 1143 AM <-- AS 1144 2.05 Content 1145 Content-Format: application/dcaf+json 1147 C <-- AM 1148 2.05 Content 1149 Content-Format: application/dcaf+json 1151 10.3. Access Restricted 1153 This example shows a denied Authorization request for the operations 1154 GET, PUT, and DELETE. AS grants access for PUT only. 1156 AM --> AS 1157 POST ep/node138/a/switch2941 1158 Content-Format: application/dcaf+json 1159 {"AS": "coaps://[2001:DB8::1]/ep/node138/a/switch2941", 1160 "CI": "2001:DB8::c", 1161 "M": [ "GET", "PUT", "DELETE" ], 1162 "R": "coaps://[2001:DB8::dcaf:1234]/a/switch2941" 1163 } 1165 AM <-- AS 1166 2.05 Content 1167 Content-Format: application/dcaf+json 1168 { "F": { "AI": { "R" : "a/switch2941", "M" : [ "GET", "PUT" ] }, 1169 "CI": "2001:DB8::c", 1170 "TS": "2013-07-04T21:33:11.930", 1171 "G": "hmac_sha256" 1172 }, 1173 "V": "NZ8Q3o8P4eHOzkoscaUpoRvrn5d74Cscw/aXAiNmC/k=" 1174 } 1176 10.4. Implicit Authorization 1178 This example shows an Authorization request using implicit 1179 authorization. AM initially requests the actions GET and POST on the 1180 resource "coaps://[2001:DB8::dcaf:1234]/a/switch2941". AS returns a 1181 ticket that has no AI field in its ticket Face, hence implicitly 1182 authorizing C. 1184 AM --> AS 1185 POST ep/node138/a/switch2941 1186 Content-Format: application/dcaf+json 1187 {"AS": "coaps://[2001:DB8::1]/ep/node138/a/switch2941", 1188 "CI": "2001:DB8::c", 1189 "M": [ "GET", "POST" ], 1190 "R": "coaps://[2001:DB8::dcaf:1234]/a/switch2941" 1191 } 1193 AM <-- AS 1194 2.05 Content 1195 Content-Format: application/dcaf+json 1196 { "F": { "CI": "2001:DB8::c", 1197 "TS": "2013-07-16T10:15:43.663", 1198 "G": "hmac_sha256" 1199 }, 1200 "V": "mCYtLG/oZIWki/mCFNJ4nxI0WMPwlDKAnXIo/ir2dtI=" 1201 } 1203 11. Security Considerations 1205 As this protocol builds on transitive trust between authorization 1206 servers as mentioned in Section 8, AS has no direct means to validate 1207 that a resource request originates from C. It has to trust AM that it 1208 correctly vouches for C and that it does not give authorization 1209 tickets meant for C to another client nor disclose the contained 1210 session key. 1212 The Authorization Server also could constitute a single point of 1213 failure. If the Authorization Server fails, the resources on all 1214 Resource Servers it is responsible for cannot be accessed any more. 1215 Thus, it is crucial for large networks to use Authorization Servers 1216 in a redundant setup. 1218 12. IANA Considerations 1220 The following registrations are done following the procedure 1221 specified in [RFC6838]. 1223 Note to RFC Editor: Please replace all occurrences of "[RFC-XXXX]" 1224 with the RFC number of this specification. 1226 12.1. dcaf+json Media Type Registration 1228 Type name: application 1230 Subtype name: dcaf+json 1232 Required parameters: none 1234 Optional parameters: none 1236 Encoding considerations: Must be encoded as using a subset of the 1237 encoding allowed in [RFC4627]. Specifically, only the primitive data 1238 types String and Number are allowed. The type Number is restricted 1239 to unsigned integers (i.e., no negative numbers, fractions or 1240 exponents are allowed). Encoding MUST be UTF-8. These restrictions 1241 simplify implementations on devices that have very limited memory 1242 capacity. 1244 Security considerations: TBD 1246 Interoperability considerations: TBD 1248 Published specification: [RFC-XXXX] 1250 Applications that use this media type: TBD 1252 Additional information: 1254 Magic number(s): none 1256 File extension(s): dcaf 1258 Macintosh file type code(s): none 1260 Person & email address to contact for further information: TBD 1262 Intended usage: COMMON 1264 Restrictions on usage: None 1265 Author: TBD 1267 Change controller: IESG 1269 12.2. CoAP Content Format Registration 1271 This document specifies a new media type application/dcaf+json (cf. 1272 Section 12.1). For use with CoAP, a numeric Content-Format 1273 identifier is to be registered in the "CoAP Content-Formats" sub- 1274 registry within the "CoRE Parameters" registry. 1276 Note to RFC Editor: Please replace all occurrences of "RFC-XXXX" with 1277 the RFC number of this specification. 1279 +-----------------------+----------+------+------------+ 1280 | Media type | Encoding | Id. | Reference | 1281 +-----------------------+----------+------+------------+ 1282 | application/dcaf+json | - | TBD1 | [RFC-XXXX] | 1283 +-----------------------+----------+------+------------+ 1285 13. References 1287 13.1. Normative References 1289 [I-D.ietf-core-coap] 1290 Shelby, Z., Hartke, K., and C. Bormann, "Constrained 1291 Application Protocol (CoAP)", draft-ietf-core-coap-18 1292 (work in progress), June 2013. 1294 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1295 Requirement Levels", BCP 14, RFC 2119, March 1997. 1297 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1298 Resource Identifier (URI): Generic Syntax", STD 66, 1299 RFC 3986, January 2005. 1301 [RFC4279] Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites 1302 for Transport Layer Security (TLS)", RFC 4279, 1303 December 2005. 1305 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 1306 Encodings", RFC 4648, October 2006. 1308 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1309 Security Version 1.2", RFC 6347, January 2012. 1311 [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type 1312 Specifications and Registration Procedures", BCP 13, 1313 RFC 6838, January 2013. 1315 13.2. Informative References 1317 [I-D.ietf-core-block] 1318 Bormann, C. and Z. Shelby, "Blockwise transfers in CoAP", 1319 draft-ietf-core-block-13 (work in progress), October 2013. 1321 [I-D.ietf-core-observe] 1322 Hartke, K., "Observing Resources in CoAP", 1323 draft-ietf-core-observe-11 (work in progress), 1324 October 2013. 1326 [I-D.ietf-core-resource-directory] 1327 Shelby, Z., Krco, S., and C. Bormann, "CoRE Resource 1328 Directory", draft-ietf-core-resource-directory-00 (work in 1329 progress), June 2013. 1331 [RFC4627] Crockford, D., "The application/json Media Type for 1332 JavaScript Object Notation (JSON)", RFC 4627, July 2006. 1334 [RFC5988] Nottingham, M., "Web Linking", RFC 5988, October 2010. 1336 [RFC6655] McGrew, D. and D. Bailey, "AES-CCM Cipher Suites for 1337 Transport Layer Security (TLS)", RFC 6655, July 2012. 1339 [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link 1340 Format", RFC 6690, August 2012. 1342 [bergmann12] 1343 Bergmann, O., Gerdes, S., Schaefer, S., Junge, F., and C. 1344 Bormann, "Secure Bootstrapping of Nodes in a CoAP 1345 Network", IEEE Wireless Communications and Networking 1346 Conference Workshops (WCNCW), April 2012. 1348 Authors' Addresses 1350 Stefanie Gerdes 1351 Universitaet Bremen TZI 1352 Postfach 330440 1353 Bremen D-28359 1354 Germany 1356 Phone: +49-421-218-63906 1357 Email: gerdes@tzi.org 1359 Olaf Bergmann 1360 Universitaet Bremen TZI 1361 Postfach 330440 1362 Bremen D-28359 1363 Germany 1365 Phone: +49-421-218-63904 1366 Email: bergmann@tzi.org 1368 Carsten Bormann 1369 Universitaet Bremen TZI 1370 Postfach 330440 1371 Bremen D-28359 1372 Germany 1374 Phone: +49-421-218-63921 1375 Email: cabo@tzi.org