idnits 2.17.1 draft-seitz-ace-oscoap-profile-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 6 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 31, 2016) is 2732 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: 'I-D.ietf-ace-actors' is mentioned on line 114, but not defined == Unused Reference: 'I-D.gerdes-ace-actors' is defined on line 563, but no explicit reference was found in the text == Outdated reference: A later version (-16) exists of draft-ietf-core-object-security-00 == Outdated reference: A later version (-14) exists of draft-selander-ace-cose-ecdhe-04 == Outdated reference: A later version (-24) exists of draft-ietf-cose-msg-23 == Outdated reference: A later version (-46) exists of draft-ietf-ace-oauth-authz-04 == Outdated reference: A later version (-15) exists of draft-ietf-ace-cbor-web-token-01 == Outdated reference: A later version (-07) exists of draft-ietf-ace-actors-03 -- Obsolete informational reference (is this intentional?): RFC 7049 (Obsoleted by RFC 8949) -- Obsolete informational reference (is this intentional?): RFC 7231 (Obsoleted by RFC 9110) Summary: 1 error (**), 0 flaws (~~), 9 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ACE Working Group L. Seitz 3 SICS Swedish ICT 4 Internet-Draft F. Palombini 5 Intended Status: Standards Track Ericsson AB 6 Expires: May 4, 2017 October 31, 2016 8 OSCOAP profile of ACE 9 draft-seitz-ace-oscoap-profile-01 11 Abstract 13 This memo specifies a profile for the ACE framework for 14 Authentication and Authorization. It utilizes Object Security of 15 CoAP (OSCOAP) and Ephemeral Diffie-Hellman over COSE (EDHOC) to 16 provide communication security, server authentication, and proof-of- 17 possession for a key owned by the client and bound to an OAuth 2.0 18 access token. 20 Status of this Memo 22 This Internet-Draft is submitted to IETF in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that 27 other groups may also distribute working documents as 28 Internet-Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress". 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/1id-abstracts.html 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html 41 Copyright and License Notice 43 Copyright (c) 2016 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Client to Resource Server . . . . . . . . . . . . . . . . . . . 4 61 2.1. Signaling the use of OSCOAP . . . . . . . . . . . . . . . . 4 62 2.2. Key establishment for OSCOAP . . . . . . . . . . . . . . . 4 63 3. Client to Authorization Server . . . . . . . . . . . . . . . . 11 64 4. Resource Server to Authorization Server . . . . . . . . . . . . 11 65 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 12 66 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 12 67 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 68 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 69 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 70 9.1 Normative References . . . . . . . . . . . . . . . . . . . 12 71 9.2 Informative References . . . . . . . . . . . . . . . . . . 13 72 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13 74 1. Introduction 76 This memo specifies a profile of the ACE framework [I-D.ietf-ace- 77 oauth-authz]. In this profile, a client and a resource server use 78 CoAP [RFC7252] to communicate. The client uses an access token, 79 bound to a key (the proof-of-possession key) to authorize its access 80 to the resource server. In order to provide communication security, 81 proof of possession, and server authentication they use Object 82 Security of CoAP (OSCOAP) [I-D.ietf-core-object-security] and 83 Ephemeral Diffie-Hellman Over COSE (EDHOC) [I-D.selander-ace-cose- 84 ecdhe]. Optionally the client and the resource server may also use 85 CoAP and OSCOAP to communicate with the authorization server. The 86 use of EDHOC in this profile in addition to OSCOAP, provides perfect 87 forward secrecy (PFS) and the initial proof-of-possession, which ties 88 the proof-of-possession key to an OSCOAP security context. 90 OSCOAP specifies how to use CBOR Object Signing and Encryption (COSE) 91 [I-D.ietf-cose-msg] to secure CoAP messages. In order to provide 92 replay and reordering protection OSCOAP also introduces sequence 93 numbers that are used together with COSE. EDHOC specifies an 94 authenticated Diffie-Hellman protocol that allows two parties to use 95 CBOR [RFC7049] and COSE in order to establish a shared secret key 96 with perfect forward secrecy. 98 1.1 Terminology 100 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 101 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 102 document are to be interpreted as described in [RFC2119]. These 103 words may also appear in this document in lowercase, absent their 104 normative meanings. 106 Certain security-related terms such as "authentication", 107 "authorization", "confidentiality", "(data) integrity", "message 108 authentication code", and "verify" are taken from [RFC4949]. 110 Since we describe exchanges as RESTful protocol interactions HTTP 111 [RFC7231] offers useful terminology. 113 Terminology for entities in the architecture is defined in OAuth 2.0 114 [RFC6749] and [I-D.ietf-ace-actors], such as client (C), resource 115 server (RS), and authorization server (AS). 117 Note that the term "endpoint" is used here following its OAuth 118 definition, which is to denote resources such as /token and 119 /introspect at the AS and /authz-info at the RS. The CoAP [RFC7252] 120 definition, which is "An entity participating in the CoAP protocol" 121 is not used in this memo. 123 2. Client to Resource Server 125 The use of OSCOAP for arbitrary CoAP messages is specified in [I- 126 D.ietf-core-object-security]. This section defines the specific uses 127 and their purpose for securing the communication between a client and 128 a resource server, and the parameters for to negotiating the use of 129 this profile with the token endpoint at the authorization server as 130 specified in section 6 of the ACE framework [I-D.ietf-ace-oauth- 131 authz]. 133 2.1. Signaling the use of OSCOAP 135 A client requests a token at an AS via the /token endpoint. This 136 follows the message formats specified in section 6.1 of the ACE 137 framework [I-D.ietf.ace-oauth-authz]. 139 The AS responding to a successful access token request as defined in 140 section 6.2 of the ACE framework can signal that the use of OSCOAP is 141 REQUIRED for a specific access token by including the "profile" 142 parameter with the value "coap_oscoap" in the access token response. 143 This means that the client MUST use OSCOAP towards all resource 144 servers for which this access token is valid. 146 The error response procedures defined in section 6.3 of the ACE 147 framework are unchanged by this profile. 149 Note the the client and the authorization server MAY OPTIONALLY use 150 OSCOAP to protect the interaction via the /token endpoint. See 151 section 3 for details. 153 2.2. Key establishment for OSCOAP 155 Section 3.2 of OSCOAP [I-D.ietf-core-object-security] defines how to 156 derive a security context based on a symmetric base_key and a few 157 other parameters, established between client and server. The proof- 158 of-possession key (pop-key) provisioned from the AS MAY, in case of 159 pre-shared keys, be used directly as base_key in OSCOAP. 160 Alternatively the pop-key (symmetric or asymmetric) MAY be used to 161 authenticate the messages in the key exchange protocol EDHOC [I- 162 D.selander-ace-cose-ecdhe], from which a base_key is derived. 164 If OSCOAP is used directly with the symmetric pop-key as base_key, 165 then the AS MUST provision the following data, in response to the 166 access token request: 168 o a symmetric key (pop-key) 169 o a context identifier 170 o an AEAD algorithm 171 o the sender identifier 172 o the recipient identifier 174 The pop-key MUST be communicated as COSE_Key in the 'cnf' parameter 175 of the access token response as defined in section 6.2. of [I-D.ietf- 176 ace-oauth-authz]. The 'kid' parameter of this COSE_Key MUST be used 177 as the context identifier. The AEAD algorithm MUST be included as 178 the 'alg' parameter of the COSE_key. The same parameters MUST be 179 included as metadata of the access token, if the token is a CWT [I- 180 D.ietf-ace-cbor-web-token], the same COSE_Key structure MUST be 181 placed in the 'cnf' claim of this token. The AS MUST also assign 182 identifiers to both client and RS, which are then used as Sender ID 183 and Recipient ID in the OSCOAP context as described in section 3.1. 184 of [I-D.ietf-core-object-security]. These MUST be included in the 185 COSE_Key as header parameters, as defined in table 1. 187 Note that C should receive the client id as 'sid' and the RS id as 188 'rid', while the RS should receive the RS id as 'sid' and the client 189 id as 'rid'. 191 +---------+-------+----------------+------------+-------------------+ 192 | name | label | CBOR type | registry | description | 193 +---------+-------+----------------+------------+-------------------+ 194 | sid | TBD | bstr | | Identifies the | 195 | | | | | sender in an | 196 | | | | | OSCOAP context | 197 | | | | | using this key | 198 | | | | | | 199 | rid | TBD | bstr | | Identifies the | 200 | | | | | recipient in an | 201 | | | | | OSCOAP context | 202 | | | | | using this key | 203 +---------+-------+----------------+------------+-------------------+ 205 Table 1: Additional common header parameters for COSE_Key 207 Figure 1 shows an example of such an AS response, in CBOR diagnostic 208 notation without the tag and value abbreviations. 210 Header: Created (Code=2.01) 211 Content-Type: "application/cose+cbor" 212 Payload: 213 { 214 "access_token" : b64'SlAV32hkKG ... 215 (remainder of access token omitted for brevity)', 216 "profile" : "coap_oscoap", 217 "expires_in" : "3600", 218 "cnf" : { 219 "COSE_Key" : { 220 "kty" : "Symmetric", 221 "kid" : b64'5tOS+h42dkw', 222 "alg" : "AES-CCM-16-64-128", 223 "sid" : b64'qA', 224 "cid" : b64'Qg', 225 "k" : b64'+a+Dg2jjU+eIiOFCa9lObw' 226 } 227 } 228 } 230 Figure 1: Example AS response with OSCOAP parameters. 232 Figure 2 shows an example CWT, containing the necessary OSCOAP 233 parameters in the 'cnf' claim, in CBOR diagnostic notation without 234 tag and value abbreviations. 236 { 237 "aud" : "tempSensorInLivingRoom", 238 "iat" : "1360189224", 239 "exp" : "1360289224", 240 "scope" : "temperature_g firmware_p", 241 "cnf" : { 242 "COSE_Key" : { 243 "kty" : "Symmetric", 244 "kid" : b64'5tOS+h42dkw', 245 "alg" : "AES-CCM-16-64-128", 246 "sid" : b64'Qg', 247 "cid" : b64'qA', 248 "k" : b64'+a+Dg2jjU+eIiOFCa9lObw' 249 } 250 } 252 Figure 2: Example CWT with OSCOAP parameters. 254 If EDHOC is used together with OSCOAP, and the pop-key (symmetric or 255 asymmetric) is used to authenticate the messages in EDHOC, then the 256 AS MUST provision the following data, in response to the access token 257 request: 259 o a symmetric or asymmetric key (pop-key) 260 o if the pop-key is symmetric, a key identifier; 262 How these parameters are communicated depends on the type of key 263 (asymmetric or symmetric). 265 In case of an asymmetric key, C MUST communicate the key to the AS in 266 the 'cnf' parameter of the access token request, as specified in 267 section 6.1 of [I-D.ietf-ace-oauth-authz]. 269 Figure 3 shows an example of such a request in CBOR diagnostic 270 notation without tag and value abbreviations. 272 Header: POST (Code=0.02) 273 Uri-Host: "server.example.com" 274 Uri-Path: "token" 275 Content-Type: "application/cose+cbor" 276 Payload: 277 { 278 "grant_type" : "client_credentials", 279 "cnf" : { 280 "COSE_Key" : { 281 "kty" : "EC", 282 "crv" : "P-256", 283 "x" : b64'usWxHK2PmfnHKwXPS54m0kTcGJ90UiglWiGahtagnv8', 284 "y" : b64'IBOL+C3BttVivg+lSreASjpkttcsz+1rb7btKLv8EX4' 285 } 286 } 287 } 289 Figure 3: Example access token request with asymmetric pop key. 291 In the case of a symmetric key, the AS MUST communicate the key to 292 the client in the 'cnf' parameter of the access token response, as 293 specified in section 6.2. of [I-D.ietf-ace-oauth-authz]. AS MUST 294 also select a key identifier, that MUST be included as the 'kid' 295 parameter either directly in the 'cnf' structure, as in figure 4 of 296 [I-D.ietf-ace-oauth-authz], or as the 'kid' parameter of the 297 COSE_key, as in figure 3 of [I-D.ietf-ace-oauth-authz]. 299 Figure 4 shows an example of the necessary parameters in the AS 300 response to the access token request when EDHOC is used. The example 301 uses CBOR diagnostic notation without tag and value abbreviations. 303 Header: Created (Code=2.01) 304 Content-Type: "application/cose+cbor" 305 Payload: 306 { 307 "access_token" : b64'SlAV32hkKG ... 308 (remainder of access token omitted for brevity)', 309 "profile" : "coap_oscoap", 310 "expires_in" : "3600", 311 "cnf" : { 312 "COSE_Key" : { 313 "kty" : "Symmetric", 314 "kid" : b64'5tOS+h42dkw', 315 "k" : b64'+a+Dg2jjU+eIiOFCa9lObw' 316 } 317 } 318 } 320 Figure 4: Example AS response with EDHOC+OSCOAP parameters. 322 In both cases, the AS MUST also include the same key identifier as 323 'kid' parameter in the access token metadata. If the access token is 324 a CWT [I-D.ietf-ace-cbor-web-token], the key identifier MUST be 325 placed inside the 'cnf' claim as 'kid' parameter of the COSE_Key or 326 directly in the 'cnf' structure (if the key is only referenced). 328 Figure 5 shows an example CWT containing the necessary EDHOC+OSCOAP 329 parameters in the 'cnf' claim, in CBOR diagnostic notation without 330 tag and value abbreviations. 332 { 333 "aud" : "tempSensorInLivingRoom", 334 "iat" : "1360189224", 335 "exp" : "1360289224", 336 "scope" : "temperature_g firmware_p", 337 "cnf" : { 338 "COSE_Key" : { 339 "kty" : "Symmetric", 340 "kid" : b64'5tOS+h42dkw', 341 "k" : b64'+a+Dg2jjU+eIiOFCa9lObw' 342 } 343 } 345 Figure 5: Example CWT with EDHOC+OSCOAP parameters. 347 All other parameters defining OSCOAP security context are derived 348 from EDHOC message exchange, including the base_key (see Appendix B 349 of [I-D.ietf-core-object-security]). 351 To provide forward secrecy and mutual authentication in the case of 352 pre-shared keys, pre-established raw public keys or with X.509 353 certificates it is RECOMMENDED to use EDHOC [I-D.selander-ace-cose- 354 ecdhe] to generate the keying material. EDHOC MUST be used as 355 defined in Appendix B, with the following additions and 356 modifications. 358 The first CoAP message is sent to the RS using the /authz-info 359 endpoint as specified in section 8.1 of the ACE framework. This 360 message MUST carry message_1 of the EDHOC protocol (section 4.1.1. if 361 asymmetric keys are used or 5.1.1. if symmetric keys are used of [I- 362 D.selander-ace-cose-ecdhe]) in the CoAP payload, and the access token 363 MUST be added to the message_1 CBOR map, with the label 364 'access_token' (Figure 11 of [I-D.ietf-ace-oauth-authz]). An example 365 can be seen in the first message (POST) of Figure 1. 367 Before the RS continues with the EDHOC protocol and responds to this 368 token submission request, additional verifications on the access 369 token are done: the RS SHALL process the access token according to 370 [I-D.ietf-ace-oauth-authz]. If the token is valid then the RS 371 continues processing EDHOC following Appendix B of [I-D.selander-ace- 372 cose-ecdhe], else it discontinues EDHOC and responds with the error 373 code as specified in [I-D.ietf-ace-oauth-authz]. 375 When the RS receives an OSCOAP message including a field with label 376 'edhoc_m3' in the unprotected Headers of the COSE object, it SHALL 377 follow the process described in Appendix B of [I-D.selander-ace-cose- 378 ecdhe]. If the OSCOAP message was valid, the RS SHALL also verify 379 that the client is authorized to perform the requested action on the 380 requested resource using the previously received access token. 382 o In case the EDHOC verification fails, the RS MUST return an 383 error response to the client with code 4.01 (Unauthorized). 385 o If RS has an access token for C but not for the resource that C 386 has requested, RS MUST reject the request with a 4.03 (Forbidden). 388 o If RS has an access token for C but it does not cover the 389 action C requested on the resource, RS MUST reject the request with a 390 4.05 (Method Not Allowed). 392 If all verifications above succeeds, further communication between 393 client and RS is protected with OSCOAP, including the RS response to 394 the OSCOAP request. 396 In the case of EDHOC being used with symmetric pop-keys, the protocol 397 in section 5 of [I-D.selander-ace-cose-ecdhe] MUST be used. If the 398 pop-key is asymmetric, the RS MUST also use an asymmetric key for 399 authentication. This key is known to the client through the access 400 token response (see section 6.2 of the ACE framework). In this case 401 the protocol in section 4 of [I-D.selander-ace-cose-ecdhe] MUST be 402 used. 404 Note that if the OSCOAP profile is used, the /authz-info endpoint at 405 the Resource Server MUST be prepared to process and generate the 406 protocol messages of the EDHOC protocol as specified above. Hence 407 the use of EDHOC does not add any additional roundtrips to the ACE 408 message exchange. 410 Figure 6 illustrates the message exchanges for using EDHOC on the 411 /authz-info endpoint (step C in figure 1 of [I-D.ietf-ace-oauth- 412 authz]). 414 Resource 415 Client Server 416 | | 417 | | 418 +--------->| Header: POST (Code=0.02) 419 | POST | Uri-Path:"authz-info" 420 | | Content-Type: application/cbor 421 | | Payload: EDHOC message_1 + access token 422 | | 423 |<---------+ Header: 2.04 Changed 424 | | Content-Type: application/cose+cbor 425 | 2.05 | Payload: EDHOC message_2 426 | | 427 | | 428 +--------->| CoAP request + 429 | OSCOAP | Object-Security option 430 | request | COSE_Encrypt0: 431 | | unprotected Header: EDHOC message_3 432 | | 433 |<---------+ CoAP response + 434 | OSCOAP | Object-Security option 435 | response | 436 | | 438 Figure 6: Key establishment with EDHOC via the authz-info endpoint 440 Figure 7 shows an example of message_1 with an access token embedded 441 in the unprotected header. 443 { 444 'N_U' : h'5598a57b47db7f2c', 445 'E_U' : h'a120a50102024478f679012001215 446 82098f50a4ff6c05861c8860d13a6 447 38ea56c3f5ad7590bbfbf054e1c7b 448 4d91d628022f5', # COSE_Key 449 'ALG_U' : [ 450 [ -27 ], # ECDH-SS + HKDF-256 451 [ 12 ], # AES-CCM-64-64-128 452 [ -7 ], # ES256 453 [ 4 ] # HMAC 256/64 454 ], 455 18 : h'4a5015df6864286979' 456 } 458 Figure 7: diagnostic notation of EDHOC message_1 with an access token 460 N_U, E_U, and ALG_U, as defined in [I-D.selander-ace-cose-ecdhe], are 461 the freshness nonce for party U, the ECDH ephemeral public keys of 462 party U, and the proposed set of algorithms to be negotiated, 463 respectively. 465 3. Client to Authorization Server 467 As specified in the ACE framework section 5 [I-D.ietf-ace-oauth- 468 authz], the Client and AS can also use CoAP instead of HTTP to 469 communicate via the token endpoint. This section specifies how to 470 use OSCOAP between Client and AS together with CoAP. The use of 471 OSCOAP for this communication is OPTIONAL in this profile, other 472 security protocols (such as DTLS) MAY be used instead. 474 The client and the AS are expected to have pre-established 475 credentials (e.g. raw public keys). How these credentials are 476 established is out of scope for this profile. Furthermore the client 477 and the AS communicate using CoAP through the token endpoint as 478 specified in section 6 of [I-D.ietf-ace-oauth-authz]. At first point 479 of contact, prior to making the token request and response, the 480 client and the AS MAY perform an EDHOC exchange with the pre- 481 established credentials to create forward secret keying material for 482 use with OSCOAP. Subsequent requests and the responses MUST be 483 protected with OSCOAP. 485 4. Resource Server to Authorization Server 487 As specified in the ACE framework section 5 [I-D.ietf-ace-oauth- 488 authz], the RS and AS can also use CoAP instead of HTTP to 489 communicate via the introspection endpoint. This section specifies 490 how to use OSCOAP between RS and AS together with CoAP. The use of 491 OSCOAP for this communication is OPTIONAL in this profile, other 492 security protocols (such as DTLS) MAY be used instead. 494 The RS and the AS are expected to have pre-established credentials 495 (e.g. symmetric keys). How these credentials are established is out 496 of scope for this profile. Furthermore the RS and the AS communicate 497 using CoAP through the introspection endpoint as specified in section 498 7 of [I-D.ietf-ace-oauth-authz]. At first point of contact, prior to 499 making the introspection request and response, the RS and the AS MAY 500 perform an EDHOC exchange with the pre-established credentials to 501 create forward secret keying material for use with OSCOAP. 502 Subsequent requests and the responses MUST be protected with OSCOAP. 504 5. Security Considerations 506 TBD. 508 6. Privacy Considerations 510 TBD. 512 7. IANA Considerations 514 TBD. 'coap_oscoap' as profile id. Header parameters 'sid' and 'rid' 515 for COSE_Key. 517 8. Acknowledgements 519 The author wishes to thank Goeran Selander for the input on this 520 memo. The error responses specified in section 2.2. were originally 521 specified by Gerdes et al. in [I-D.gerdes-ace-dcaf-authorize]. 523 9. References 525 9.1 Normative References 527 [I-D.ietf-core-object-security] 528 Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 529 "Object Security of CoAP (OSCOAP)", draft-ietf-core- 530 object-security-00 (work in progress), October 2016. 532 [I-D.selander-ace-cose-ecdhe] 533 Selander, G., Mattsson, J., and F. Palombini, "Ephemeral 534 Diffie-Hellman Over COSE (EDHOC)", draft-selander-ace- 535 cose-ecdhe-04 (work in progress), October 2016. 537 [I-D.ietf-cose-msg] 538 Schaad, J., "CBOR Object Signing and Encryption (COSE)", 539 draft-ietf-cose-msg-23 (work in progress), October 2016. 541 [I-D.ietf-ace-oauth-authz] 542 Seitz, L., Selander, G., Wahlstroem, E., Erdtmann, S., and 543 H. Tschofenig. "Authentication and Authorization for 544 Constrained Environments (ACE)", draft-ietf-ace-oauth- 545 authz-04 (work in progress), October 2016. 547 [I-D.ietf-ace-cbor-web-token] Wahlstroem, E., Jones, M., Tschofenig, 548 H., and S. Erdtman. "CBOR Web Token (CWT)", draft-ietf- 549 ace-cbor-web-token-01 (work in progress), July 2016. 551 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 552 Requirement Levels", BCP 14, RFC 2119, DOI 553 10.17487/RFC2119, March 1997, . 556 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 557 Application Protocol (CoAP)", RFC 7252, DOI 558 10.17487/RFC7252, June 2014, . 561 9.2 Informative References 563 [I-D.gerdes-ace-actors] 564 Gerdes, S., Seitz, L., Selander, G., and C. Bormann (ed). 565 "An Arhitecture for Authorization in Constrained 566 Environments", draft-ietf-ace-actors-03 (work in 567 progress), March 2016. 569 [I-D.gerdes-ace-dcaf-authorize] 570 Gerdes, S., Bergmann, O., Bormann C. "Delegated CoAP 571 Authentication and Authorization Framework (DCAF)", draft- 572 gerdes-ace-dcaf-authorize-04 (work in progress), October 573 2015. 575 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", FYI 576 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, 577 . 579 [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", 580 RFC 6749, DOI 10.17487/RFC6749, October 2012, 581 . 583 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 584 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 585 October 2013, . 587 [RFC7231] Fielding, R., Ed., and J. Reschke, Ed., "Hypertext 588 Transfer Protocol (HTTP/1.1): Semantics and Content", 589 RFC 7231, DOI 10.17487/RFC7231, June 2014, 590 . 592 Author's Address 593 Ludwig Seitz 594 SICS Swedish ICT AB 595 Scheelevagen 17 596 22370 Lund 597 SWEDEN 598 EMail: ludwig@sics.se 600 Francesca Palombini 601 Ericsson AB 602 Farogatan 6 603 SE-16480 Stockholm 604 SWEDEN 605 EMail: francesca.palombini@ericsson.com