idnits 2.17.1 draft-ietf-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 10, 2019) is 1873 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 167, but not defined Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network P. Wouters 3 Internet-Draft Red Hat 4 Intended status: Standards Track S. Prasad 5 Expires: September 11, 2019 Technical University of Munich 6 March 10, 2019 8 Labeled IPsec Traffic Selector support for IKEv2 9 draft-ietf-ipsecme-labeled-ipsec-00 11 Abstract 13 This document defines two new Traffic Selector (TS) Types for 14 Internet Key Exchange version 2 to add support for Mandatory Access 15 Control (MAC) security labels, also known as "Labeled IPsec". The 16 two new TS Types are TS_IPV4_ADDR_RANGE_SECLABEL and 17 TS_IPV6_ADDR_RANGE_SECLABEL, which are identical to their non- 18 seclabel namesakes except for the addition of a variable length 19 opaque field specifying the security label. These new Traffic 20 Selector Types facilitate negotiating security labels as an 21 additional selector of the Security Policy Database to further 22 restrict the type of traffic allowed to be send and received over the 23 IPsec SA. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on September 11, 2019. 42 Copyright Notice 44 Copyright (c) 2019 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 61 2. Traffic Selector negotiation . . . . . . . . . . . . . . . . 3 62 3. SECLABEL Traffic Selector . . . . . . . . . . . . . . . . . . 3 63 4. Traffic Selector matching . . . . . . . . . . . . . . . . . . 5 64 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 65 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 66 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 67 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 68 8.1. Normative References . . . . . . . . . . . . . . . . . . 6 69 8.2. Informative References . . . . . . . . . . . . . . . . . 7 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 72 1. Introduction 74 In computer security, Mandatory Access Control usually refers to 75 systems in which all subjects and objects are assigned a security 76 label. A security label is comprised of a set of security 77 attributes. The security labels along with a system authorization 78 policy determine access. Rules within the system authorization 79 policy determine whether the access will be granted based on the 80 security attributes of the subject and object. 82 Traditionally, security labels used by Multilevel Systems (MLS) are 83 comprised of a sensitivity level (or classification) field and a 84 compartment (or category) field, as defined in [FIPS188] and 85 [RFC5570]. As MAC systems evolved, other MAC models gained in 86 popularity. For example, SELinux, a Flux Advanced Security Kernel 87 (FLASK) implementation, has security labels represented as colon- 88 separated ASCII strings composed of values for identity, role, and 89 type. The security labels are often referred to as security 90 contexts. 92 This document specifies two new Traffic Selector Types for IKEv2 that 93 can be used to negotiate security labels as additional selectors for 94 the Security Policy Database (SPD) to further restrict the type of 95 traffic allowed to be send and received over the IPsec SA. 97 Traffic Selector (TS) payloads allow endpoints to communicate some of 98 the information from their SPD to their peers. These must be 99 communicated to IKE from the SPD. TS payloads specify the selection 100 criteria for packets that will be forwarded over the newly set up SA. 101 Section 2.9 in the Internet Key Exchange protocol version 2 [RFC7296] 102 illustrates the Traffic Selector negotiation procedure. 104 Two TS payloads appear in each of the messages in the exchange that 105 creates a Child SA pair. Each TS payload contains one or more 106 Traffic Selectors. Currently, each Traffic Selector consists of an 107 address range (IPv4 or IPv6), a port range, and an IP protocol ID. 108 However, a security context or a label is missing. Therefore this 109 document extends the section 2.9 in the Internet Key Exchange 110 protocol version 2 [RFC7296] to add support for a new traffic 111 selector type which would be used to negotiate the security label or 112 context. 114 Negotiating and verifying the security context or label in the new TS 115 types will act as an additional criteria that has to match along with 116 the previously mentioned Traffic Selectors. 118 1.1. Requirements Language 120 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 121 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 122 document are to be interpreted as described in RFC 2119 [RFC2119]. 124 2. Traffic Selector negotiation 126 The negotiation of Traffic Selectors is specified in Section 2.9 of 127 [RFC7296]. The initiating IKE peer sends a Traffic Selector payload 128 for the initiator side (TSi) and a Traffic Selector payload for the 129 responder side (TSr). The TSi and TSr payloads contain a list of one 130 or more Traffic Selectors (TS). The responder picks one TS from the 131 TSi list and one TS from the TSr list and returns these in their own 132 TSi/TSr payloads to the initiator in the IKE response as confirmation 133 of the chosen traffic selectors. [RFC7296] defines two TS Types, 134 TS_IPV4_ADDR_RANGE and TS_IPV6_ADDR_RANGE. These TS payloads contain 135 the TS Type, IP protocol ID, Selector Length, Start and End Port and 136 Start and End Address. 138 3. SECLABEL Traffic Selector 140 This document defines two new TS Types, TS_IPV4_ADDR_RANGE_SECLABEL 141 and TS_IPV6_ADDR_RANGE_SECLABEL. In addition to the above mentioned 142 selectors, it contains a single new opaque Security Label selector. 144 1 2 3 145 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 146 +---------------+---------------+-------------------------------+ 147 | TS Type |IP Protocol ID*| Selector Length | 148 +---------------+---------------+-------------------------------+ 149 | Start Port* | End Port* | 150 +-------------------------------+-------------------------------+ 151 | | 152 ~ Starting Address* ~ 153 | | 154 +---------------------------------------------------------------+ 155 | | 156 ~ Ending Address* ~ 157 | | 158 +---------------------------------------------------------------+ 159 | | 160 ~ Security Label* ~ 161 | | 162 +---------------------------------------------------------------+ 164 Figure 1: Labeled IPsec Traffic Selector 166 *Note: All fields other than TS Type and Selector Length depend on 167 the TS Type. The fields shown are for TS Types [TBD] and [TBD], the 168 two values this document defines. 170 o TS Type (one octet) - Specifies the type of Traffic Selector. 172 o IP protocol ID (1 octet) - Value specifying an associated IP 173 protocol ID (such as UDP, TCP, and ICMP). A value of zero means 174 that the protocol ID is not relevant to this Traffic Selector -- 175 the SA can carry all protocols. 177 o Selector Length (2 octets, unsigned integer) - Specifies the 178 length of this Traffic Selector substructure including the header. 180 o Start Port (2 octets, unsigned integer) - Value specifying the 181 smallest port number allowed by this Traffic Selector. For 182 protocols for which port is undefined (including protocol 0), or 183 if all ports are allowed, this field MUST be zero. ICMP and 184 ICMPv6 Type and Code values, as well as Mobile IP version 6 185 (MIPv6) mobility header (MH) Type values, are represented in this 186 field as specified in Section 4.4.1.1 of [RFC4301]. ICMP Type and 187 Code values are treated as a single 16-bit integer port number, 188 with Type in the most significant eight bits and Code in the least 189 significant eight bits. MIPv6 MH Type values are treated as a 190 single 16-bit integer port number, with Type in the most 191 significant eight bits and the least significant eight bits set to 192 zero. 194 o End Port (2 octets, unsigned integer) - Value specifying the 195 largest port number allowed by this Traffic Selector. For 196 protocols for which port is undefined (including protocol 0), or 197 if all ports are allowed, this field MUST be 65535. ICMP and 198 ICMPv6 Type and Code values, as well as MIPv6 MH Type values, are 199 represented in this field as specified in Section 4.4.1.1 of 200 [RFC4301]. ICMP Type and Code values are treated as a single 201 16-bit integer port number, with Type in the most significant 202 eight bits and Code in the least significant eight bits. MIPv6 MH 203 Type values are treated as a single 16-bit integer port number, 204 with Type in the most significant eight bits and the least 205 significant eight bits set to zero. 207 o Starting Address - The smallest address included in this Traffic 208 Selector (length determined by TS Type). 210 o Ending Address - The largest address included in this Traffic 211 Selector (length determined by TS Type). 213 o Security Label - An opaque byte stream of at least one octet. 215 4. Traffic Selector matching 217 Matching of the IP protocol, start and end address, and start and end 218 port is performed the same way as for the TS_IPV4_ADDR_RANGE and 219 TS_IPV6_ADDR_RANGE TS types. Additionally, the Security Label is 220 compared for an exact match as well. Label matching is done by 221 comparing the opaque bytestream. 223 The Security Label in the TSi and TSr MUST be identical. If the 224 responder's policy does not allow it to accept any part of the 225 proposed Traffic Selector including the Security Label, it MUST 226 ignore the TS and look for another matching TS in the list. If no 227 list entry matches, a TS_UNACCEPTABLE Notify message is returned. 229 A zero length Security Label MUST NOT be sent. If the SPD policy 230 contains no Security Label selectors, the TS Types 231 TS_IPV4_ADDR_RANGE_SECLABEL and TS_IPV6_ADDR_RANGE_SECLABEL should 232 not be used and TS_IPV4_ADDR_RANGE and TS_IPV6_ADDR_RANGE should be 233 used instead. Any received Traffic Selector with a zero length 234 Security Label MUST be ignored, and if no valid TS can be selected, 235 an TS_UNACCEPTABLE Error Notify message is returned. A zero length 236 Security Label MUST NOT be interpreted as a wildcard security label. 238 If multiple Security Labels are allowed for a given IP protocol, 239 start and end address/port match, multiple 240 TS_IPV4_ADDR_RANGE_SECLABEL or TS_IPV6_ADDR_RANGE_SECLABEL Traffic 241 Selectors must be included that only differ in the Security Label. 243 Narrowing of Traffic Selectors applies to TS_IPV4_ADDR_RANGE_SECLABEL 244 and TS_IPV6_ADDR_RANGE_SECLABEL as well, but the Security Label 245 itself is not interpreted and cannot itself be narrowed. It MUST be 246 matched exactly. Rekey of an IPsec SA MUST only use identical 247 Traffic Selectors, which means the same TS Type and selectors MUST be 248 used. This guarantees that a Security Label once negotiated, remains 249 part of the IPsec SA after a rekey. 251 5. Security Considerations 253 It is assumed that the Security Label can be matched by the IKE 254 implementation to its own configured value, even if the IKE 255 implemention itself cannot interpret the Security Label value. 257 6. IANA Considerations 259 This document defines two new entries in the IKEv2 Traffic Selector 260 Types registry: 262 Value TS Type Reference 263 ----- --------------------------- ----------------- 264 TBD TS_IPV4_ADDR_RANGE_SECLABEL [this document] 265 TBD TS_IPV6_ADDR_RANGE_SECLABEL [this document] 267 Figure 2 269 7. Acknowledgements 271 A large part of the introduction text was taken verbatim from 272 [draft-jml-ipsec-ikev2-security-label] whose authors are J Latten, D. 273 Quigley and J. Lu. Part of the Traffic Selector description is 274 reproduced from [RFC7296]. 276 8. References 278 8.1. Normative References 280 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 281 Requirement Levels", BCP 14, RFC 2119, 282 DOI 10.17487/RFC2119, March 1997, . 285 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 286 Kivinen, "Internet Key Exchange Protocol Version 2 287 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 288 2014, . 290 8.2. Informative References 292 [draft-jml-ipsec-ikev2-security-label] 293 Latten, J., Quigley, D., and J. Lu, "Security Label 294 Extension to IKE", draft-wouters-edns-tcp-keeaplive (work 295 in progress), January 2011. 297 [FIPS188] NIST, "National Institute of Standards and Technology, 298 "Standard Security Label for Information Transfer"", 299 Federal Information Processing Standard (FIPS) Publication 300 188, September 1994. 302 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 303 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 304 December 2005, . 306 [RFC5570] StJohns, M., Atkinson, R., and G. Thomas, "Common 307 Architecture Label IPv6 Security Option (CALIPSO)", 308 RFC 5570, DOI 10.17487/RFC5570, July 2009, 309 . 311 Authors' Addresses 313 Paul Wouters 314 Red Hat 316 Email: pwouters@redhat.com 318 Sahana Prasad 319 Technical University of Munich 321 Email: sahana.prasad07@gmail.com