ACE Working Group S. Aragon Internet-Draft M. Tiloca Intended status: Standards Track S. Raza Expires: May 2, 2018 RISE SICS AB October 29, 2017 IPsec profile of ACE draft-aragon-ace-ipsec-profile-01 Abstract This document defines a profile of the ACE framework for authentication and authorization. It uses the IPsec protocol suite and the IKEv2 protocol to ensure secure communication, server authentication and proof-of-possession for a key bound to an OAuth 2.0 access token. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on May 2, 2018. Copyright Notice Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of Aragon, et al. Expires May 2, 2018 [Page 1] Internet-Draft IPsec profile of ACE October 2017 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 2. Methods for Setting Up SA Pairs . . . . . . . . . . . . . . . 4 2.1. The "ipsec" Structure . . . . . . . . . . . . . . . . . . 5 3. Protocol Description . . . . . . . . . . . . . . . . . . . . 7 3.1. Unauthorized Client to RS . . . . . . . . . . . . . . . . 8 3.2. Client to AS . . . . . . . . . . . . . . . . . . . . . . 8 3.2.1. Direct Provisioning of SA pairs . . . . . . . . . . . 9 3.2.2. SA Establishment Based on Symmetric Keys . . . . . . 9 3.2.3. SA Establishment Based on Asymmetric Keys . . . . . . 11 3.3. Client to RS . . . . . . . . . . . . . . . . . . . . . . 11 3.3.1. SA Direct Provisioning . . . . . . . . . . . . . . . 12 3.3.2. Authenticated SA Establishment . . . . . . . . . . . 13 3.4. RS to AS . . . . . . . . . . . . . . . . . . . . . . . . 13 4. Security Considerations . . . . . . . . . . . . . . . . . . . 14 4.1. Privacy Considerations . . . . . . . . . . . . . . . . . 14 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 5.1. CoAP-IPsec Profile registration . . . . . . . . . . . . . 14 5.2. Confirmation Methods registration . . . . . . . . . . . . 15 5.2.1. IPsec field . . . . . . . . . . . . . . . . . . . . . 15 5.2.2. Key Management Protocol field . . . . . . . . . . . . 15 5.3. Key Management Protocol Methods Registry . . . . . . . . 15 5.3.1. Registration Template . . . . . . . . . . . . . . . . 15 5.3.2. Initial Registry Contents . . . . . . . . . . . . . . 16 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 7.1. Normative References . . . . . . . . . . . . . . . . . . 17 7.2. Informative References . . . . . . . . . . . . . . . . . 18 Appendix A. Coexistence of OSCORE and IPsec . . . . . . . . . . 18 Appendix B. SA Establishment with EDHOC . . . . . . . . . . . . 20 B.1. Client to AS . . . . . . . . . . . . . . . . . . . . . . 20 B.2. Client to RS . . . . . . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 1. Introduction The IPsec protocol suite [RFC4301] allows communications based on the Constrained Application Protocol (CoAP) [RFC7252] to fulfill a number of security goals at the network layer, i.e. integrity and IP spoofing protection, confidentiality of traffic flows, and message replay protection. In several resource-constrained platforms, this can leverage security operations directly provided by hardware Aragon, et al. Expires May 2, 2018 [Page 2] Internet-Draft IPsec profile of ACE October 2017 crypto-modules, including mandatory-to-implement cipher suites defined in [RFC4835]. This document defines a profile of the ACE framework for authentication and authorization [I-D.ietf-ace-oauth-authz], where a client (C) and a resource server (RS) communicate using CoAP [RFC7252] over IPsec [RFC4301]. In particular, C uses an Access Token released by an Authorization Server (AS) and bound to a key (proof-of-possession key) to authorize its access to RS and its protected resources. The establishment of an IPsec channel between C and RS provides secure communication, proof-of-possession as well as RS and C mutual authentication. Furthermore, this profile preserves the flexibility of IPsec as to the selection of specific security protocols, i.e. Encapsulating Security Payload (ESP) [RFC4303] and IP Authentication Header (AH) [RFC4302], key management, and modes of operations, i.e. tunnel or transport. Those parameters are specified in the IPsec Security Association (SA) pair established between C and RS. Optionally, the client and the resource server may also use CoAP and IPsec to communicate with the Authorization Server. This specification supports different key management methods for setting up SA pairs, namely direct provisioning of SA pairs and establishment of SA pairs based on symmetric or asymmetric key authentication. The latter approach relies on the Internet Key Exchange Protocol version 2 (IKEv2) [RFC7296]. 1.1. Terminology In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119][RFC8174] when, and only when, they appear in all capitals, as shown here. These keywords indicate requirement levels for compliant CoAP-IPsec profile implementations. Readers are expected to be familiar with terminology such as client (C), resource server (RS), authentication server (AS), and endpoint which are defined in [RFC6749] and [I-D.ietf-ace-actors]. It is assumed in this document that a given resource on a specific RS is associated to a unique AS. The concept of IPsec Security Association (Section 4.1. of [RFC4301]) plays a key role, and this profile uses it extensively. An SA indicates how to secure a one-way communication between two parties. Hence, two SAs are required to be created and coordinated, in order Aragon, et al. Expires May 2, 2018 [Page 3] Internet-Draft IPsec profile of ACE October 2017 to secure a two-way communication channel. This document refers to a SA pair as the two IPsec SAs used to protect the two-way communication channel between two IPsec peers. The SA parameters described in section 4.4.2.1 of [RFC4301] are divided into the following two sets. o Network Parameters: the parameters defining the network properties of the IPsec channel, e.g. DSCP filtering; o Security Parameters: the parameters defining the security properties of the IPsec channel. This document refers to SA-C as the SA for securing communication from C to RS, and to SA-RS as the SA for securing communication from RS to C. Thus, a SA pair consists of an SA-C and an SA-RS. 2. Methods for Setting Up SA Pairs The following key management methods are supported for setting up a SA pair between C and RS. 1. Direct Provisioning (DP). The SA pair is pre-defined by the AS. Then, SA-RS and SA-C are specified in the Access Token Response and in the Access Token issued by the AS. 2. Establishment with symmetric key authentication. A symmetric Pre-Shared Key (PSK) is used to authenticate both parties during the SA pair establishment and is bound to the Access Token as proof-of-possession key. If C is interacting for the first time with the RS, then the AS MUST include a PSK and a unique key identifier in the Access Token Response. Otherwise, C MUST include the unique key identifier pointing at the previously established PSK in the Access Token Request. 3. Establishment with asymmetric key authentication. An asymmetric Raw Public Key (RPK) or Certificate-based Public Key (CPK) is used to authenticate both parties during the SA pair establishment and is bound to the Access Token as proof-of- possession key. If the AS does not know C's asymmetric authentication information, then C MUST include its RPK or CPK in the Access Token Request. Otherwise, C MUST include a key identifier linked to its own RPK or CPK available at the AS. Every SA MUST include the following Security Parameters. o A Security Parameter Index (SPI); Aragon, et al. Expires May 2, 2018 [Page 4] Internet-Draft IPsec profile of ACE October 2017 o IPsec protocol mode: tunnel or transport; o Security protocol: AH or ESP; o "AH-authentication", "ESP-encryption", "ESP-integrity" or "ESP- combined" algorithm; o Source and destination, if tunnel mode is selected; o Cryptographic keys; o SA lifetime. As assumed in Section 5.5.2 of [I-D.ietf-ace-oauth-authz], the AS has knowledge of C's and RS's capabilities, and of RS's preferred communications settings. Therefore, the AS MUST set the values of Security Parameters and Network Parameters in the SA pair. 2.1. The "ipsec" Structure This document defines the "ipsec" structure as a field of the "cnf" parameter of the Access Token and Access Token Response. This structure encodes the Network and Security Parameters of the SA pair as defined in Figure 1. The Network Parameters are not discussed in this specification. ipsec{ , } Figure 1: "ipsec" structure overview. The AS builds the "ipsec" structure as follows: o The Security Parameters MUST always include the set of parameters sec_A shown in Figure 2. o The Security Parameters MUST include the set of parameters sec_B shown in Figure 3 if the AS uses the Direct Provisioning method. Aragon, et al. Expires May 2, 2018 [Page 5] Internet-Draft IPsec profile of ACE October 2017 sec_A{ mode, protocol, life, IP_C, (if mode == tunnel) IP_RS (if mode == tunnel) } Figure 2: Set sec_A of Security Parameters sec_B{ SPI_SA_C, SPI_SA_RS, alg, seed } Figure 3: Set sec_B of Security Parameters In sec_A, the IP_C field is the IP address of C, while IP_RS is the IP address of RS. In tunnel mode, the RS MUST use IP_C as the destination address and IP_RS as source address of outgoing IPsec messages. Similarly, C MUST use IP_RS as destination address and IP_C as source address of incoming IPsec messages. In sec_B, the field "SPI_SA_C" is the SPI of SA-C. Similarly, "SPI_SA_RS" is the SPI of SA-RS. The field "alg" indicates the algorithm used for securing communications over IPsec. The "seed" field MUST reflect the SKEYSEED secret defined in Section 2.14 of [RFC7296]. Thus, C and RS MUST use the same key derivation techniques to generate the necessary SA keys from "seed". Note that if the Direct Provisioning method is used, the AS cannot guarantee the uniqueness of the "SPI_SA_C" value at the RS and of the "SPI_SA_RS" value at C. In such a case, the AS MUST randomly generate the "SPI_SA_C" value and the "SPI_SA_RS" value, so that the probability of a collision to occur is negligible. If RS receives an "SPI_SA_C" value which results in a collision, then RS MUST reply to C with en error response, and both C and RS MUST abort the set up of the IPsec channel. In order to overcome this issue, the AS can manage a pool of "SPI_SA_C" reserved values, intended only for use with the Direct Provisioning method. Then, in case of SA termination, the RS asks the AS to set back the identifier of that SA-C as available. If C receives an "SPI_SA_RS" value which results in a collision, then C sends a second Token Request to the AS, asking for a Token Update. Aragon, et al. Expires May 2, 2018 [Page 6] Internet-Draft IPsec profile of ACE October 2017 This Token Request includes also an "ipsec" structure, which contains only the field "SPI_SA_RS" specifying an available value to use. Then, the AS replies with an Access Token and an Access Token Response both updated as to the "SPI_SA_RS" value only. 3. Protocol Description This profile considers a client C that intends to access a protected resource hosted by a resource server RS. The resource access is authorized through an Access Token issued by the AS as specified in [I-D.ietf-ace-oauth-authz] and indicating that IPsec is used to secure communications between C and RS. In particular, this profile defines how C and RS set up a SA pair, using the key management methods introduced in Section 2. The protocol is composed of three parts, as shown in Figure 4. C RS AS | | | | [------ Resource Request ------>] | | (1) | | | | [<------ AS Information --------] | | | | | --- | | | | | | | --------- Token Request ------------------------------> | (2) | | | | | | Access Token + RS Information | | <------------------------------------------------------ | | Including information for IPsec SA establishment | | | --- | | | | | | | --------- Access Token ---------> | | | | | | [<=== IPsec SA establishment ==>] | | (3) | | | | ======== Resource Request ======> | | | | | | <======= Resource Response ====== | | | | | Figure 4: Protocol Overview Aragon, et al. Expires May 2, 2018 [Page 7] Internet-Draft IPsec profile of ACE October 2017 3.1. Unauthorized Client to RS Phase (1) in Figure 4 is OPTIONAL and aims at providing C with the necessary information to contact the AS, in case C does not know AS's address. Through an unauthorized request to RS, C determines which AS is responsible for granting authorization to that particular RS. When doing so, C learns to which address the Access Token Request has to be addressed. The unauthorized request is denied by RS, which sends back to C a response containing the information to contact the AS. 3.2. Client to AS Phase (2) in Figure 4 starts with C sending the Access Token Request to the /token endpoint at the AS, as specified in Section 5.5.1 of [I-D.ietf-ace-oauth-authz]. Figure 2 and Figure 3 of [I-D.ietf-ace-oauth-authz] provide examples of such request. If the AS successfully verifies the Access Token Request and C is authorized to access the resource specified in the Token Request, then the AS issues the corresponding Access Token and includes it in a CoAP response with code 2.01 (Created) as specified in Section 5.5.2 of [I-D.ietf-ace-oauth-authz]. The AS can signal that IPsec is REQUIRED to secure communications between C and RS by including the "profile" parameter with the value "coap_ipsec" in the Access Token Response. Together with authorization information, the Access Token also includes the same information for the set up of the IPsec channel included in the Access Token Response. The error response procedures defined in Section 5.5.3 of [I-D.ietf-ace-oauth-authz] are unchanged by this profile. The information exchanged between C and the AS depends on the specific method used to set up the SA pair (see Section 3.2.1, Section 3.2.2 and Section 3.2.3). Note that, unless Direct Provisioning of SAs is used, C and RS are required to finalize the SA pair set up by running a Key Management Protocol such as IKEv2 (see Section 3.3.2). The AS indicates to use IKEv2 for establishing a SA pair by setting the "kmp" field to "ikev2" in the "cnf" parameter in the Access Token Response. As specified in Section 5.5 of [I-D.ietf-ace-oauth-authz], the Client and the AS can also use CoAP instead of HTTP to communicate via the /token endpoint. This communication channel MUST be secured. This section specifies how to use IPsec [RFC4301] to protect the channel between the Client and the AS. The use of IPsec for this communication channel is OPTIONAL in this profile, and other security Aragon, et al. Expires May 2, 2018 [Page 8] Internet-Draft IPsec profile of ACE October 2017 protocols MAY be used instead, such as DTLS [RFC6347] and OSCORE [I-D.ietf-core-object-security]. The Client and the AS are either expected to have pre-established a pair of IPsec SA or to have pre-established credentials to authenticate an IKEv2 key exchange. How these credentials are established is out of scope for this profile. 3.2.1. Direct Provisioning of SA pairs If the AS selects this key management method, it encodes the SA pair in the Access Token and in the Access Token Response as an "ipsec" structure in the "cnf" parameter. Figure 5 shows an example of an Access Token Response, signaling C to set up an IPsec channel with RS based on the ESP protocol in transport mode. Header: Created (Code=2.01) Content-Type: "application/cose+cbor" Payload : { "access_token" : b64'YiksuH&=1GFfg ... (remainder of Access Token omitted for brevity)', "profile" : "coap_ipsec", "expires_in" : "3600", "cnf" : { "ipsec" : { "mode" : "transport", "protocol" : "ESP", "life" : "3600", "SPI_SA_C" : "87615", "SPI_SA_RS" : "87616", "seed" : b64'+a+Dg2jjU+eIiOFCa9lObw', "alg" : "AES-CCM-16-64-128", ... (the Network Parameters are omitted for brevity), } } } Figure 5: Example of Access Token Response with DP of SA pair 3.2.2. SA Establishment Based on Symmetric Keys If the AS selects this key management method, it specifies the following pieces of information in the Access Token Response and in the Access Token: Aragon, et al. Expires May 2, 2018 [Page 9] Internet-Draft IPsec profile of ACE October 2017 o a symmetric key to be used as proof-of-possession key; o a key identifier associated to the symmetric key; o SA pair's Network Parameters and Security Parameters, as an "ipsec" structure in the "cnf" parameter (see Section 2.1). If C has previously received a PSK from the AS, then C MUST provide a key identifier of that PSK either directly in the "kid" field of "cnf" parameter or in the "kid" field of the "COSE_Key" object of the Access Token Request. In this case, the AS omits the PSK and its identifier in the Access Token Response. The AS indicates the use of symmetric cryptography for the key management message exchange in the "kty" field of the "COSE_Key" object, including also the PSK in the "k" field as well as its key identifier in the "kid" field, as shown in Figure 6. Header: Created (Code=2.01) Content-Type: "application/cose+cbor" Payload: { "access_token" : b64'YiksuH&=1GFfg ... (remainder of Access Token omitted for brevity)', "profile" : "coap_ipsec", "expires_in" : "3600", "cnf" : { "COSE_Key" : { "kty" : "Symmetric", "kid" : b64'6kwi42ec', "k" : b64'+pAd48jU+eIiOF23gd=', } "kmp": "ikev2", "ipsec" : { "mode" : "tunnel", "protocol" : "ESP", "life" : "1800", "IP_C" : "a.b.c.d2", "IP_RS" : "a.b.c.d1", ... (the Network Parameters are omitted for brevity), } } } Figure 6: Example of Access Token Response with a symmetric key as proof-of-possession key. Aragon, et al. Expires May 2, 2018 [Page 10] Internet-Draft IPsec profile of ACE October 2017 3.2.3. SA Establishment Based on Asymmetric Keys C MUST include its own public key in the Access Token Request, as shown in Figure 7. As an alternative, C MUST provide the key identifier of its own public key, previously shared with the AS. The AS specifies in the Access Token and in the Access Token Response the SA pair's Network Parameters and Security Parameters, as an "ipsec" structure in the "cnf" parameter (see Section 2.1). In addition, the AS specifies the RS's public key in the Access Token Response, and the C's public key to be used as proof-of-possession key in the Access Token. The AS indicates the use of asymmetric cryptography for the key management message exchange in the "kty" field of the "COSE_Key" object, which includes also the RS's public key in the Access Token Response and the C's public key in the Access Token. Header: POST (Code=0.02) Uri-Host: "server.example.com" Uri-Path: "token" Content-Type: "application/cose+cbor" Payload: { "grant_type" : "client_credentials", "cnf" : { "COSE_Key" : { "kty" : "EC", "crv" : "P-256", "x" : b64'CaFadPPavdtjRH3YqaTqm0FrFtNV0', "y" : b64'ehekJBwciJdeT6cKieycnk6kg4pHC' } } } Figure 7: Example of Access Token Request with an asymmetric key as proof-of-possession key. 3.3. Client to RS Phase (3) in Figure 4 starts with C posting the Access Token by means of a POST CoAP message to the /authz-info endpoint at RS, as specified in Section 5.7 of [I-D.ietf-ace-oauth-authz]. The processing details of this request, as well as the handling of invalid Access Tokens at RS, are defined in Section 5.7.1 of [I-D.ietf-ace-oauth-authz] and in the rest of this section. The Access Token and Access Token Response specify one of the SA setup Aragon, et al. Expires May 2, 2018 [Page 11] Internet-Draft IPsec profile of ACE October 2017 methods defined in Section 2. In particular, C and RS determine the specific SA setup method as follows: o In case of Direct Provisioning, the "ipsec" structure is present, while the "COSE_Key" object is not present. o If the SA pair set up based on Symmetric Keys through IKEv2 is used, then: * the "COSE_Key" object is present with the "kty" field set to "Symmetric"; and * the "kmp" parameter is set to "ikev2". o If the SA pair set up based on Asymmetric Keys through IKEv2 is used, then: * the "COSE_Key" object is present with the "kty" field set to a value that indicates the use of an asymmetric key, e.g. "EC"; and * the "kmp" parameter is set to "ikev2". If the Direct Provisioning method is used, then C and RS do not perform the SA establishment shown in Figure 4. Otherwise, C and RS perform the key management protocol indicated by the "kmp" parameter (such as IKEv2), in the authentication mode indicated by the "kty" field of the "COSE_key" object. Regardless the chosen SA setup method and the successful establishment of the IPsec channel, if C holds a valid Access Token but this does not grant access to the requested protected resource, RS MUST send a 4.03 (Forbidden) response. Similarly, if the Access Token does not cover the intended action, RS MUST send a 4.05 (Method Not Allowed) response. 3.3.1. SA Direct Provisioning Once received a positive Access Token Response from the AS, C derives the necessary IPsec key material from the "seed" field of the "ipsec" structure in the Access Token Response, as discussed in Section 2.1. Similarly, RS performs the same key derivation process upon receiving and successfully verifying the Access Token. After that, RS replies to C with a 2.01 (Created) response, using the IPsec channel specified by the SA pair. Thereafter, Resource Requests and Responses are also sent using the IPsec channel. Aragon, et al. Expires May 2, 2018 [Page 12] Internet-Draft IPsec profile of ACE October 2017 3.3.2. Authenticated SA Establishment If an Authenticated Key Management method is used (see Section 3.2.2 and Section 3.2.3), C and RS MUST run a Key Management Protocol to finalize the establishment of the SA pair and the IPsec channel, i.e. the required keys and algorithms. As shown in Figure 8, the first message IKE_SA_INIT of the IKEv2 protocol is used to acknowledge the Access Token submission. Depending on the used authentication method, i.e. symmetric or asymmetric, the proof-of-possession key MUST be used accordingly to authenticate the IKEv2 message exchange as defined in Section 2.15 of [RFC7296]. The rest of the IKEv2 protocol MUST be executed between C and RS as described in Section 2 of [RFC7296], with no further modifications. If IKEv2 is successfully completed, C and RS agree on keys and algorithms to use, and thus the IPsec channel between C and RS is ready to be used. Resource Client Server | | | | +--------->| Header: POST (Code=0.02) | POST | Uri-Path:"authz-info" | | Content-Type: application/cbor | | Payload: Access Token | | |<---------+ IKE_SA_INIT | | ... Figure 8: IKEv2 used as Key Management Protocol. 3.4. RS to AS As specified in Section 5.6 of [I-D.ietf-ace-oauth-authz], the RS and the AS can also use CoAP instead of HTTP to communicate via the /introspect endpoint. This communication channel MUST be secured. This section specifies how to use IPsec to protect the channel between the RS and the AS. The use of IPsec for this communication channel is OPTIONAL in this profile, and other security protocols MAY be used instead, such as DTLS [RFC6347] and OSCORE [I-D.ietf-core-object-security]. The RS and the AS are either expected to have pre-established a pair of IPsec SA or to have pre-established credentials to authenticate an IKEv2 key exchange. How these credentials are established is out of scope for this profile. Aragon, et al. Expires May 2, 2018 [Page 13] Internet-Draft IPsec profile of ACE October 2017 4. Security Considerations This document inherits the security considerations of [RFC4301], [RFC4302] and [RFC4303]. Furthermore, if IKEv2 is used as key establishment method (see Section 3.3.2), the same considerations discussed in [RFC7296] hold. 4.1. Privacy Considerations The message exchange in Phase (1) of Figure 4 is unprotected and MAY disclose the relation between the AS, RS and C, as well as network related information, such as IP addresses. Thus RS SHOULD only include the necessary information to contact the AS in the unprotected response. 5. IANA Considerations This document requires the following IANA considerations: +---------+-------+----------------+------------+-------------------+ | name | label | CBOR type | value | description | +---------+-------+----------------+------------+-------------------+ | kmp | TBD | bstr | ikev2 | Indicates the | | | | | | key management | | | | | | protocol to be | | | | | | used to establish | | | | | | a SA pair | | | | | | | | ipsec | TBD | struct | | Contains Security | | | | | | and Network | | | | | | Parameters of an | | | | | | SA pair | +---------+-------+----------------+------------+-------------------+ 5.1. CoAP-IPsec Profile registration o Profile name: CoAP-IPsec o Profile description: ACE Framework profile o Profile ID: coap_ipsec o Change Controller: IESG o Specification Document: This document Aragon, et al. Expires May 2, 2018 [Page 14] Internet-Draft IPsec profile of ACE October 2017 5.2. Confirmation Methods registration 5.2.1. IPsec field o Confirmation Method Name: "ipsec" o Confirmation Method Value: TBD o Confirmation Method Description: A structure containing the corresponding information of an IPsec Security Association Pair. o Change Controller: IESG o Specification Document: This document 5.2.2. Key Management Protocol field o Confirmation Method Name: "kmp" o Confirmation Method Value: TBD o Confirmation Method Description: Key management protocol. o Change Controller: IESG o Specification Document: This document 5.3. Key Management Protocol Methods Registry This specification establishes the IANA "Key Management Protocol Methods" registry for the "kmp" member values. The registry records the confirmation method member and a reference to the spec that defines it. 5.3.1. Registration Template Key Management Protocol Method Name: The name requested (e.g. "ikev2"). This name is intended to be human readable and be used for debugging purposes. It is case sensitive. Names may not match other registered names in a case- insensitive manner unless the Designated Experts state that there is a compelling reason to allow an exception. Key Management Protocol Method Value: Aragon, et al. Expires May 2, 2018 [Page 15] Internet-Draft IPsec profile of ACE October 2017 Integer representation for the confirmation method value. Intended for use to uniquely identify the confirmation method. The value MUST be an integer in the range of 1 to 65536. Key Management Protocol Method Description: Brief description of the confirmation method (e.g. "Key Identifier"). Change Controller: For Standards Track RFCs, list the "IESG". For others, give the name of the responsible party. Other details (e.g. postal address, email address, home page URI) may also be included. Specification Document(s): Reference to the document or documents that specify the parameter, preferably including URIs that can be used to retrieve copies of the documents. An indication of the relevant sections may also be included but is not required. 5.3.2. Initial Registry Contents o Key Management Protocol Method Name: "ikev2" o Key Management Protocol Method Value: TBD o Key Management Protocol Method Description: Defines IKEv2 as key management protocol. o Change Controller: IESG o Specification Document: this document 6. Acknowledgments The authors sincerely thank Max Maass for his comments and feedback. The authors gratefully acknowledge the EIT-Digital Master School for partially funding this work. 7. References Aragon, et al. Expires May 2, 2018 [Page 16] Internet-Draft IPsec profile of ACE October 2017 7.1. Normative References [I-D.ietf-ace-oauth-authz] Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and H. Tschofenig, "Authentication and Authorization for Constrained Environments (ACE)", draft-ietf-ace-oauth- authz-08 (work in progress), October 2017. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, December 2005, . [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, DOI 10.17487/RFC4302, December 2005, . [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, DOI 10.17487/RFC4303, December 2005, . [RFC4835] Manral, V., "Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH)", RFC 4835, DOI 10.17487/RFC4835, April 2007, . [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained Application Protocol (CoAP)", RFC 7252, DOI 10.17487/RFC7252, June 2014, . [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. Kivinen, "Internet Key Exchange Protocol Version 2 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 2014, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . Aragon, et al. Expires May 2, 2018 [Page 17] Internet-Draft IPsec profile of ACE October 2017 7.2. Informative References [I-D.ietf-ace-actors] Gerdes, S., Seitz, L., Selander, G., and C. Bormann, "An architecture for authorization in constrained environments", draft-ietf-ace-actors-05 (work in progress), March 2017. [I-D.ietf-core-object-security] Selander, G., Mattsson, J., Palombini, F., and L. Seitz, "Object Security for Constrained RESTful Environments (OSCORE)", draft-ietf-core-object-security-06 (work in progress), October 2017. [I-D.seitz-ace-oscoap-profile] Seitz, L., Palombini, F., and M. Gunnarsson, "OSCORE profile of the Authentication and Authorization for Constrained Environments Framework", draft-seitz-ace- oscoap-profile-06 (work in progress), October 2017. [I-D.selander-ace-cose-ecdhe] Selander, G., Mattsson, J., and F. Palombini, "Ephemeral Diffie-Hellman Over COSE (EDHOC)", draft-selander-ace- cose-ecdhe-07 (work in progress), July 2017. [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, January 2012, . [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", RFC 6749, DOI 10.17487/RFC6749, October 2012, . [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", RFC 8152, DOI 10.17487/RFC8152, July 2017, . Appendix A. Coexistence of OSCORE and IPsec Object Security of Constrained RESTful Environments (OSCORE) [I-D.ietf-core-object-security] is a data object based security protocol that protects CoAP messages end-to-end while allowing proxy operations. It encloses unprotected CoAP messages, and selected CoAP options and headers fields into a CBOR Object Signing and Encryption (COSE) object [RFC8152]. This section describes a scenario where communications between C and RS are secured by means of OSCORE and IPsec. Figure 9 depicts a scenario where a Client needs to access a Aragon, et al. Expires May 2, 2018 [Page 18] Internet-Draft IPsec profile of ACE October 2017 Resource Server which is behind an untrusted CoAP-Proxy. This scenario requires that: 1. the Proxy has access to the selected CoAP options to perform management and support operations; 2. the integrity of messages and their IP headers can be verified by the Resource Server; 3. the confidentiality of the Resource Server address and CoAP request has to be guaranteed between the Client and the Proxy. The first requirement is addressed by means of an OSCORE channel between the Client and the Resource Server established as described in [I-D.seitz-ace-oscoap-profile]), by marking as Class E the sensitive fields of the CoAP payload as defined in [I-D.ietf-core-object-security]. To address the second requirement, a SA pair between the Client and the Resource Server is established, as specified in Section 3, by using the IPsec AH protocol in transport mode. Finally, the third requirement is fulfilled by means of a SA pair between the Client and the CoAP-Proxy, as specified in Section 3, by using the IPsec ESP protocol in tunnel mode. This profile can be used to establish the necessary SA pairs. After that, C can request a token update to the AS, in order to establish an OSCORE security context with RS, as specified in Section 2.2 of [I-D.seitz-ace-oscoap-profile]. Figure 9 overviews the involved secure communication channels. Logical links such as the SA pair shared between the Client and the Proxy are represented by dotted lines. IPsec traffic is depicted with double-dashed lines, and an example of the packets going through these links is represented with numbers, e.g. (1). The destination address included in the IP headers is also specified, e.g. "IP:P" indicates the Proxy's address as destination address. The source address of the IP header is omitted, since all the IP packets have the Client's address as source address. Aragon, et al. Expires May 2, 2018 [Page 19] Internet-Draft IPsec profile of ACE October 2017 OSCORE context & SA AH-transport . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SA ESP-tunnel . . . . . . . . . . . . . . . . . . . . . v v v v +--------+ +--------+ +------+ | Client | <==== (1) ====> | Proxy | <==== (2) ====> | RS | +--------+ +--------+ +------+ (1): |IP:P|ESP|IP:RS|AH|UDP|OSCORE|ESP_T|ESP_Auth| (2): |IP:RS|AH|UDP|OSCORE| Figure 9: OSCORE and IPsec - Scenario overview Appendix B. SA Establishment with EDHOC As discussed in Appendix A, securing communications between C and RS with both OSCORE and IPsec makes it possible to fulfill a number of additional security requirements. An OSCORE security context between C and RS can be established using Ephemeral Diffie-Hellman Over COSE (EDHOC) as defined in Appendix C.2 of [I-D.selander-ace-cose-ecdhe] and according to [I-D.seitz-ace-oscoap-profile]. This section proposes a method to establish also IPsec SA pairs by means of EDHOC. This makes it possible for constrained devices running the scenario described in Appendix A to rely solely on EDHOC for establishing both OSCORE contexts and IPsec SA pairs, thus avoiding to include the implementation of IKEv2 as further key management protocol. In particular, C and RS can refer to the SA Authenticated Establishment methods described in this specification, and then use EDHOC to finalize the SA pair, i.e. by deriving the encryption and authentication keys for the security protocols specified in the SA pair. This is possible thanks to IPsec's independence from specific key management protocols. In addition, the same security consideration discussed in [I-D.selander-ace-cose-ecdhe] hold. The AS, C and RS refer to the same protocol shown in Figure 4, with the following changes. B.1. Client to AS The AS specifies the fields "alg", "SPI_SA_C" and "SPI_SA_RS" of the "ipsec" structure in the Access Token and in the Access Token Response, in addition to the pieces of information defined in Aragon, et al. Expires May 2, 2018 [Page 20] Internet-Draft IPsec profile of ACE October 2017 Section 3.2.2 or Section 3.2.3, in case the proof-of-possession key is symmetric or asymmetric, respectively. The AS signals that EDHOC MUST be used, by setting the "kmp" field to "edhoc" in the Access Token and the Access Token Response. Then, C and RS MUST perform EDHOC as described in Section 4 or Section 5 of [I-D.selander-ace-cose-ecdhe], in case the proof-of-possession key is asymmetric or symmetric, respectively. B.2. Client to RS Figure 10 shows how EDHOC message_1 is sent through a POST Access Token Request to the /authz-info at the RS. The RS SHALL process the Access Token according to [I-D.ietf-ace-oauth-authz], and, if valid, continue with the EDHOC protocol as defined in Appendix C.1 of [I-D.selander-ace-cose-ecdhe]. Otherwise, RS aborts EDHOC and responds with an error code as specified in [I-D.ietf-ace-oauth-authz]. At the end of the EDHOC protocol, C and RS MUST derive an IPsec seed from the EDHOC shared secret. The seed is derived as specified in Section 3.2 of [I-D.selander-ace-cose-ecdhe], with other=exchange_hash, AlgorithmID="EDHOC IKE seed" and keyDataLength equal to the key length of the SKEYSEED secret defined in Section 2.14 of [RFC7296]. After that, the derived seed is written in the "seed" field of the "ipsec" structure, and accordingly used to derive IPsec key material as described in Section 2.1. Resource Client Server | | | | +-------->| Header: POST (Code=0.02) | POST | Uri-Path:"authz-info" | | Content-Type: application/cbor | | Payload: EDHOC message_1 + Access Token | | ... Figure 10: EDHOC used as Key Management Protocol Authors' Addresses Aragon, et al. Expires May 2, 2018 [Page 21] Internet-Draft IPsec profile of ACE October 2017 Santiago Aragon RISE SICS AB Isafjordsgatan 22 Kista SE-164 29 Sweden Email: santiago.aragon@stud.tu-darmstadt.de Marco Tiloca RISE SICS AB Isafjordsgatan 22 Kista SE-164 29 Sweden Phone: +46 70 604 65 01 Email: marco.tiloca@ri.se Shahid Raza RISE SICS AB Isafjordsgatan 22 Kista SE-164 29 Sweden Phone: +46 76 883 17 97 Email: shahid.raza@ri.se Aragon, et al. Expires May 2, 2018 [Page 22]