idnits 2.17.1 draft-seitz-ace-oscoap-profile-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 (May 3, 2017) is 2549 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) -- Looks like a reference, but probably isn't: '1' on line 452 == Outdated reference: A later version (-16) exists of draft-ietf-core-object-security-02 == Outdated reference: A later version (-14) exists of draft-selander-ace-cose-ecdhe-06 == Outdated reference: A later version (-46) exists of draft-ietf-ace-oauth-authz-06 == Outdated reference: A later version (-15) exists of draft-ietf-ace-cbor-web-token-04 == Outdated reference: A later version (-07) exists of draft-ietf-ace-actors-05 -- 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: 0 errors (**), 0 flaws (~~), 6 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ACE Working Group L. Seitz 3 Internet-Draft M. Gunnarsson 4 Intended Status: Standards Track RISE SICS AB 5 Expires: November 4, 2017 F. Palombini 6 Ericsson AB 7 May 3, 2017 9 OSCOAP profile of ACE 10 draft-seitz-ace-oscoap-profile-02 12 Abstract 14 This memo specifies a profile for the ACE framework for 15 Authentication and Authorization. It utilizes Object Security of 16 CoAP (OSCOAP) and Ephemeral Diffie-Hellman over COSE (EDHOC) to 17 provide communication security, server authentication, and proof-of- 18 possession for a key owned by the client and bound to an OAuth 2.0 19 access token. 21 Status of this Memo 23 This Internet-Draft is submitted to IETF in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF), its areas, and its working groups. Note that 28 other groups may also distribute working documents as 29 Internet-Drafts. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress". 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/1id-abstracts.html 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html 42 Copyright and License Notice 44 Copyright (c) 2017 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Client to Resource Server . . . . . . . . . . . . . . . . . . . 4 62 2.1. Signaling the use of OSCOAP . . . . . . . . . . . . . . . . 4 63 2.2. Key establishment for OSCOAP . . . . . . . . . . . . . . . 4 64 3. Client to Authorization Server . . . . . . . . . . . . . . . . 11 65 4. Resource Server to Authorization Server . . . . . . . . . . . . 11 66 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 12 67 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 12 68 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 69 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 70 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 71 9.1 Normative References . . . . . . . . . . . . . . . . . . . 12 72 9.2 Informative References . . . . . . . . . . . . . . . . . . 13 73 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14 75 1. Introduction 77 This memo specifies a profile of the ACE framework [I-D.ietf-ace- 78 oauth-authz]. In this profile, a client and a resource server use 79 CoAP [RFC7252] to communicate. The client uses an access token, 80 bound to a key (the proof-of-possession key) to authorize its access 81 to the resource server. In order to provide communication security, 82 proof of possession, and server authentication they use Object 83 Security of CoAP (OSCOAP) [I-D.ietf-core-object-security] and 84 Ephemeral Diffie-Hellman Over COSE (EDHOC) [I-D.selander-ace-cose- 85 ecdhe]. Optionally the client and the resource server may also use 86 CoAP and OSCOAP to communicate with the authorization server. The 87 use of EDHOC in this profile in addition to OSCOAP, provides perfect 88 forward secrecy (PFS) and the initial proof-of-possession, which ties 89 the proof-of-possession key to an OSCOAP security context. 91 OSCOAP specifies how to use CBOR Object Signing and Encryption (COSE) 92 [I-D.ietf-cose-msg] to secure CoAP messages. In order to provide 93 replay and reordering protection OSCOAP also introduces sequence 94 numbers that are used together with COSE. EDHOC specifies an 95 authenticated Diffie-Hellman protocol that allows two parties to use 96 CBOR [RFC7049] and COSE in order to establish a shared secret key 97 with perfect forward secrecy. 99 1.1 Terminology 101 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 102 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 103 document are to be interpreted as described in [RFC2119]. These 104 words may also appear in this document in lowercase, absent their 105 normative meanings. 107 Certain security-related terms such as "authentication", 108 "authorization", "confidentiality", "(data) integrity", "message 109 authentication code", and "verify" are taken from [RFC4949]. 111 Since we describe exchanges as RESTful protocol interactions HTTP 112 [RFC7231] offers useful terminology. 114 Terminology for entities in the architecture is defined in OAuth 2.0 115 [RFC6749] and [I-D.ietf-ace-actors], such as client (C), resource 116 server (RS), and authorization server (AS). 118 Note that the term "endpoint" is used here following its OAuth 119 definition, which is to denote resources such as /token and 120 /introspect at the AS and /authz-info at the RS. The CoAP [RFC7252] 121 definition, which is "An entity participating in the CoAP protocol" 122 is not used in this memo. 124 2. Client to Resource Server 126 The use of OSCOAP for arbitrary CoAP messages is specified in [I- 127 D.ietf-core-object-security]. This section defines the specific uses 128 and their purpose for securing the communication between a client and 129 a resource server, and the parameters needed to negotiate the use of 130 this profile with the token endpoint at the authorization server as 131 specified in section 5.5 of the ACE framework [I-D.ietf-ace-oauth- 132 authz]. 134 2.1. Signaling the use of OSCOAP 136 A client requests a token at an AS via the /token endpoint. This 137 follows the message formats specified in section 5.5.1 of the ACE 138 framework [I-D.ietf.ace-oauth-authz]. 140 The AS responding to a successful access token request as defined in 141 section 5.5.2 of the ACE framework can signal that the use of OSCOAP 142 is REQUIRED for a specific access token by including the "profile" 143 parameter with the value "coap_oscoap" in the access token response. 144 This means that the client MUST use OSCOAP towards all resource 145 servers for which this access token is valid. 147 The error response procedures defined in section 5.5.3 of the ACE 148 framework are unchanged by this profile. 150 Note the the client and the authorization server MAY OPTIONALLY use 151 OSCOAP to protect the interaction via the /token endpoint. See 152 section 3 for details. 154 2.2. Key establishment for OSCOAP 156 Section 3.2 of OSCOAP [I-D.ietf-core-object-security] defines how to 157 derive a security context based on a symmetric master secret and a 158 few other parameters, established between client and server. The 159 proof-of-possession key (pop-key) provisioned from the AS MAY, in 160 case of pre-shared keys, be used directly as master secret in OSCOAP. 161 Alternatively the pop-key (symmetric or asymmetric) MAY be used to 162 authenticate the messages in the key exchange protocol EDHOC [I- 163 D.selander-ace-cose-ecdhe], from which a master secret is derived. 165 If OSCOAP is used directly with the symmetric pop-key as master 166 secret, then the AS MUST provision the following data, in response to 167 the access token request: 169 o a symmetric key (pop-key) 170 o an AEAD algorithm 171 o a KDF algorithm 172 o the sender identifier 173 o the recipient identifier 175 The pop-key MUST be communicated as COSE_Key in the 'cnf' parameter 176 of the access token response as defined in section 5.5.4.5 of [I- 177 D.ietf-ace-oauth-authz]. The AEAD algorithm MUST be included as the 178 '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 "alg" : "AES-CCM-16-64-128", 222 "sid" : b64'qA', 223 "rid" : b64'Qg', 224 "k" : b64'+a+Dg2jjU+eIiOFCa9lObw' 225 } 226 } 227 } 229 Figure 1: Example AS response with OSCOAP parameters. 231 Figure 2 shows an example CWT, containing the necessary OSCOAP 232 parameters in the 'cnf' claim, in CBOR diagnostic notation without 233 tag and value abbreviations. 235 { 236 "aud" : "tempSensorInLivingRoom", 237 "iat" : "1360189224", 238 "exp" : "1360289224", 239 "scope" : "temperature_g firmware_p", 240 "cnf" : { 241 "COSE_Key" : { 242 "kty" : "Symmetric", 243 "alg" : "AES-CCM-16-64-128", 244 "sid" : b64'Qg', 245 "rid" : b64'qA', 246 "k" : b64'+a+Dg2jjU+eIiOFCa9lObw' 247 } 248 } 250 Figure 2: Example CWT with OSCOAP parameters. 252 If EDHOC is used together with OSCOAP, and the pop-key (symmetric or 253 asymmetric) is used to authenticate the messages in EDHOC, then the 254 AS MUST provision the following data, in response to the access token 255 request: 257 o a symmetric or asymmetric key (pop-key) 258 o if the pop-key is symmetric, a key identifier; 260 How these parameters are communicated depends on the type of key 261 (asymmetric or symmetric). 263 In case of an asymmetric key, C MUST communicate the key to the AS in 264 the 'cnf' parameter of the access token request, as specified in 265 section 5.5.1 of [I-D.ietf-ace-oauth-authz]. 267 Figure 3 shows an example of such a request in CBOR diagnostic 268 notation without tag and value abbreviations. 270 Header: POST (Code=0.02) 271 Uri-Host: "server.example.com" 272 Uri-Path: "token" 273 Content-Type: "application/cose+cbor" 274 Payload: 275 { 276 "grant_type" : "client_credentials", 277 "cnf" : { 278 "COSE_Key" : { 279 "kty" : "EC", 280 "crv" : "P-256", 281 "x" : b64'usWxHK2PmfnHKwXPS54m0kTcGJ90UiglWiGahtagnv8', 282 "y" : b64'IBOL+C3BttVivg+lSreASjpkttcsz+1rb7btKLv8EX4' 283 } 284 } 285 } 287 Figure 3: Example access token request with asymmetric pop key. 289 In the case of a symmetric key, the AS MUST communicate the key to 290 the client in the 'cnf' parameter of the access token response, as 291 specified in section 5.5.2. of [I-D.ietf-ace-oauth-authz]. AS MUST 292 also select a key identifier, that MUST be included as the 'kid' 293 parameter either directly in the 'cnf' structure, as in figure 4 of 294 [I-D.ietf-ace-oauth-authz], or as the 'kid' parameter of the 295 COSE_key, as in figure 3 of [I-D.ietf-ace-oauth-authz]. 297 Figure 4 shows an example of the necessary parameters in the AS 298 response to the access token request when EDHOC is used. The example 299 uses CBOR diagnostic notation without tag and value abbreviations. 301 Header: Created (Code=2.01) 302 Content-Type: "application/cose+cbor" 303 Payload: 304 { 305 "access_token" : b64'SlAV32hkKG ... 306 (remainder of access token omitted for brevity)', 307 "profile" : "coap_oscoap", 308 "expires_in" : "3600", 309 "cnf" : { 310 "COSE_Key" : { 311 "kty" : "Symmetric", 312 "kid" : b64'5tOS+h42dkw', 313 "k" : b64'+a+Dg2jjU+eIiOFCa9lObw' 315 } 316 } 317 } 319 Figure 4: Example AS response with EDHOC+OSCOAP parameters. 321 In both cases, the AS MUST also include the same key identifier as 322 'kid' parameter in the access token metadata. If the access token is 323 a CWT [I-D.ietf-ace-cbor-web-token], the key identifier MUST be 324 placed inside the 'cnf' claim as 'kid' parameter of the COSE_Key or 325 directly in the 'cnf' structure (if the key is only referenced). 327 Figure 5 shows an example CWT containing the necessary EDHOC+OSCOAP 328 parameters in the 'cnf' claim, in CBOR diagnostic notation without 329 tag and value abbreviations. 331 { 332 "aud" : "tempSensorInLivingRoom", 333 "iat" : "1360189224", 334 "exp" : "1360289224", 335 "scope" : "temperature_g firmware_p", 336 "cnf" : { 337 "COSE_Key" : { 338 "kty" : "Symmetric", 339 "kid" : b64'5tOS+h42dkw', 340 "k" : b64'+a+Dg2jjU+eIiOFCa9lObw' 341 } 342 } 344 Figure 5: Example CWT with EDHOC+OSCOAP parameters. 346 All other parameters defining OSCOAP security context are derived 347 from EDHOC message exchange, including the master secret (see 348 Appendix C.2 of [I-D.selander-ace-cose-ecdhe]). 350 To provide forward secrecy and mutual authentication in the case of 351 pre-shared keys, pre-established raw public keys or with X.509 352 certificates it is RECOMMENDED to use EDHOC [I-D.selander-ace-cose- 353 ecdhe] to generate the keying material. EDHOC MUST be used as 354 defined in Appendix C, with the following additions and 355 modifications. 357 The first CoAP message is sent to the RS using the /authz-info 358 endpoint as specified in section 5.7.1 of the ACE framework. This 359 message MUST carry message_1 of the EDHOC protocol (section 4.2. if 360 asymmetric keys are used or 5.2. if symmetric keys are used of [I- 361 D.selander-ace-cose-ecdhe]) in the CoAP payload, and the access token 362 MUST be added to the message_1 APP_1 as an element in a serialized 363 CBOR map, with the label 'access_token' (Figure 11 of [I-D.ietf-ace- 364 oauth-authz]). An example can be seen in the first message (POST) of 365 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 C 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 C 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 5.5.2 of the ACE framework). In this 401 case the protocol in section 4 of [I-D.selander-ace-cose-ecdhe] MUST 402 be 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 412 /authz-info endpoint (step C in figure 1 of [I-D.ietf-ace-oauth- 413 authz]). 415 Resource 416 Client Server 417 | | 418 | | 419 +--------->| Header: POST (Code=0.02) 420 | POST | Uri-Path:"authz-info" 421 | | Content-Type: application/cbor 422 | | Payload: EDHOC message_1 + access token 423 | | 424 |<---------+ Header: 2.04 Changed 425 | | Content-Type: application/cose+cbor 426 | 2.05 | Payload: EDHOC message_2 427 | | 428 | | 429 +--------->| CoAP request + 430 | OSCOAP | Object-Security option 431 | request | COSE_Encrypt0: 432 | | unprotected Header: EDHOC message_3 433 | | 434 |<---------+ CoAP response + 435 | OSCOAP | Object-Security option 436 | response | 437 | | 439 Figure 6: Key establishment with EDHOC via the authz-info endpoint 441 Figure 7 shows an example of message_1 with an access token embedded 442 in the unprotected header. 444 [ 445 1, # message type 446 h'05c2dc' # session identifier 447 h'5598a57b47db7f2c', # random nonce 448 h'a120a50102024478f679012001215 449 82098f50a4ff6c05861c8860d13a6 450 38ea56c3f5ad7590bbfbf054e1c7b 451 4d91d628022f5', # COSE_Key 452 [1] # NIST P-256 453 [ -27 ], # ECDH-SS + HKDF-256 454 [ 12 ], # AES-CCM-64-64-128 455 [ -7 ], # ES256 456 [ -7 ], # ES256 457 h'a16c6163636573735f746f6b656e # APP_3: access token 458 ... 459 ] 461 Figure 7: diagnostic notation of EDHOC message_1 with an access token 463 3. Client to Authorization Server 465 As specified in the ACE framework section 5.5 [I-D.ietf-ace-oauth- 466 authz], the Client and AS can also use CoAP instead of HTTP to 467 communicate via the token endpoint. This section specifies how to 468 use OSCOAP between Client and AS together with CoAP. The use of 469 OSCOAP for this communication is OPTIONAL in this profile, other 470 security protocols (such as DTLS) MAY be used instead. 472 The client and the AS are expected to have pre-established 473 credentials (e.g. raw public keys). How these credentials are 474 established is out of scope for this profile. Furthermore the client 475 and the AS communicate using CoAP through the token endpoint as 476 specified in section 5.5 of [I-D.ietf-ace-oauth-authz]. At first 477 point of contact, prior to making the token request and response, the 478 client and the AS MAY perform an EDHOC exchange with the pre- 479 established credentials to create forward secret keying material for 480 use with OSCOAP. Subsequent requests and the responses MUST be 481 protected with OSCOAP. 483 4. Resource Server to Authorization Server 485 As specified in the ACE framework section 5.6 [I-D.ietf-ace-oauth- 486 authz], the RS and AS can also use CoAP instead of HTTP to 487 communicate via the introspection endpoint. This section specifies 488 how to use OSCOAP between RS and AS together with CoAP. The use of 489 OSCOAP for this communication is OPTIONAL in this profile, other 490 security protocols (such as DTLS) MAY be used instead. 492 The RS and the AS are expected to have pre-established credentials 493 (e.g. symmetric keys). How these credentials are established is out 494 of scope for this profile. Furthermore the RS and the AS communicate 495 using CoAP through the introspection endpoint as specified in section 496 5.6 of [I-D.ietf-ace-oauth-authz]. At first point of contact, prior 497 to making the introspection request and response, the RS and the AS 498 MAY perform an EDHOC exchange with the pre-established credentials to 499 create forward secret keying material for use with OSCOAP. 500 Subsequent requests and the responses MUST be protected with OSCOAP. 502 5. Security Considerations 504 TBD. 506 6. Privacy Considerations 508 TBD. 510 7. IANA Considerations 512 TBD. 'coap_oscoap' as profile id. Header parameters 'sid' and 'rid' 513 for COSE_Key. 515 8. Acknowledgments 517 The author wishes to thank Goeran Selander for the input on this 518 memo. The error responses specified in section 2.2. were originally 519 specified by Gerdes et al. in [I-D.gerdes-ace-dcaf-authorize]. 521 9. References 523 9.1 Normative References 525 [I-D.ietf-core-object-security] 526 Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 527 "Object Security of CoAP (OSCOAP)", draft-ietf-core- 528 object-security-02 (work in progress), March 2017. 530 [I-D.selander-ace-cose-ecdhe] 531 Selander, G., Mattsson, J., and F. Palombini, "Ephemeral 532 Diffie-Hellman Over COSE (EDHOC)", draft-selander-ace- 533 cose-ecdhe-06 (work in progress), April 2017. 535 [I-D.ietf-cose-msg] 536 Schaad, J., "CBOR Object Signing and Encryption (COSE)", 537 draft-ietf-cose-msg-24 (work in progress), November 2016. 539 [I-D.ietf-ace-oauth-authz] 540 Seitz, L., Selander, G., Wahlstroem, E., Erdtmann, S., and 541 H. Tschofenig. "Authentication and Authorization for 542 Constrained Environments (ACE)", draft-ietf-ace-oauth- 543 authz-06 (work in progress), March 2017. 545 [I-D.ietf-ace-cbor-web-token] Jones, M., Wahlstroem, E., Erdtman S. 546 and H. Tschofenig. "CBOR Web Token (CWT)", draft-ietf-ace- 547 cbor-web-token-04 (work in progress), April 2017. 549 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 550 Requirement Levels", BCP 14, RFC 2119, DOI 551 10.17487/RFC2119, March 1997, . 554 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 555 Application Protocol (CoAP)", RFC 7252, DOI 556 10.17487/RFC7252, June 2014, . 559 9.2 Informative References 561 [I-D.ietf-ace-actors] 562 Gerdes, S., Seitz, L., Selander, G., and C. Bormann (ed). 563 "An Architecture for Authorization in Constrained 564 Environments", draft-ietf-ace-actors-05 (work in 565 progress), March 2017. 567 [I-D.gerdes-ace-dcaf-authorize] 568 Gerdes, S., Bergmann, O., Bormann C. "Delegated CoAP 569 Authentication and Authorization Framework (DCAF)", draft- 570 gerdes-ace-dcaf-authorize-04 (work in progress), October 571 2015. 573 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", FYI 574 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, 575 . 577 [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", 578 RFC 6749, DOI 10.17487/RFC6749, October 2012, 579 . 581 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 582 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 583 October 2013, . 585 [RFC7231] Fielding, R., Ed., and J. Reschke, Ed., "Hypertext 586 Transfer Protocol (HTTP/1.1): Semantics and Content", 587 RFC 7231, DOI 10.17487/RFC7231, June 2014, 588 . 590 Author's Address 592 Ludwig Seitz 593 RISE SICS AB 594 Scheelevagen 17 595 22370 Lund 596 SWEDEN 597 EMail: ludwig.seitz@ri.se 599 Martin Gunnarsson 600 RISE SICS AB 601 Scheelevagen 17 602 22370 Lund 603 SWEDEN 604 EMail: martin.gunnarsson@ri.se 606 Francesca Palombini 607 Ericsson AB 608 Farogatan 6 609 SE-16480 Stockholm 610 SWEDEN 611 EMail: francesca.palombini@ericsson.com