idnits 2.17.1 draft-sprasad-ipsecme-labeled-ipsec-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 : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC7296, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 4, 2018) is 2237 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'TBD' is mentioned on line 195, but not defined ** Downref: Normative reference to an Informational RFC: RFC 4595 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network S. Prasad 3 Internet-Draft Technical University of Munich 4 Updates: 7296 (if approved) P. Wouters 5 Intended status: Standards Track Red Hat 6 Expires: September 5, 2018 March 4, 2018 8 Labeled IPsec Traffic Selector support for IKEv2 9 draft-sprasad-ipsecme-labeled-ipsec-00 11 Abstract 13 Some IPsec implementations support Security Labels otherwise known as 14 Security Contexts, to be configured as a selector within the Security 15 Policy Database (SPD) for IPsec SAs. This document adds support to 16 IKEv2 to negotiate these Security Labels or Contexts using a new 17 Traffic Selector (TS) Type TS_SECLABEL. The approach is named 18 "Labeled IPsec". It assumes that the SPD processing of RFC 4303 is 19 already extended to support Security Labels. This document only adds 20 the ability for IKE to negotiate the Security Labels used with the 21 SPD. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on September 5, 2018. 40 Copyright Notice 42 Copyright (c) 2018 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (https://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 59 2. Labeled IPsec Traffic Selector . . . . . . . . . . . . . . . 3 60 2.1. Narrowing of Labeled IPsec Traffic Selector . . . . . . . 4 61 3. Security Considerations . . . . . . . . . . . . . . . . . . . 4 62 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 63 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 64 5.1. Normative References . . . . . . . . . . . . . . . . . . 5 65 5.2. Informative References . . . . . . . . . . . . . . . . . 5 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 68 1. Introduction 70 A Security Context or Security Label is a mechanism used to classify 71 resources. It allows the enforcement of rules on how or by whom 72 these resources are accessable. This document introduces a mechanism 73 to negotiate these values using IKE. This negotiation is done via a 74 new Traffic Selector (TS) Type in the TSi/TSr Payloads of the 75 IKE_AUTH Exchange. 77 Traffic Selector (TS) payloads allow endpoints to communicate some of 78 the information from their SPD to their peers. Section 2.9 in the 79 Internet Key Exchange protocol version 2 [RFC7296] illustrates the 80 Traffic selector negotiation procedure. 82 Two or more TS payloads appear in each of the messages in the 83 exchange that creates a Child SA pair. Each TS payload contains one 84 or more Traffic Selectors. The Traffic Selector types 85 TS_IPV4_ADDR_RANGE and TS_IPV6_ADDR_RANGE consists of an address 86 range, a port range, and an IP protocol ID. [RFC4595] defines 87 Traffic Selector type TS_FC_ADDR_RANGE to denote a list of Fibre 88 Channel (FC) addresses and protocol ranges. This document extends 89 the above set by adding a new TS Type that allows endpoints to agree 90 on assigning a Security Label or Context to the IPsec SA. 92 Negotiating and applying the Security Label or Context in the new TS 93 Type will act as an additional selector criterium that has to match 94 along with any other existing Traffic Selectors. 96 1.1. Requirements Language 98 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 99 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 100 document are to be interpreted as described in RFC 2119 [RFC2119]. 102 2. Labeled IPsec Traffic Selector 104 Labeled IPsec Traffic Selectors allow endpoints to negotiate the 105 Security Label using the Selector Type TS_SECLABEL. In addition to 106 the regular prcessing of Traffic Selectors as described in 107 Section 3.13.1 of [RFC7296], the context or label of an IP packet now 108 also has to match the Security Label Traffic Selector. 110 0 1 2 3 111 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 112 +---------------+---------------+-------------------------------+ 113 | TS TYPE | Reserved | Selector Length | 114 +---------------+---------------+-------------------------------+ 115 | | 116 ~ Security Label ~ 117 | | 118 +---------------------------------------------------------------+ 120 o TS TYPE (one octet) - Specifies the type of Traffic Selector. 122 o Selector Length (2 octets, network byte order) - Specifies the 123 length of Security Label including the header. 125 o Security Label - This field contains the opaque payload. 127 The following table lists the assigned value for the Labeled IPsec 128 Traffic Selector Type field: 130 TS Type Value 131 ------- ----- 132 TS_SECLABEL [TBD] 134 To indicate support and a requirement for agreeing on a specific 135 security context, the initiator MUST include the security context or 136 label via TS_SECLABEL in the TSi (Traffic Selector-initiator) and TSr 137 (Traffic Selector-responder) Payloads. On reception of TS_SECLABEL, 138 the responder MUST find a matching Security Policy Database (SPD) 139 entry that contains a Security Label and match the proposed label. 140 Assuming that this proposal was acceptable to the responder, it would 141 send the same or narrowed TS payloads in the IKE_AUTH reply. If the 142 Security Label was not found in the SPD by the responder, it MUST 143 respond with a TS_UNACCEPTABLE Notify message. 145 As per section 2.9.2 in [RFC7296], TS sets MUST BE kept identical 146 during rekey. If a Security Label needs to change, the IPsec SA must 147 be torn down and a new one must be negotiated with the updated 148 TS_SECLABEL values. 150 2.1. Narrowing of Labeled IPsec Traffic Selector 152 The IKE daemon might or might not be able to interpret the Security 153 Label beyond an exact match. It might be possible for the IKE daemon 154 to apply narrowing to the Security Labels. For example, a Security 155 Label "Top Secret" could mean that this IPsec SA may also transport 156 traffic with label "Secret". An initiator requesting "Top Secret" 157 might be willing to be narrowed down to a "Secret" security context. 158 Or a security context of "*" might mean "any security context". If 159 the daemon does not interpret the Security Label, then it can only 160 support an exact match of the raw data of the TS. 162 The rules of responder narrowing as explained in section 2.9 in 163 [RFC7296] are applicable to TS_SECLABEL. 165 The TS_SECLABEL Traffic Selector Type if present MUST be mutually 166 agreed upon. If one side includes a TS_SECLABEL and the other sides 167 does not, the IPsec SA negotiation MUST fail with TS_UNAVAILABLE. If 168 a responder insists on a TS_SECLABEL security context and receives a 169 TSi/TSr set that does not contain a TS_SECLABEL Traffic Selector, it 170 MUST fail the negotiation with TS_UNAVAILABLE. 172 DISCUSS: Should a TS_SECLABEL of length 0 be allowed? If so, should 173 it mean "any label" ? 175 3. Security Considerations 177 While matching the Security Label on the endpoints, an assumption 178 that the Security label will contain only ASCII text MUST NOT be 179 made. If the Security Label is handed off to a helper routine for 180 interpretation, it MUST be assumed that the content can be malicious. 181 While Security Labels might look like text, there is no guarantee 182 this text is null terminated. 184 Any errors in handling the SPD entry, such as failing to add the SPD 185 entry with the negotiated Security Label, MUST be abled as any other 186 failure of SPD processing as defined in [RFC4303]. 188 4. IANA Considerations 190 This document defines one new Traffic Selector Type in the IKEv2 191 Traffic Selector Types Registry namespace. 193 TS Type Value 194 ------- ----- 195 TS_SECLABEL [TBD] 197 Figure 1 199 5. References 201 5.1. Normative References 203 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 204 Requirement Levels", BCP 14, RFC 2119, 205 DOI 10.17487/RFC2119, March 1997, 206 . 208 [RFC4595] Maino, F. and D. Black, "Use of IKEv2 in the Fibre Channel 209 Security Association Management Protocol", RFC 4595, 210 DOI 10.17487/RFC4595, July 2006, 211 . 213 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 214 Kivinen, "Internet Key Exchange Protocol Version 2 215 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 216 2014, . 218 5.2. Informative References 220 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 221 RFC 4303, DOI 10.17487/RFC4303, December 2005, 222 . 224 Authors' Addresses 226 Sahana Prasad 227 Technical University of Munich 229 Email: sahana.prasad07@gmail.com 230 Paul Wouters 231 Red Hat 233 Email: pwouters@redhat.com