idnits 2.17.1 draft-aragon-ace-ipsec-profile-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (July 3, 2017) is 2488 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) == Outdated reference: A later version (-46) exists of draft-ietf-ace-oauth-authz-06 == Outdated reference: A later version (-06) exists of draft-seitz-ace-oscoap-profile-03 == Outdated reference: A later version (-14) exists of draft-selander-ace-cose-ecdhe-06 ** Obsolete normative reference: RFC 4835 (Obsoleted by RFC 7321) ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) == Outdated reference: A later version (-07) exists of draft-ietf-ace-actors-05 == Outdated reference: A later version (-16) exists of draft-ietf-core-object-security-04 Summary: 2 errors (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ACE Working Group S. Aragon 3 Internet-Draft M. Tiloca 4 Intended status: Standards Track S. Raza 5 Expires: January 4, 2018 RISE SICS AB 6 July 3, 2017 8 IPsec profile of ACE 9 draft-aragon-ace-ipsec-profile-00 11 Abstract 13 This document defines a profile of the ACE framework for 14 authentication and authorization. It uses the IPsec protocol suite 15 and the IKEv2 protocol to ensure secure communication, server 16 authentication and proof-of-possession for a key bound to an OAuth 17 2.0 access token. The profile also defines an alternative key 18 management approach to establish IPsec Security Associations using 19 Ephemeral Diffie-Hellman Over COSE (EDHOC). 21 Status of This Memo 23 This Internet-Draft is submitted 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). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 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 This Internet-Draft will expire on January 4, 2018. 38 Copyright Notice 40 Copyright (c) 2017 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Methods for Setting Up SA Pairs . . . . . . . . . . . . . . . 4 58 2.1. The "ipsec" Structure . . . . . . . . . . . . . . . . . . 5 59 3. Protocol Description . . . . . . . . . . . . . . . . . . . . 6 60 3.1. Unauthorized Client to RS . . . . . . . . . . . . . . . . 7 61 3.2. Client to AS . . . . . . . . . . . . . . . . . . . . . . 8 62 3.2.1. Direct Provisioning of SA pairs . . . . . . . . . . . 8 63 3.2.2. SA Establishment Based of Symmetric Keys . . . . . . 9 64 3.2.3. SA Establishment Based on Asymmetric Keys . . . . . . 10 65 3.3. Client to RS . . . . . . . . . . . . . . . . . . . . . . 11 66 3.3.1. SA Direct Provisioning . . . . . . . . . . . . . . . 12 67 3.3.2. Authenticated SA Establishment . . . . . . . . . . . 12 68 3.4. RS to AS . . . . . . . . . . . . . . . . . . . . . . . . 13 69 4. Security Considerations . . . . . . . . . . . . . . . . . . . 13 70 4.1. Privacy Considerations . . . . . . . . . . . . . . . . . 13 71 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 72 5.1. CoAP-IPsec Profile registration . . . . . . . . . . . . . 14 73 5.2. Confirmation Methods registration . . . . . . . . . . . . 14 74 5.2.1. IPsec field . . . . . . . . . . . . . . . . . . . . . 14 75 5.2.2. Key Management Protocol field . . . . . . . . . . . . 14 76 5.3. Key Management Protocol Methods Registry . . . . . . . . 15 77 5.3.1. Registration Template . . . . . . . . . . . . . . . . 15 78 5.3.2. Initial Registry Contents . . . . . . . . . . . . . . 16 79 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 80 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 81 7.1. Normative References . . . . . . . . . . . . . . . . . . 16 82 7.2. Informative References . . . . . . . . . . . . . . . . . 17 83 Appendix A. Coexistence of OSCOAP and IPsec . . . . . . . . . . 18 84 Appendix B. SA Establishment with EDHOC . . . . . . . . . . . . 19 85 B.1. Client to AS . . . . . . . . . . . . . . . . . . . . . . 19 86 B.2. Client to RS . . . . . . . . . . . . . . . . . . . . . . 20 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 89 1. Introduction 91 The IPsec protocol suite [RFC4301] allows communications based on the 92 Constrained Application Protocol (CoAP) [RFC7252] to fulfill a number 93 of security goals at the network layer, i.e. integrity and IP 94 spoofing protection, confidentiality of traffic flows, and message 95 replay protection. In several resource-constrained platforms, this 96 can leverage security operations directly provided by hardware 97 crypto-modules, including mandatory-to-implement cipher suites 98 defined in [RFC4835]. 100 This document defines a profile of the ACE framework for 101 authentication and authorization [I-D.ietf-ace-oauth-authz], where a 102 client (C) and a resource server (RS) communicate using CoAP 103 [RFC7252] over IPsec [RFC4301]. In particular, C uses an Access 104 Token released by an Authorization Server (AS) and bound to a key 105 (proof-of-possession key) to authorize its access to RS and its 106 protected resources. 108 The establishment of an IPsec channel between C and RS provides 109 secure communication, proof-of-possession as well as RS and C mutual 110 authentication. Furthermore, this profile preserves the flexibility 111 of IPsec as to the selection of specific security protocols, i.e. 112 Encapsulating Security Payload (ESP) [RFC4303] and IP Authentication 113 Header (AH) [RFC4302], key management, and modes of operations, i.e. 114 tunnel or transport. Those parameters are specified in the IPsec 115 Security Association (SA) pair established between C and RS. 117 This specification supports different key management methods for 118 setting up SA pairs, namely direct provisioning of SA pairs and 119 establishment of SA pairs based on symmetric or asymmetric key 120 authentication. The latter approach can use the Internet Key 121 Exchange Protocol version 2 (IKEv2) [RFC7296] or the Ephemeral 122 Diffie-Hellman Over COSE (EDHOC) key exchange 123 [I-D.selander-ace-cose-ecdhe]. 125 1.1. Terminology 127 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 128 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 129 and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 130 [RFC2119] and indicate requirement levels for compliant CoAP-IPsec 131 profile implementations. 133 Readers are expected to be familiar with terminology such as client 134 (C), resource server (RS), authentication server (AS), and endpoint 135 which are defined in [RFC6749] and [I-D.ietf-ace-actors]. 137 The concept of IPsec Security Association (Section 4.1. of [RFC4301]) 138 plays a key role, and this profile uses it extensively. An SA 139 indicates how to secure a one-way communication between two parties. 140 Hence, two SAs are required to be created and coordinated, in order 141 to secure a two-way communication channel. This document refers to a 142 SA pair as the two IPsec SAs used to protect the two-way 143 communication channel between two IPsec peers. 145 The SA parameters described in section 4.4.2.1 of [RFC4301] are 146 divided into the following two sets. 148 o Network Parameters: the parameters defining the network properties 149 of the IPsec channel, e.g. DSCP filtering; 151 o Security Parameters: the parameters defining the security 152 properties of the IPsec channel. 154 This document refers to SA-C as the SA for securing communication 155 from C to RS, and to SA-RS as the SA for securing communication from 156 RS to C. Thus, a SA pair consists of an SA-C and an SA-RS. 158 2. Methods for Setting Up SA Pairs 160 The following key management methods are supported for setting up a 161 SA pair between C and RS. 163 1. Direct Provisoning (DP). The SA pair is pre-defined by the AS. 164 Then, SA-RS and SA-C are specified in the Access Token Response 165 and in the Access Token issued by the AS. 167 2. Establishment with symmetric key authentication. A symmetric 168 Pre-Shared Key (PSK) is used to authenticate both parties during 169 the SA pair establishment and is bound to the Access Token as 170 proof-of-possession key. If C is interacting for the first time 171 with the RS, then the AS MUST include a PSK and a unique key 172 identifier in the Access Token Response. Otherwise, C MUST 173 include the unique key identifier pointing at the previously 174 established PSK in the Access Token Request. 176 3. Establishment with asymmetric key authentication. An asymmetric 177 Raw Public Key (RPK) or Certificate-based Public Key (CPK) is 178 used to authenticate both parties during the SA pair 179 establishment and is bound to the Access Token as proof-of- 180 possession key. If the AS does not know C's asymmetric 181 authentication information, then C MUST include its RPK or CPK in 182 the Access Token Request. Otherwise, C MUST include a key 183 identifier linked to its own RPK or CPK available at the AS. 185 Every SA MUST include the following Security Parameters. 187 o A Security Parameter Index (SPI); 189 o IPsec protocol mode: tunnel or transport; 191 o Security protocol: AH or ESP; 192 o "AH-authentication", "ESP-encryption", "ESP-integrity" or "ESP- 193 combined" algorithm; 195 o Source and destination, if tunnel mode is selected; 197 o Cryptographic keys; 199 o SA lifetime. 201 As assumed in Section 5.5.2 of [I-D.ietf-ace-oauth-authz], the AS has 202 knowledge of C's and RS's capabilities, and of RS's preferred 203 communications settings. Therefore, the AS MUST set the values of 204 Security Parameters and Network Parameters in the SA pair. 206 2.1. The "ipsec" Structure 208 This document defines the "ipsec" structure as a field of the "cnf" 209 parameter of the Access Token and Access Token Response. This 210 structure encodes the Network and Security Parameters of the SA pair 211 as defined in Figure 1. The Network Parameters are not discussed in 212 this specification. 214 ipsec{ 215 , 216 217 } 219 Figure 1: "ipsec" structure overview. 221 The AS builds the "ipsec" structure as follows: 223 o The Security Parameters MUST always include the set of parameters 224 sec_A shown in Figure 2. 226 o The Security Parameters MUST include the set of parameters sec_B 227 shown in Figure 3 if the AS uses the Direct Provisioning method. 229 sec_A{ 230 mode, 231 protocol, 232 life, 233 IP_C, (if mode == tunnel) 234 IP_RS (if mode == tunnel) 235 } 237 Figure 2: Set sec_A of Security Parameters 239 sec_B{ 240 SPI_SA_C, 241 SPI_SA_RS, 242 alg, 243 seed 244 } 246 Figure 3: Set sec_B of Security Parameters 248 In sec_A, the IP_C field is the IP address of C, while IP_RS is the 249 IP address of RS. In tunnel mode, the RS MUST use IP_C as the 250 destination address and IP_RS as source address of outgoing IPsec 251 messages. Similarly, C MUST use IP_RS as destination address and 252 IP_C as source address of incoming IPsec messages. 254 In sec_B, the field "SPI_SA_C" is the SPI of SA-C. Similarly, 255 "SPI_SA_RS" is the SPI of SA-RS. The field "alg" indicates the 256 algorithm used for securing communications over IPsec. The "seed" 257 field MUST reflect the SKEYSEED secret defined in Section 2.14 of 258 [RFC7296]. Thus, C and RS MUST use the same key derivation 259 techniques to generate the necessary SA keys from "seed". 261 Note that if the Direct Provisioning method is used, the AS cannot 262 guarantee the uniqueness of the "SPI_SA_C" value at the RS and of the 263 "SPI_SA_RS" value at C. In such a case, the AS MUST randomly 264 generate the "SPI_SA_C" value and the "SPI_SA_RS" value, so that the 265 probability of a collision to occur is negligible. 267 If RS receives an "SPI_SA_C" value which results in a collision, then 268 RS MUST reply to C with en error response, and both C and RS MUST 269 abort the set up of the IPsec channel. In order to overcome this 270 issue, the AS can manage a pool of "SPI_SA_C" reserved values, 271 intended only for use with the Direct Provisioning method. Then, in 272 case of SA termination, the RS asks the AS to set back the identifier 273 of that SA-C as available. 275 If C receives an "SPI_SA_RS" value which results in a collision, then 276 C sends a second Token Request to the AS, asking for a Token Update. 277 This Token Request includes also an "ipsec" structure, which contains 278 only the field "SPI_SA_RS" specifying an available value to use. 279 Then, the AS replies with an Access Token and an Access Token 280 Response both updated as to the "SPI_SA_RS" value only. 282 3. Protocol Description 284 This profile considers a client C that intends to access a protected 285 resource hosted by a resource server RS. The resource access is 286 authorized through an Access Token issued by the AS as specified in 288 [I-D.ietf-ace-oauth-authz] and indicating that IPsec is used to 289 secure communications between C and RS. In particular, this profile 290 defines how C and RS set up a SA pair, using the key management 291 methods introduced in Section 2. 293 The protocol is composed of three parts, as shown in Figure 4. 295 C RS AS 296 | | | 297 | [------ Resource Request ------>] | | 298 (1) | | | 299 | [<------ AS Information --------] | | 300 | | | 301 --- | | | 302 | | | 303 | --------- Token Request ------------------------------> | 304 (2) | | | 305 | | 306 | Access Token + RS Information | 307 | <------------------------------------------------------ | 308 | Including information for IPsec SA establishment | 309 | | 310 --- | | | 311 | | | 312 | --------- Access Token ---------> | | 313 | | | 314 | [<=== IPsec SA establishment ==>] | | 315 (3) | | | 316 | ======== Resource Request ======> | | 317 | | | 318 | <======= Resource Response ====== | | 319 | | | 321 Figure 4: Protocol Overview 323 3.1. Unauthorized Client to RS 325 Phase (1) in Figure 4 is OPTIONAL and aims at providing C with the 326 necessary information to contact the AS, in case C does not know AS's 327 address. Through an unauthorized request to RS, C determines which 328 AS is responsible for granting authorization to that particular RS. 329 When doing so, C learns to which address the Access Token Request has 330 to be addressed. The unauthorized request is denied by RS, which 331 sends back to C a response containing the information to contact the 332 AS. 334 3.2. Client to AS 336 Phase (2) in Figure 4 starts with C sending the Access Token Request 337 to the /token endpoint at the AS, as specified in Section 5.5.1 of 338 [I-D.ietf-ace-oauth-authz]. Figure 2 and Figure 3 of 339 [I-D.ietf-ace-oauth-authz] provide examples of such request. 341 If the AS successfully verifies the Access Token Request and C is 342 authorized to access the resource specified in the Token Request, 343 then the AS issues the corresponding Access Token and includes it in 344 a CoAP response with code 2.01 (Created) as specified in 345 Section 5.5.2 of [I-D.ietf-ace-oauth-authz]. The AS can signal that 346 IPsec is REQUIRED to secure communications between C and RS by 347 including the "profile" parameter with the value "coap_ipsec" in the 348 Access Token Response. Together with authorization information, the 349 Access Token also includes the same information for the set up of the 350 IPsec channel included in the Access Token Response. The error 351 responses are handled as described in Section 5.5.3 of 352 [I-D.ietf-ace-oauth-authz]. 354 The information exchanged between C and the AS depends on the 355 specific method used to set up the SA pair (see Section 3.2.1, 356 Section 3.2.2 and Section 3.2.3). Note that, unless Direct 357 Provisioning of SAs is used, C and RS are required to finalize the SA 358 pair set up by running a Key Management Protocol such as IKEv2 (see 359 Section 3.3.2). The AS indicates to use IKEv2 for establishing a SA 360 pair by setting the "kmp" field to "ikev2" in the "cnf" parameter in 361 the Access Token Response. An alternative key management method 362 based on Ephemeral Diffie-Hellman Over COSE (EDHOC) 363 [I-D.selander-ace-cose-ecdhe] is described in Appendix B. 365 The communications between the AS and C (/token endpoint) rely on the 366 CoAP protocol and MUST be secured. In particular, they can be 367 secured by means of Object Security of OSCOAP 368 [I-D.ietf-core-object-security]} as described in section 5.5 of 369 [I-D.ietf-ace-oauth-authz], or through other means such as IPSec 370 [RFC4301] or DTLS [RFC6347]. 372 3.2.1. Direct Provisioning of SA pairs 374 If the AS selects this key management method, it encodes the SA pair 375 in the Access Token and in the Access Token Response as an "ipsec" 376 structure in the "cnf" parameter. 378 Figure 5 shows an example of an Access Token Response, signaling C to 379 set up an IPsec channel with RS based on the ESP protocol in 380 transport mode. 382 Header: Created (Code=2.01) 383 Content-Type: "application/cose+cbor" 384 Payload : { 385 "access_token" : b64'YiksuH&=1GFfg ... 386 (remainder of Access Token omitted for brevity)', 387 "profile" : "coap_ipsec", 388 "expires_in" : "3600", 389 "cnf" : { 390 "ipsec" : { 392 "mode" : "transport", 393 "protocol" : "ESP", 394 "life" : "3600", 395 "SPI_SA_C" : "87615", 396 "SPI_SA_RS" : "87616", 397 "seed" : b64'+a+Dg2jjU+eIiOFCa9lObw', 398 "alg" : "AES-CCM-16-64-128", 399 ... (the Network Parameters are omitted for brevity), 400 } 401 } 402 } 404 Figure 5: Example of Access Token Response with DP of SA pair 406 3.2.2. SA Establishment Based of Symmetric Keys 408 If the AS selects this key management method, it specifies the 409 following pieces of information in the Access Token Response and in 410 the Access Token: 412 o a symmetric key to be used as proof-of-possession key; 414 o a key identifier associated to the symmetric key; 416 o SA pair's Network Parameters and Security Parameters, as an 417 "ipsec" structure in the "cnf" parameter (see Section 2.1). 419 If C has previously received a PSK from the AS, then C MUST provide a 420 key identifier of that PSK either directly in the "kid" field of 421 "cnf" parameter or in the "kid" field of the "COSE_Key" object of the 422 Access Token Request. In this case, the AS omits the PSK and its 423 identifier in the Access Token Response. 425 The AS indicates the use of symmetric cryptography for the key 426 management message exchange in the "kty" field of the "COSE_Key" 427 object, including also the PSK in the "k" field as well as its key 428 identifier in the "kid" field, as shown in Figure 6. 430 Header: Created (Code=2.01) 431 Content-Type: "application/cose+cbor" 432 Payload: 433 { 434 "access_token" : b64'YiksuH&=1GFfg ... 435 (remainder of Access Token omitted for brevity)', 436 "profile" : "coap_ipsec", 437 "expires_in" : "3600", 438 "cnf" : { 439 "COSE_Key" : { 440 "kty" : "Symmetric", 441 "kid" : b64'6kwi42ec', 442 "k" : b64'+pAd48jU+eIiOF23gd=', 443 } 444 "kmp": "ikev2", 445 "ipsec" : { 446 "mode" : "tunnel", 447 "protocol" : "ESP", 448 "life" : "1800", 449 "IP_C" : "a.b.c.d2", 450 "IP_RS" : "a.b.c.d1", 451 ... (the Network Parameters are omitted for brevity), 452 } 453 } 454 } 456 Figure 6: Example of Access Token Response with a symmetric key as 457 proof-of-possession key. 459 3.2.3. SA Establishment Based on Asymmetric Keys 461 C MUST include its own public key in the Access Token Request, as 462 shown in Figure 7. As an alternative, C MUST provide the key 463 identifier of its own public key, previously shared with the AS. 465 The AS specifies in the Access Token and in the Access Token Response 466 the SA pair's Network Parameters and Security Parameters, as an 467 "ipsec" structure in the "cnf" parameter (see Section 2.1). 469 In addition, the AS specifies the RS's public key in the Access Token 470 Response, and the C's public key to be used as proof-of-possession 471 key in the Access Token. 473 The AS indicates the use of asymmetric cryptography for the key 474 management message exchange in the "kty" field of the "COSE_Key" 475 object, which includes also the RS's public key in the Access Token 476 Response and the C's public key in the Access Token. 478 Header: POST (Code=0.02) 479 Uri-Host: "server.example.com" 480 Uri-Path: "token" 481 Content-Type: "application/cose+cbor" 482 Payload: 483 { 484 "grant_type" : "client_credentials", 485 "cnf" : { 486 "COSE_Key" : { 487 "kty" : "EC", 488 "crv" : "P-256", 489 "x" : b64'CaFadPPavdtjRH3YqaTqm0FrFtNV0', 490 "y" : b64'ehekJBwciJdeT6cKieycnk6kg4pHC' 491 } 492 } 493 } 495 Figure 7: Example of Access Token Request with an asymmetric key as 496 proof-of-possession key. 498 3.3. Client to RS 500 Phase (3) in Figure 4 starts with C posting the Access Token by means 501 of a POST CoAP message to the /authz-info endpoint at RS, as 502 specified in Section 8 of [I-D.ietf-ace-oauth-authz]. The processing 503 details of this request, as well as the handling of invalid Access 504 Tokens at RS, are defined in Section 5.7.1 of 505 [I-D.ietf-ace-oauth-authz] and in the rest of this section. The 506 Access Token and Access Token Response specify one of the SA setup 507 methods defined in Section 2. In particular, C and RS determine the 508 specific SA setup method as follows: 510 o In case of Direct Provisioning, the "ipsec" structure is present, 511 while the "COSE_Key" object is not present. 513 o If the SA pair set up based on Symmetric Keys through IKEv2 is 514 used, then: 516 * the "COSE_Key" object is present with the "kty" field set to 517 "Symmetric"; and 519 * the "kmp" parameter is set to "ikev2". 521 o If the SA pair set up based on Asymmetric Keys through IKEv2 is 522 used, then: 524 * the "COSE_Key" object is present with the "kty" field set to a 525 value that indicates the use of an asymmetric key, e.g. "EC"; 526 and 528 * the "kmp" parameter is set to "ikev2". 530 If the Direct Provisioning method is used, then C and RS do not 531 perform the SA establishment shown in Figure 4. Otherwise, C and RS 532 perform the key management protocol indicated by the "kmp" parameter 533 (such as IKEv2), in the authentication mode indicated by the "kty" 534 field of the "COSE_key" object. 536 Regardless the chosen SA setup method and the successful 537 establishment of the IPsec channel, if C holds a valid Access Token 538 but this does not grant access to the requested protected resource, 539 RS MUST send a 4.03 (Forbidden) response. Similarly, if the Access 540 Token does not cover the intended action, RS MUST send a 4.05 (Method 541 Not Allowed) response. 543 3.3.1. SA Direct Provisioning 545 Once received a positive Access Token Response from the AS, C derives 546 the necessary IPsec key material from the "seed" field of the "ipsec" 547 structure in the Access Token Response, as discussed in Section 2.1. 548 Similarly, RS performs the same key derivation process upon receiving 549 and successfully verifying the Access Token. After that, RS replies 550 to C with a 2.01 (Created) response, using the IPsec channel 551 specified by the SA pair. Thereafter, Resource Requests and 552 Responses are also sent using the IPsec channel. 554 3.3.2. Authenticated SA Establishment 556 If an Authenticated Key Management method is used (see Section 3.2.2 557 and Section 3.2.3), C and RS MUST run a Key Management Protocol to 558 finalize the establishment of the SA pair and the IPsec channel, i.e. 559 the required keys and algorithms. As shown in Figure 8, the first 560 message IKE_SA_INIT of the IKEv2 protocol is used to acknowledge the 561 Access Token submission. Depending on the used authentication 562 method, i.e. symmetric or asymmetric, the proof-of-possession key 563 MUST be used accordingly to authenticate the IKEv2 message exchange 564 as defined in Section 2.15 of [RFC7296]. The rest of the IKEv2 565 protocol MUST be executed between C and RS as described in Section 2 566 of [RFC7296], with no further modifications. If IKEv2 is 567 successfully completed, C and RS agree on keys and algorithms to use, 568 and thus the IPsec channel between C and RS is ready to be used. 570 Resource 571 Client Server 572 | | 573 | | 574 +--------->| Header: POST (Code=0.02) 575 | POST | Uri-Path:"authz-info" 576 | | Content-Type: application/cbor 577 | | Payload: Access Token 578 | | 579 |<---------+ IKE_SA_INIT 580 | | 581 ... 583 Figure 8: IKEv2 used as Key Management Protocol. 585 3.4. RS to AS 587 The communication between RS and the AS occurs through the 588 /introspect endpoint, as defined in Section 5.6 of 589 [I-D.ietf-ace-oauth-authz]. This channel SHOULD be confidential, 590 authenticated and integrity protected. Therefore, RS and the AS are 591 expected to have pre-established credentials and to use security 592 protocols such as OSCOAP, DTLS or IPsec to protect their 593 communications. 595 4. Security Considerations 597 This document inherits the security considerations of [RFC4301], 598 [RFC4302] and [RFC4303]. Furthermore, if IKEv2 is used as key 599 establishment method (see Section 3.3.2), the same considerations 600 discussed in [RFC7296] hold. 602 4.1. Privacy Considerations 604 The message exchange in Phase (1) of Figure 4 is unprotected and MAY 605 disclose the relation between the AS, RS and C, as well as network 606 related information, such as IP addresses. Thus RS SHOULD only 607 include the necessary information to contact the AS in the 608 unprotected response. 610 5. IANA Considerations 612 This document requires the following IANA considerations: 614 +---------+-------+----------------+------------+-------------------+ 615 | name | label | CBOR type | value | description | 616 +---------+-------+----------------+------------+-------------------+ 617 | kmp | TBD | bstr | ikev2 | Indicates the | 618 | | | | | key management | 619 | | | | | protocol to be | 620 | | | | | used to establish | 621 | | | | | a SA pair | 622 | | | | | | 623 | ipsec | TBD | struct | | Contains Security | 624 | | | | | and Network | 625 | | | | | Parameters of an | 626 | | | | | SA pair | 627 +---------+-------+----------------+------------+-------------------+ 629 5.1. CoAP-IPsec Profile registration 631 o Profile name: CoAP-IPsec 633 o Profile description: ACE Framework profile 635 o Profile ID: coap_ipsec 637 o Change Controller: IESG 639 o Specification Document: This document 641 5.2. Confirmation Methods registration 643 5.2.1. IPsec field 645 o Confirmation Method Name: "ipsec" 647 o Confirmation Method Value: TBD 649 o Confirmation Method Description: A structure containing the 650 corresponding information of an IPsec Security Association Pair. 652 o Change Controller: IESG 654 o Specification Document: This document 656 5.2.2. Key Management Protocol field 658 o Confirmation Method Name: "kmp" 660 o Confirmation Method Value: TBD 661 o Confirmation Method Description: Key management protocol. 663 o Change Controller: IESG 665 o Specification Document: This document 667 5.3. Key Management Protocol Methods Registry 669 This specification establishes the IANA "Key Management Protocol 670 Methods" registry for the "kmp" member values. The registry records 671 the confirmation method member and a reference to the spec that 672 defines it. 674 5.3.1. Registration Template 676 Key Management Protocol Method Name: 678 The name requested (e.g. "ikev2"). This name is intended to be 679 human readable and be used for debugging purposes. It is case 680 sensitive. Names may not match other registered names in a case- 681 insensitive manner unless the Designated Experts state that there 682 is a compelling reason to allow an exception. 684 Key Management Protocol Method Value: 686 Integer representation for the confirmation method value. 687 Intended for use to uniquely identify the confirmation method. 688 The value MUST be an integer in the range of 1 to 65536. 690 Key Management Protocol Method Description: 692 Brief description of the confirmation method (e.g. "Key 693 Identifier"). 695 Change Controller: 697 For Standards Track RFCs, list the "IESG". For others, give the 698 name of the responsible party. Other details (e.g. postal 699 address, email address, home page URI) may also be included. 701 Specification Document(s): 703 Reference to the document or documents that specify the parameter, 704 preferably including URIs that can be used to retrieve copies of 705 the documents. An indication of the relevant sections may also be 706 included but is not required. 708 5.3.2. Initial Registry Contents 710 o Key Management Protocol Method Name: "ikev2" 712 o Key Management Protocol Method Value: TBD 714 o Key Management Protocol Method Description: Defines IKEv2 as key 715 management protocol. 717 o Change Controller: IESG 719 o Specification Document: this document 721 6. Acknowledgments 723 The authors sincerely thank Max Maass for his comments and feedback. 725 The authors gratefully acknowledge the EIT-Digital Master School for 726 partially funding this work. 728 7. References 730 7.1. Normative References 732 [I-D.ietf-ace-oauth-authz] 733 Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and 734 H. Tschofenig, "Authentication and Authorization for 735 Constrained Environments (ACE)", draft-ietf-ace-oauth- 736 authz-06 (work in progress), March 2017. 738 [I-D.seitz-ace-oscoap-profile] 739 Seitz, L., Gunnarsson, M., and F. Palombini, "OSCOAP 740 profile of ACE", draft-seitz-ace-oscoap-profile-03 (work 741 in progress), June 2017. 743 [I-D.selander-ace-cose-ecdhe] 744 Selander, G., Mattsson, J., and F. Palombini, "Ephemeral 745 Diffie-Hellman Over COSE (EDHOC)", draft-selander-ace- 746 cose-ecdhe-06 (work in progress), April 2017. 748 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 749 Requirement Levels", BCP 14, RFC 2119, 750 DOI 10.17487/RFC2119, March 1997, 751 . 753 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 754 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 755 December 2005, . 757 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 758 DOI 10.17487/RFC4302, December 2005, 759 . 761 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 762 RFC 4303, DOI 10.17487/RFC4303, December 2005, 763 . 765 [RFC4835] Manral, V., "Cryptographic Algorithm Implementation 766 Requirements for Encapsulating Security Payload (ESP) and 767 Authentication Header (AH)", RFC 4835, 768 DOI 10.17487/RFC4835, April 2007, 769 . 771 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 772 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 773 January 2012, . 775 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 776 Application Protocol (CoAP)", RFC 7252, 777 DOI 10.17487/RFC7252, June 2014, 778 . 780 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 781 Kivinen, "Internet Key Exchange Protocol Version 2 782 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 783 2014, . 785 7.2. Informative References 787 [I-D.ietf-ace-actors] 788 Gerdes, S., Seitz, L., Selander, G., and C. Bormann, "An 789 architecture for authorization in constrained 790 environments", draft-ietf-ace-actors-05 (work in 791 progress), March 2017. 793 [I-D.ietf-core-object-security] 794 Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 795 "Object Security of CoAP (OSCOAP)", draft-ietf-core- 796 object-security-04 (work in progress), July 2017. 798 [I-D.ietf-cose-msg] 799 Schaad, J., "CBOR Object Signing and Encryption (COSE)", 800 draft-ietf-cose-msg-24 (work in progress), November 2016. 802 [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", 803 RFC 6749, DOI 10.17487/RFC6749, October 2012, 804 . 806 Appendix A. Coexistence of OSCOAP and IPsec 808 Object Security of CoAP (OSCOAP) [I-D.ietf-core-object-security] is a 809 data object based security protocol that protects CoAP messages end- 810 to-end while allowing proxy operations. It encloses unprotected CoAP 811 messages, and selected CoAP options and headers fields into a CBOR 812 Object Signing and Encryption (COSE) object [I-D.ietf-cose-msg]. 813 This section describes a scenario where communications between C and 814 RS are secured by means of OSCOAP and IPsec. Figure 9 depicts a 815 scenario where a Client needs to access a Resource Server which is 816 behind an untrusted CoAP-Proxy. This scenario requires that: 818 1. the Proxy has access to the selected CoAP options to perform 819 management and support operations; 821 2. the integrity of messages and their IP headers can be verified by 822 the Resource Server; 824 3. the confidentiality of the Resource Server address and CoAP 825 request has to be guaranteed between the Client and the Proxy. 827 The first requirement is addressed by means of an OSCOAP channel 828 between the Client and the Resource Server established as described 829 in [I-D.seitz-ace-oscoap-profile]), by marking as Class E the 830 sensitive fields of the CoAP payload as defined in 831 [I-D.ietf-core-object-security]. 833 To address the second requirement, a SA pair between the Client and 834 the Resource Server is established, as specified in Section 3, by 835 using the IPsec AH protocol in transport mode. Finally, the third 836 requirement is fulfilled by means of a SA pair between the Client and 837 the CoAP-Proxy, as specified in Section 3, by using the IPsec ESP 838 protocol in tunnel mode. 840 This profile can be used to establish the necessary SA pairs. After 841 that, C can request a token update to the AS, in order to establish 842 an OSCOAP security context with RS, as specified in Section 2.2 of 843 [I-D.seitz-ace-oscoap-profile]. 845 Figure 9 overviews the involved secure communication channels. 846 Logical links such as the SA pair shared between the Client and the 847 Proxy are represented by dotted lines. IPsec traffic is depicted 848 with double-dashed lines, and an example of the packets going through 849 these links is represented with numbers, e.g. (1). The destination 850 address included in the IP headers is also specified, e.g. "IP:P" 851 indicates the Proxy's address as destination address. The source 852 address of the IP header is omitted, since all the IP packets have 853 the Client's address as source address. 855 OSCOAP context & 856 SA AH-transport 857 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 858 . . 859 . SA ESP-tunnel . 860 . . . . . . . . . . . . . . . . 861 . . . . 862 v v v v 863 +--------+ +--------+ +------+ 864 | Client | <==== (1) ====> | Proxy | <==== (2) ====> | RS | 865 +--------+ +--------+ +------+ 867 (1): |IP:P|ESP|IP:RS|AH|UDP|OSCOAP|ESP_T|ESP_Auth| 868 (2): |IP:RS|AH|UDP|OSCOAP| 870 Figure 9: OSCOAP and IPsec - Scenario overview 872 Appendix B. SA Establishment with EDHOC 874 As discussed in Appendix A, securing communications between C and RS 875 with both OSCOAP and IPsec makes it possible to fulfill a number of 876 additional security requirements. An OSCOAP security context between 877 C and RS can be established using Ephemeral Diffie-Hellman Over COSE 878 (EDHOC) as defined in Appendix C.2 of [I-D.selander-ace-cose-ecdhe] 879 and according to [I-D.seitz-ace-oscoap-profile]. This section 880 proposes a method to establish also IPsec SA pairs by means of EDHOC. 881 This makes it possible for constrained devices running the scenario 882 described in Appendix A to rely solely on EDHOC for establishing both 883 OSCOAP contexts and IPsec SA pairs, thus avoiding to include the 884 implementation of IKEv2 as further key management protocol. 886 In particular, C and RS can refer to the SA Authenticated 887 Establishment methods described in this specification, and then use 888 EDHOC to finalize the SA pair, i.e. by deriving the encryption and 889 authentication keys for the security protocols specified in the SA 890 pair. This is possible thanks to IPsec's independence from specific 891 key management protocols. In addition, the same security 892 consideration discussed in [I-D.selander-ace-cose-ecdhe] hold. 894 The AS, C and RS refer to the same protocol shown in Figure 4, with 895 the following changes. 897 B.1. Client to AS 899 The AS specifies the fields "alg", "SPI_SA_C" and "SPI_SA_RS" of the 900 "ipsec" structure in the Access Token and in the Access Token 901 Response, in addition to the pieces of information defined in 902 Section 3.2.2 or Section 3.2.3, in case the proof-of-possession key 903 is symmetric or asymmetric, respectively. 905 The AS signals that EDHOC MUST be used, by setting the "kmp" field to 906 "edhoc" in the Access Token and the Access Token Response. Then, C 907 and RS MUST perform EDHOC as described in Section 4 or Section 5 of 908 [I-D.selander-ace-cose-ecdhe], in case the proof-of-possession key is 909 asymmetric or symmetric, respectively. 911 B.2. Client to RS 913 Figure 10 shows how EDHOC message_1 is sent through a POST Access 914 Token Request to the /authz-info at the RS. The RS SHALL process the 915 Access Token according to [I-D.ietf-ace-oauth-authz], and, if valid, 916 continue with the EDHOC protocol as defined in Appendix C.1 of 917 [I-D.selander-ace-cose-ecdhe]. Otherwise, RS aborts EDHOC and 918 responds with an error code as specified in 919 [I-D.ietf-ace-oauth-authz]. At the end of the EDHOC protocol, C and 920 RS MUST derive an IPsec seed from the EDHOC shared secret. The seed 921 is derived as specified in Section 3.2 of 922 [I-D.selander-ace-cose-ecdhe], with other=exchange_hash, 923 AlgorithmID="EDHOC IKE seed" and keyDataLength equal to the key 924 length of the SKEYSEED secret defined in Section 2.14 of [RFC7296]. 925 After that, the derived seed is written in the "seed" field of the 926 "ipsec" structure, and accordingly used to derive IPsec key material 927 as described in Section 2.1. 929 Resource 930 Client Server 931 | | 932 | | 933 +-------->| Header: POST (Code=0.02) 934 | POST | Uri-Path:"authz-info" 935 | | Content-Type: application/cbor 936 | | Payload: EDHOC message_1 + Access Token 937 | | 938 ... 940 Figure 10: EDHOC used as Key Management Protocol 942 Authors' Addresses 943 Santiago Aragon 944 RISE SICS AB 945 Isafjordsgatan 22 946 Kista SE-164 29 947 Sweden 949 Email: santiago.aragon@stud.tu-darmstadt.de 951 Marco Tiloca 952 RISE SICS AB 953 Isafjordsgatan 22 954 Kista SE-164 29 955 Sweden 957 Phone: +46 70 604 65 01 958 Email: marco.tiloca@ri.se 960 Shahid Raza 961 RISE SICS AB 962 Isafjordsgatan 22 963 Kista SE-164 29 964 Sweden 966 Phone: +46 76 883 17 97 967 Email: shahid.raza@ri.se