idnits 2.17.1 draft-aragon-ace-ipsec-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 : ---------------------------------------------------------------------------- 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 (October 29, 2017) is 2370 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-08 ** Obsolete normative reference: RFC 4835 (Obsoleted by RFC 7321) == 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-06 == Outdated reference: A later version (-14) exists of draft-selander-ace-cose-ecdhe-07 -- Obsolete informational reference (is this intentional?): RFC 6347 (Obsoleted by RFC 9147) -- Obsolete informational reference (is this intentional?): RFC 8152 (Obsoleted by RFC 9052, RFC 9053) Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 3 comments (--). 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: May 2, 2018 RISE SICS AB 6 October 29, 2017 8 IPsec profile of ACE 9 draft-aragon-ace-ipsec-profile-01 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. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on May 2, 2018. 36 Copyright Notice 38 Copyright (c) 2017 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Methods for Setting Up SA Pairs . . . . . . . . . . . . . . . 4 56 2.1. The "ipsec" Structure . . . . . . . . . . . . . . . . . . 5 57 3. Protocol Description . . . . . . . . . . . . . . . . . . . . 7 58 3.1. Unauthorized Client to RS . . . . . . . . . . . . . . . . 8 59 3.2. Client to AS . . . . . . . . . . . . . . . . . . . . . . 8 60 3.2.1. Direct Provisioning of SA pairs . . . . . . . . . . . 9 61 3.2.2. SA Establishment Based on Symmetric Keys . . . . . . 9 62 3.2.3. SA Establishment Based on Asymmetric Keys . . . . . . 11 63 3.3. Client to RS . . . . . . . . . . . . . . . . . . . . . . 11 64 3.3.1. SA Direct Provisioning . . . . . . . . . . . . . . . 12 65 3.3.2. Authenticated SA Establishment . . . . . . . . . . . 13 66 3.4. RS to AS . . . . . . . . . . . . . . . . . . . . . . . . 13 67 4. Security Considerations . . . . . . . . . . . . . . . . . . . 14 68 4.1. Privacy Considerations . . . . . . . . . . . . . . . . . 14 69 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 70 5.1. CoAP-IPsec Profile registration . . . . . . . . . . . . . 14 71 5.2. Confirmation Methods registration . . . . . . . . . . . . 15 72 5.2.1. IPsec field . . . . . . . . . . . . . . . . . . . . . 15 73 5.2.2. Key Management Protocol field . . . . . . . . . . . . 15 74 5.3. Key Management Protocol Methods Registry . . . . . . . . 15 75 5.3.1. Registration Template . . . . . . . . . . . . . . . . 15 76 5.3.2. Initial Registry Contents . . . . . . . . . . . . . . 16 77 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 78 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 79 7.1. Normative References . . . . . . . . . . . . . . . . . . 17 80 7.2. Informative References . . . . . . . . . . . . . . . . . 18 81 Appendix A. Coexistence of OSCORE and IPsec . . . . . . . . . . 18 82 Appendix B. SA Establishment with EDHOC . . . . . . . . . . . . 20 83 B.1. Client to AS . . . . . . . . . . . . . . . . . . . . . . 20 84 B.2. Client to RS . . . . . . . . . . . . . . . . . . . . . . 21 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 87 1. Introduction 89 The IPsec protocol suite [RFC4301] allows communications based on the 90 Constrained Application Protocol (CoAP) [RFC7252] to fulfill a number 91 of security goals at the network layer, i.e. integrity and IP 92 spoofing protection, confidentiality of traffic flows, and message 93 replay protection. In several resource-constrained platforms, this 94 can leverage security operations directly provided by hardware 95 crypto-modules, including mandatory-to-implement cipher suites 96 defined in [RFC4835]. 98 This document defines a profile of the ACE framework for 99 authentication and authorization [I-D.ietf-ace-oauth-authz], where a 100 client (C) and a resource server (RS) communicate using CoAP 101 [RFC7252] over IPsec [RFC4301]. In particular, C uses an Access 102 Token released by an Authorization Server (AS) and bound to a key 103 (proof-of-possession key) to authorize its access to RS and its 104 protected resources. 106 The establishment of an IPsec channel between C and RS provides 107 secure communication, proof-of-possession as well as RS and C mutual 108 authentication. Furthermore, this profile preserves the flexibility 109 of IPsec as to the selection of specific security protocols, i.e. 110 Encapsulating Security Payload (ESP) [RFC4303] and IP Authentication 111 Header (AH) [RFC4302], key management, and modes of operations, i.e. 112 tunnel or transport. Those parameters are specified in the IPsec 113 Security Association (SA) pair established between C and RS. 114 Optionally, the client and the resource server may also use CoAP and 115 IPsec to communicate with the Authorization Server. 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 relies on the Internet Key 121 Exchange Protocol version 2 (IKEv2) [RFC7296]. 123 1.1. Terminology 125 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 126 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 127 RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be 128 interpreted as described in BCP 14 [RFC2119][RFC8174] when, and only 129 when, they appear in all capitals, as shown here. These keywords 130 indicate requirement levels for compliant CoAP-IPsec profile 131 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]. It is 136 assumed in this document that a given resource on a specific RS is 137 associated to a unique AS. 139 The concept of IPsec Security Association (Section 4.1. of [RFC4301]) 140 plays a key role, and this profile uses it extensively. An SA 141 indicates how to secure a one-way communication between two parties. 142 Hence, two SAs are required to be created and coordinated, in order 143 to secure a two-way communication channel. This document refers to a 144 SA pair as the two IPsec SAs used to protect the two-way 145 communication channel between two IPsec peers. 147 The SA parameters described in section 4.4.2.1 of [RFC4301] are 148 divided into the following two sets. 150 o Network Parameters: the parameters defining the network properties 151 of the IPsec channel, e.g. DSCP filtering; 153 o Security Parameters: the parameters defining the security 154 properties of the IPsec channel. 156 This document refers to SA-C as the SA for securing communication 157 from C to RS, and to SA-RS as the SA for securing communication from 158 RS to C. Thus, a SA pair consists of an SA-C and an SA-RS. 160 2. Methods for Setting Up SA Pairs 162 The following key management methods are supported for setting up a 163 SA pair between C and RS. 165 1. Direct Provisioning (DP). The SA pair is pre-defined by the AS. 166 Then, SA-RS and SA-C are specified in the Access Token Response 167 and in the Access Token issued by the AS. 169 2. Establishment with symmetric key authentication. A symmetric 170 Pre-Shared Key (PSK) is used to authenticate both parties during 171 the SA pair establishment and is bound to the Access Token as 172 proof-of-possession key. If C is interacting for the first time 173 with the RS, then the AS MUST include a PSK and a unique key 174 identifier in the Access Token Response. Otherwise, C MUST 175 include the unique key identifier pointing at the previously 176 established PSK in the Access Token Request. 178 3. Establishment with asymmetric key authentication. An asymmetric 179 Raw Public Key (RPK) or Certificate-based Public Key (CPK) is 180 used to authenticate both parties during the SA pair 181 establishment and is bound to the Access Token as proof-of- 182 possession key. If the AS does not know C's asymmetric 183 authentication information, then C MUST include its RPK or CPK in 184 the Access Token Request. Otherwise, C MUST include a key 185 identifier linked to its own RPK or CPK available at the AS. 187 Every SA MUST include the following Security Parameters. 189 o A Security Parameter Index (SPI); 190 o IPsec protocol mode: tunnel or transport; 192 o Security protocol: AH or ESP; 194 o "AH-authentication", "ESP-encryption", "ESP-integrity" or "ESP- 195 combined" algorithm; 197 o Source and destination, if tunnel mode is selected; 199 o Cryptographic keys; 201 o SA lifetime. 203 As assumed in Section 5.5.2 of [I-D.ietf-ace-oauth-authz], the AS has 204 knowledge of C's and RS's capabilities, and of RS's preferred 205 communications settings. Therefore, the AS MUST set the values of 206 Security Parameters and Network Parameters in the SA pair. 208 2.1. The "ipsec" Structure 210 This document defines the "ipsec" structure as a field of the "cnf" 211 parameter of the Access Token and Access Token Response. This 212 structure encodes the Network and Security Parameters of the SA pair 213 as defined in Figure 1. The Network Parameters are not discussed in 214 this specification. 216 ipsec{ 217 , 218 219 } 221 Figure 1: "ipsec" structure overview. 223 The AS builds the "ipsec" structure as follows: 225 o The Security Parameters MUST always include the set of parameters 226 sec_A shown in Figure 2. 228 o The Security Parameters MUST include the set of parameters sec_B 229 shown in Figure 3 if the AS uses the Direct Provisioning method. 231 sec_A{ 232 mode, 233 protocol, 234 life, 235 IP_C, (if mode == tunnel) 236 IP_RS (if mode == tunnel) 237 } 239 Figure 2: Set sec_A of Security Parameters 241 sec_B{ 242 SPI_SA_C, 243 SPI_SA_RS, 244 alg, 245 seed 246 } 248 Figure 3: Set sec_B of Security Parameters 250 In sec_A, the IP_C field is the IP address of C, while IP_RS is the 251 IP address of RS. In tunnel mode, the RS MUST use IP_C as the 252 destination address and IP_RS as source address of outgoing IPsec 253 messages. Similarly, C MUST use IP_RS as destination address and 254 IP_C as source address of incoming IPsec messages. 256 In sec_B, the field "SPI_SA_C" is the SPI of SA-C. Similarly, 257 "SPI_SA_RS" is the SPI of SA-RS. The field "alg" indicates the 258 algorithm used for securing communications over IPsec. The "seed" 259 field MUST reflect the SKEYSEED secret defined in Section 2.14 of 260 [RFC7296]. Thus, C and RS MUST use the same key derivation 261 techniques to generate the necessary SA keys from "seed". 263 Note that if the Direct Provisioning method is used, the AS cannot 264 guarantee the uniqueness of the "SPI_SA_C" value at the RS and of the 265 "SPI_SA_RS" value at C. In such a case, the AS MUST randomly 266 generate the "SPI_SA_C" value and the "SPI_SA_RS" value, so that the 267 probability of a collision to occur is negligible. 269 If RS receives an "SPI_SA_C" value which results in a collision, then 270 RS MUST reply to C with en error response, and both C and RS MUST 271 abort the set up of the IPsec channel. In order to overcome this 272 issue, the AS can manage a pool of "SPI_SA_C" reserved values, 273 intended only for use with the Direct Provisioning method. Then, in 274 case of SA termination, the RS asks the AS to set back the identifier 275 of that SA-C as available. 277 If C receives an "SPI_SA_RS" value which results in a collision, then 278 C sends a second Token Request to the AS, asking for a Token Update. 280 This Token Request includes also an "ipsec" structure, which contains 281 only the field "SPI_SA_RS" specifying an available value to use. 282 Then, the AS replies with an Access Token and an Access Token 283 Response both updated as to the "SPI_SA_RS" value only. 285 3. Protocol Description 287 This profile considers a client C that intends to access a protected 288 resource hosted by a resource server RS. The resource access is 289 authorized through an Access Token issued by the AS as specified in 290 [I-D.ietf-ace-oauth-authz] and indicating that IPsec is used to 291 secure communications between C and RS. In particular, this profile 292 defines how C and RS set up a SA pair, using the key management 293 methods introduced in Section 2. 295 The protocol is composed of three parts, as shown in Figure 4. 297 C RS AS 298 | | | 299 | [------ Resource Request ------>] | | 300 (1) | | | 301 | [<------ AS Information --------] | | 302 | | | 303 --- | | | 304 | | | 305 | --------- Token Request ------------------------------> | 306 (2) | | | 307 | | 308 | Access Token + RS Information | 309 | <------------------------------------------------------ | 310 | Including information for IPsec SA establishment | 311 | | 312 --- | | | 313 | | | 314 | --------- Access Token ---------> | | 315 | | | 316 | [<=== IPsec SA establishment ==>] | | 317 (3) | | | 318 | ======== Resource Request ======> | | 319 | | | 320 | <======= Resource Response ====== | | 321 | | | 323 Figure 4: Protocol Overview 325 3.1. Unauthorized Client to RS 327 Phase (1) in Figure 4 is OPTIONAL and aims at providing C with the 328 necessary information to contact the AS, in case C does not know AS's 329 address. Through an unauthorized request to RS, C determines which 330 AS is responsible for granting authorization to that particular RS. 331 When doing so, C learns to which address the Access Token Request has 332 to be addressed. The unauthorized request is denied by RS, which 333 sends back to C a response containing the information to contact the 334 AS. 336 3.2. Client to AS 338 Phase (2) in Figure 4 starts with C sending the Access Token Request 339 to the /token endpoint at the AS, as specified in Section 5.5.1 of 340 [I-D.ietf-ace-oauth-authz]. Figure 2 and Figure 3 of 341 [I-D.ietf-ace-oauth-authz] provide examples of such request. 343 If the AS successfully verifies the Access Token Request and C is 344 authorized to access the resource specified in the Token Request, 345 then the AS issues the corresponding Access Token and includes it in 346 a CoAP response with code 2.01 (Created) as specified in 347 Section 5.5.2 of [I-D.ietf-ace-oauth-authz]. The AS can signal that 348 IPsec is REQUIRED to secure communications between C and RS by 349 including the "profile" parameter with the value "coap_ipsec" in the 350 Access Token Response. Together with authorization information, the 351 Access Token also includes the same information for the set up of the 352 IPsec channel included in the Access Token Response. The error 353 response procedures defined in Section 5.5.3 of 354 [I-D.ietf-ace-oauth-authz] are unchanged by this profile. 356 The information exchanged between C and the AS depends on the 357 specific method used to set up the SA pair (see Section 3.2.1, 358 Section 3.2.2 and Section 3.2.3). Note that, unless Direct 359 Provisioning of SAs is used, C and RS are required to finalize the SA 360 pair set up by running a Key Management Protocol such as IKEv2 (see 361 Section 3.3.2). The AS indicates to use IKEv2 for establishing a SA 362 pair by setting the "kmp" field to "ikev2" in the "cnf" parameter in 363 the Access Token Response. 365 As specified in Section 5.5 of [I-D.ietf-ace-oauth-authz], the Client 366 and the AS can also use CoAP instead of HTTP to communicate via the 367 /token endpoint. This communication channel MUST be secured. 369 This section specifies how to use IPsec [RFC4301] to protect the 370 channel between the Client and the AS. The use of IPsec for this 371 communication channel is OPTIONAL in this profile, and other security 372 protocols MAY be used instead, such as DTLS [RFC6347] and OSCORE 373 [I-D.ietf-core-object-security]. 375 The Client and the AS are either expected to have pre-established a 376 pair of IPsec SA or to have pre-established credentials to 377 authenticate an IKEv2 key exchange. How these credentials are 378 established is out of scope for this profile. 380 3.2.1. Direct Provisioning of SA pairs 382 If the AS selects this key management method, it encodes the SA pair 383 in the Access Token and in the Access Token Response as an "ipsec" 384 structure in the "cnf" parameter. 386 Figure 5 shows an example of an Access Token Response, signaling C to 387 set up an IPsec channel with RS based on the ESP protocol in 388 transport mode. 390 Header: Created (Code=2.01) 391 Content-Type: "application/cose+cbor" 392 Payload : { 393 "access_token" : b64'YiksuH&=1GFfg ... 394 (remainder of Access Token omitted for brevity)', 395 "profile" : "coap_ipsec", 396 "expires_in" : "3600", 397 "cnf" : { 398 "ipsec" : { 400 "mode" : "transport", 401 "protocol" : "ESP", 402 "life" : "3600", 403 "SPI_SA_C" : "87615", 404 "SPI_SA_RS" : "87616", 405 "seed" : b64'+a+Dg2jjU+eIiOFCa9lObw', 406 "alg" : "AES-CCM-16-64-128", 407 ... (the Network Parameters are omitted for brevity), 408 } 409 } 410 } 412 Figure 5: Example of Access Token Response with DP of SA pair 414 3.2.2. SA Establishment Based on Symmetric Keys 416 If the AS selects this key management method, it specifies the 417 following pieces of information in the Access Token Response and in 418 the Access Token: 420 o a symmetric key to be used as proof-of-possession key; 422 o a key identifier associated to the symmetric key; 424 o SA pair's Network Parameters and Security Parameters, as an 425 "ipsec" structure in the "cnf" parameter (see Section 2.1). 427 If C has previously received a PSK from the AS, then C MUST provide a 428 key identifier of that PSK either directly in the "kid" field of 429 "cnf" parameter or in the "kid" field of the "COSE_Key" object of the 430 Access Token Request. In this case, the AS omits the PSK and its 431 identifier in the Access Token Response. 433 The AS indicates the use of symmetric cryptography for the key 434 management message exchange in the "kty" field of the "COSE_Key" 435 object, including also the PSK in the "k" field as well as its key 436 identifier in the "kid" field, as shown in Figure 6. 438 Header: Created (Code=2.01) 439 Content-Type: "application/cose+cbor" 440 Payload: 441 { 442 "access_token" : b64'YiksuH&=1GFfg ... 443 (remainder of Access Token omitted for brevity)', 444 "profile" : "coap_ipsec", 445 "expires_in" : "3600", 446 "cnf" : { 447 "COSE_Key" : { 448 "kty" : "Symmetric", 449 "kid" : b64'6kwi42ec', 450 "k" : b64'+pAd48jU+eIiOF23gd=', 451 } 452 "kmp": "ikev2", 453 "ipsec" : { 454 "mode" : "tunnel", 455 "protocol" : "ESP", 456 "life" : "1800", 457 "IP_C" : "a.b.c.d2", 458 "IP_RS" : "a.b.c.d1", 459 ... (the Network Parameters are omitted for brevity), 460 } 461 } 462 } 464 Figure 6: Example of Access Token Response with a symmetric key as 465 proof-of-possession key. 467 3.2.3. SA Establishment Based on Asymmetric Keys 469 C MUST include its own public key in the Access Token Request, as 470 shown in Figure 7. As an alternative, C MUST provide the key 471 identifier of its own public key, previously shared with the AS. 473 The AS specifies in the Access Token and in the Access Token Response 474 the SA pair's Network Parameters and Security Parameters, as an 475 "ipsec" structure in the "cnf" parameter (see Section 2.1). 477 In addition, the AS specifies the RS's public key in the Access Token 478 Response, and the C's public key to be used as proof-of-possession 479 key in the Access Token. 481 The AS indicates the use of asymmetric cryptography for the key 482 management message exchange in the "kty" field of the "COSE_Key" 483 object, which includes also the RS's public key in the Access Token 484 Response and the C's public key in the Access Token. 486 Header: POST (Code=0.02) 487 Uri-Host: "server.example.com" 488 Uri-Path: "token" 489 Content-Type: "application/cose+cbor" 490 Payload: 491 { 492 "grant_type" : "client_credentials", 493 "cnf" : { 494 "COSE_Key" : { 495 "kty" : "EC", 496 "crv" : "P-256", 497 "x" : b64'CaFadPPavdtjRH3YqaTqm0FrFtNV0', 498 "y" : b64'ehekJBwciJdeT6cKieycnk6kg4pHC' 499 } 500 } 501 } 503 Figure 7: Example of Access Token Request with an asymmetric key as 504 proof-of-possession key. 506 3.3. Client to RS 508 Phase (3) in Figure 4 starts with C posting the Access Token by means 509 of a POST CoAP message to the /authz-info endpoint at RS, as 510 specified in Section 5.7 of [I-D.ietf-ace-oauth-authz]. The 511 processing details of this request, as well as the handling of 512 invalid Access Tokens at RS, are defined in Section 5.7.1 of 513 [I-D.ietf-ace-oauth-authz] and in the rest of this section. The 514 Access Token and Access Token Response specify one of the SA setup 515 methods defined in Section 2. In particular, C and RS determine the 516 specific SA setup method as follows: 518 o In case of Direct Provisioning, the "ipsec" structure is present, 519 while the "COSE_Key" object is not present. 521 o If the SA pair set up based on Symmetric Keys through IKEv2 is 522 used, then: 524 * the "COSE_Key" object is present with the "kty" field set to 525 "Symmetric"; and 527 * the "kmp" parameter is set to "ikev2". 529 o If the SA pair set up based on Asymmetric Keys through IKEv2 is 530 used, then: 532 * the "COSE_Key" object is present with the "kty" field set to a 533 value that indicates the use of an asymmetric key, e.g. "EC"; 534 and 536 * the "kmp" parameter is set to "ikev2". 538 If the Direct Provisioning method is used, then C and RS do not 539 perform the SA establishment shown in Figure 4. Otherwise, C and RS 540 perform the key management protocol indicated by the "kmp" parameter 541 (such as IKEv2), in the authentication mode indicated by the "kty" 542 field of the "COSE_key" object. 544 Regardless the chosen SA setup method and the successful 545 establishment of the IPsec channel, if C holds a valid Access Token 546 but this does not grant access to the requested protected resource, 547 RS MUST send a 4.03 (Forbidden) response. Similarly, if the Access 548 Token does not cover the intended action, RS MUST send a 4.05 (Method 549 Not Allowed) response. 551 3.3.1. SA Direct Provisioning 553 Once received a positive Access Token Response from the AS, C derives 554 the necessary IPsec key material from the "seed" field of the "ipsec" 555 structure in the Access Token Response, as discussed in Section 2.1. 556 Similarly, RS performs the same key derivation process upon receiving 557 and successfully verifying the Access Token. After that, RS replies 558 to C with a 2.01 (Created) response, using the IPsec channel 559 specified by the SA pair. Thereafter, Resource Requests and 560 Responses are also sent using the IPsec channel. 562 3.3.2. Authenticated SA Establishment 564 If an Authenticated Key Management method is used (see Section 3.2.2 565 and Section 3.2.3), C and RS MUST run a Key Management Protocol to 566 finalize the establishment of the SA pair and the IPsec channel, i.e. 567 the required keys and algorithms. As shown in Figure 8, the first 568 message IKE_SA_INIT of the IKEv2 protocol is used to acknowledge the 569 Access Token submission. Depending on the used authentication 570 method, i.e. symmetric or asymmetric, the proof-of-possession key 571 MUST be used accordingly to authenticate the IKEv2 message exchange 572 as defined in Section 2.15 of [RFC7296]. The rest of the IKEv2 573 protocol MUST be executed between C and RS as described in Section 2 574 of [RFC7296], with no further modifications. If IKEv2 is 575 successfully completed, C and RS agree on keys and algorithms to use, 576 and thus the IPsec channel between C and RS is ready to be used. 578 Resource 579 Client Server 580 | | 581 | | 582 +--------->| Header: POST (Code=0.02) 583 | POST | Uri-Path:"authz-info" 584 | | Content-Type: application/cbor 585 | | Payload: Access Token 586 | | 587 |<---------+ IKE_SA_INIT 588 | | 589 ... 591 Figure 8: IKEv2 used as Key Management Protocol. 593 3.4. RS to AS 595 As specified in Section 5.6 of [I-D.ietf-ace-oauth-authz], the RS and 596 the AS can also use CoAP instead of HTTP to communicate via the 597 /introspect endpoint. This communication channel MUST be secured. 599 This section specifies how to use IPsec to protect the channel 600 between the RS and the AS. The use of IPsec for this communication 601 channel is OPTIONAL in this profile, and other security protocols MAY 602 be used instead, such as DTLS [RFC6347] and OSCORE 603 [I-D.ietf-core-object-security]. 605 The RS and the AS are either expected to have pre-established a pair 606 of IPsec SA or to have pre-established credentials to authenticate an 607 IKEv2 key exchange. How these credentials are established is out of 608 scope for this profile. 610 4. Security Considerations 612 This document inherits the security considerations of [RFC4301], 613 [RFC4302] and [RFC4303]. Furthermore, if IKEv2 is used as key 614 establishment method (see Section 3.3.2), the same considerations 615 discussed in [RFC7296] hold. 617 4.1. Privacy Considerations 619 The message exchange in Phase (1) of Figure 4 is unprotected and MAY 620 disclose the relation between the AS, RS and C, as well as network 621 related information, such as IP addresses. Thus RS SHOULD only 622 include the necessary information to contact the AS in the 623 unprotected response. 625 5. IANA Considerations 627 This document requires the following IANA considerations: 629 +---------+-------+----------------+------------+-------------------+ 630 | name | label | CBOR type | value | description | 631 +---------+-------+----------------+------------+-------------------+ 632 | kmp | TBD | bstr | ikev2 | Indicates the | 633 | | | | | key management | 634 | | | | | protocol to be | 635 | | | | | used to establish | 636 | | | | | a SA pair | 637 | | | | | | 638 | ipsec | TBD | struct | | Contains Security | 639 | | | | | and Network | 640 | | | | | Parameters of an | 641 | | | | | SA pair | 642 +---------+-------+----------------+------------+-------------------+ 644 5.1. CoAP-IPsec Profile registration 646 o Profile name: CoAP-IPsec 648 o Profile description: ACE Framework profile 650 o Profile ID: coap_ipsec 652 o Change Controller: IESG 654 o Specification Document: This document 656 5.2. Confirmation Methods registration 658 5.2.1. IPsec field 660 o Confirmation Method Name: "ipsec" 662 o Confirmation Method Value: TBD 664 o Confirmation Method Description: A structure containing the 665 corresponding information of an IPsec Security Association Pair. 667 o Change Controller: IESG 669 o Specification Document: This document 671 5.2.2. Key Management Protocol field 673 o Confirmation Method Name: "kmp" 675 o Confirmation Method Value: TBD 677 o Confirmation Method Description: Key management protocol. 679 o Change Controller: IESG 681 o Specification Document: This document 683 5.3. Key Management Protocol Methods Registry 685 This specification establishes the IANA "Key Management Protocol 686 Methods" registry for the "kmp" member values. The registry records 687 the confirmation method member and a reference to the spec that 688 defines it. 690 5.3.1. Registration Template 692 Key Management Protocol Method Name: 694 The name requested (e.g. "ikev2"). This name is intended to be 695 human readable and be used for debugging purposes. It is case 696 sensitive. Names may not match other registered names in a case- 697 insensitive manner unless the Designated Experts state that there 698 is a compelling reason to allow an exception. 700 Key Management Protocol Method Value: 702 Integer representation for the confirmation method value. 703 Intended for use to uniquely identify the confirmation method. 704 The value MUST be an integer in the range of 1 to 65536. 706 Key Management Protocol Method Description: 708 Brief description of the confirmation method (e.g. "Key 709 Identifier"). 711 Change Controller: 713 For Standards Track RFCs, list the "IESG". For others, give the 714 name of the responsible party. Other details (e.g. postal 715 address, email address, home page URI) may also be included. 717 Specification Document(s): 719 Reference to the document or documents that specify the parameter, 720 preferably including URIs that can be used to retrieve copies of 721 the documents. An indication of the relevant sections may also be 722 included but is not required. 724 5.3.2. Initial Registry Contents 726 o Key Management Protocol Method Name: "ikev2" 728 o Key Management Protocol Method Value: TBD 730 o Key Management Protocol Method Description: Defines IKEv2 as key 731 management protocol. 733 o Change Controller: IESG 735 o Specification Document: this document 737 6. Acknowledgments 739 The authors sincerely thank Max Maass for his comments and feedback. 741 The authors gratefully acknowledge the EIT-Digital Master School for 742 partially funding this work. 744 7. References 745 7.1. Normative References 747 [I-D.ietf-ace-oauth-authz] 748 Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and 749 H. Tschofenig, "Authentication and Authorization for 750 Constrained Environments (ACE)", draft-ietf-ace-oauth- 751 authz-08 (work in progress), October 2017. 753 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 754 Requirement Levels", BCP 14, RFC 2119, 755 DOI 10.17487/RFC2119, March 1997, . 758 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 759 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 760 December 2005, . 762 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 763 DOI 10.17487/RFC4302, December 2005, . 766 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 767 RFC 4303, DOI 10.17487/RFC4303, December 2005, 768 . 770 [RFC4835] Manral, V., "Cryptographic Algorithm Implementation 771 Requirements for Encapsulating Security Payload (ESP) and 772 Authentication Header (AH)", RFC 4835, 773 DOI 10.17487/RFC4835, April 2007, . 776 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 777 Application Protocol (CoAP)", RFC 7252, 778 DOI 10.17487/RFC7252, June 2014, . 781 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 782 Kivinen, "Internet Key Exchange Protocol Version 2 783 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 784 2014, . 786 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 787 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 788 May 2017, . 790 7.2. Informative References 792 [I-D.ietf-ace-actors] 793 Gerdes, S., Seitz, L., Selander, G., and C. Bormann, "An 794 architecture for authorization in constrained 795 environments", draft-ietf-ace-actors-05 (work in 796 progress), March 2017. 798 [I-D.ietf-core-object-security] 799 Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 800 "Object Security for Constrained RESTful Environments 801 (OSCORE)", draft-ietf-core-object-security-06 (work in 802 progress), October 2017. 804 [I-D.seitz-ace-oscoap-profile] 805 Seitz, L., Palombini, F., and M. Gunnarsson, "OSCORE 806 profile of the Authentication and Authorization for 807 Constrained Environments Framework", draft-seitz-ace- 808 oscoap-profile-06 (work in progress), October 2017. 810 [I-D.selander-ace-cose-ecdhe] 811 Selander, G., Mattsson, J., and F. Palombini, "Ephemeral 812 Diffie-Hellman Over COSE (EDHOC)", draft-selander-ace- 813 cose-ecdhe-07 (work in progress), July 2017. 815 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 816 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 817 January 2012, . 819 [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", 820 RFC 6749, DOI 10.17487/RFC6749, October 2012, 821 . 823 [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", 824 RFC 8152, DOI 10.17487/RFC8152, July 2017, 825 . 827 Appendix A. Coexistence of OSCORE and IPsec 829 Object Security of Constrained RESTful Environments (OSCORE) 830 [I-D.ietf-core-object-security] is a data object based security 831 protocol that protects CoAP messages end-to-end while allowing proxy 832 operations. It encloses unprotected CoAP messages, and selected CoAP 833 options and headers fields into a CBOR Object Signing and Encryption 834 (COSE) object [RFC8152]. This section describes a scenario where 835 communications between C and RS are secured by means of OSCORE and 836 IPsec. Figure 9 depicts a scenario where a Client needs to access a 837 Resource Server which is behind an untrusted CoAP-Proxy. This 838 scenario requires that: 840 1. the Proxy has access to the selected CoAP options to perform 841 management and support operations; 843 2. the integrity of messages and their IP headers can be verified by 844 the Resource Server; 846 3. the confidentiality of the Resource Server address and CoAP 847 request has to be guaranteed between the Client and the Proxy. 849 The first requirement is addressed by means of an OSCORE channel 850 between the Client and the Resource Server established as described 851 in [I-D.seitz-ace-oscoap-profile]), by marking as Class E the 852 sensitive fields of the CoAP payload as defined in 853 [I-D.ietf-core-object-security]. 855 To address the second requirement, a SA pair between the Client and 856 the Resource Server is established, as specified in Section 3, by 857 using the IPsec AH protocol in transport mode. Finally, the third 858 requirement is fulfilled by means of a SA pair between the Client and 859 the CoAP-Proxy, as specified in Section 3, by using the IPsec ESP 860 protocol in tunnel mode. 862 This profile can be used to establish the necessary SA pairs. After 863 that, C can request a token update to the AS, in order to establish 864 an OSCORE security context with RS, as specified in Section 2.2 of 865 [I-D.seitz-ace-oscoap-profile]. 867 Figure 9 overviews the involved secure communication channels. 868 Logical links such as the SA pair shared between the Client and the 869 Proxy are represented by dotted lines. IPsec traffic is depicted 870 with double-dashed lines, and an example of the packets going through 871 these links is represented with numbers, e.g. (1). The destination 872 address included in the IP headers is also specified, e.g. "IP:P" 873 indicates the Proxy's address as destination address. The source 874 address of the IP header is omitted, since all the IP packets have 875 the Client's address as source address. 877 OSCORE context & 878 SA AH-transport 879 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 880 . . 881 . SA ESP-tunnel . 882 . . . . . . . . . . . . . . . . 883 . . . . 884 v v v v 885 +--------+ +--------+ +------+ 886 | Client | <==== (1) ====> | Proxy | <==== (2) ====> | RS | 887 +--------+ +--------+ +------+ 889 (1): |IP:P|ESP|IP:RS|AH|UDP|OSCORE|ESP_T|ESP_Auth| 890 (2): |IP:RS|AH|UDP|OSCORE| 892 Figure 9: OSCORE and IPsec - Scenario overview 894 Appendix B. SA Establishment with EDHOC 896 As discussed in Appendix A, securing communications between C and RS 897 with both OSCORE and IPsec makes it possible to fulfill a number of 898 additional security requirements. An OSCORE security context between 899 C and RS can be established using Ephemeral Diffie-Hellman Over COSE 900 (EDHOC) as defined in Appendix C.2 of [I-D.selander-ace-cose-ecdhe] 901 and according to [I-D.seitz-ace-oscoap-profile]. This section 902 proposes a method to establish also IPsec SA pairs by means of EDHOC. 903 This makes it possible for constrained devices running the scenario 904 described in Appendix A to rely solely on EDHOC for establishing both 905 OSCORE contexts and IPsec SA pairs, thus avoiding to include the 906 implementation of IKEv2 as further key management protocol. 908 In particular, C and RS can refer to the SA Authenticated 909 Establishment methods described in this specification, and then use 910 EDHOC to finalize the SA pair, i.e. by deriving the encryption and 911 authentication keys for the security protocols specified in the SA 912 pair. This is possible thanks to IPsec's independence from specific 913 key management protocols. In addition, the same security 914 consideration discussed in [I-D.selander-ace-cose-ecdhe] hold. 916 The AS, C and RS refer to the same protocol shown in Figure 4, with 917 the following changes. 919 B.1. Client to AS 921 The AS specifies the fields "alg", "SPI_SA_C" and "SPI_SA_RS" of the 922 "ipsec" structure in the Access Token and in the Access Token 923 Response, in addition to the pieces of information defined in 924 Section 3.2.2 or Section 3.2.3, in case the proof-of-possession key 925 is symmetric or asymmetric, respectively. 927 The AS signals that EDHOC MUST be used, by setting the "kmp" field to 928 "edhoc" in the Access Token and the Access Token Response. Then, C 929 and RS MUST perform EDHOC as described in Section 4 or Section 5 of 930 [I-D.selander-ace-cose-ecdhe], in case the proof-of-possession key is 931 asymmetric or symmetric, respectively. 933 B.2. Client to RS 935 Figure 10 shows how EDHOC message_1 is sent through a POST Access 936 Token Request to the /authz-info at the RS. The RS SHALL process the 937 Access Token according to [I-D.ietf-ace-oauth-authz], and, if valid, 938 continue with the EDHOC protocol as defined in Appendix C.1 of 939 [I-D.selander-ace-cose-ecdhe]. Otherwise, RS aborts EDHOC and 940 responds with an error code as specified in 941 [I-D.ietf-ace-oauth-authz]. At the end of the EDHOC protocol, C and 942 RS MUST derive an IPsec seed from the EDHOC shared secret. The seed 943 is derived as specified in Section 3.2 of 944 [I-D.selander-ace-cose-ecdhe], with other=exchange_hash, 945 AlgorithmID="EDHOC IKE seed" and keyDataLength equal to the key 946 length of the SKEYSEED secret defined in Section 2.14 of [RFC7296]. 947 After that, the derived seed is written in the "seed" field of the 948 "ipsec" structure, and accordingly used to derive IPsec key material 949 as described in Section 2.1. 951 Resource 952 Client Server 953 | | 954 | | 955 +-------->| Header: POST (Code=0.02) 956 | POST | Uri-Path:"authz-info" 957 | | Content-Type: application/cbor 958 | | Payload: EDHOC message_1 + Access Token 959 | | 960 ... 962 Figure 10: EDHOC used as Key Management Protocol 964 Authors' Addresses 965 Santiago Aragon 966 RISE SICS AB 967 Isafjordsgatan 22 968 Kista SE-164 29 969 Sweden 971 Email: santiago.aragon@stud.tu-darmstadt.de 973 Marco Tiloca 974 RISE SICS AB 975 Isafjordsgatan 22 976 Kista SE-164 29 977 Sweden 979 Phone: +46 70 604 65 01 980 Email: marco.tiloca@ri.se 982 Shahid Raza 983 RISE SICS AB 984 Isafjordsgatan 22 985 Kista SE-164 29 986 Sweden 988 Phone: +46 76 883 17 97 989 Email: shahid.raza@ri.se