idnits 2.17.1 draft-jml-ipsec-ikev2-security-label-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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC5996]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 28, 2011) is 4837 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) ** Obsolete normative reference: RFC 5996 (Obsoleted by RFC 7296) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Latten 3 Internet-Draft IBM 4 Intended Status: Standards Track D. Quigley 5 Expires: July 27, 2011 J. Lu 6 Oracle 7 January 28, 2011 9 Security Label Extension to IKE 10 draft-jml-ipsec-ikev2-security-label-01 12 Status of This Memo 14 This Internet-Draft is submitted in full conformance with the 15 provisions of BCP 78 and BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that other 19 groups may also distribute working documents as Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress". 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on July 27, 2011. 34 Copyright Notice 36 Copyright (c) 2010 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Abstract 51 This document describes extensions to the Internet Key Exchange 52 Protocol Version 2 [RFC5996] to support Mandatory Access Control 53 (MAC) security labels used on deployed systems. 55 1. Introduction 57 In computer security, Mandatory Access Control usually refers to 58 systems in which all subjects and objects are assigned a security 59 label. A security label is comprised of a set of security attributes. 60 The security labels along with a system authorization policy 61 determine access. Rules within the system authorization policy 62 determine whether the access will be granted based on the security 63 attributes of the subject and object. 65 Traditionally, security labels used by Multilevel Systems (MLS) are 66 comprised of a sensitivity level (or classification) field and a 67 compartment (or category) field, as defined in [FIPS188] and 68 [RFC5570]. As MAC systems evolved, other MAC models gained in 69 popularity. For example, SELinux, a Flux Advanced Security Kernel 70 (FLASK) implementation, has security labels represented as 71 colon-separated ASCII strings composed of values for identity, role, 72 and type. The security labels are often referred to as security 73 contexts. 75 This document will describe extensions to IKEv2 to support its 76 handling of security labels for implicit labeling schemes on 77 network communications. 79 2. Terminology 81 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 82 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 83 document are to be interpreted as described in [RFC2119]. 85 3. Implicit Labeled Networking 87 Within a MAC environment, a security label is applied to data (e.g. 88 IP packets) transmitted over the network. The MAC policy can then use 89 the label information to make informed access decisions. 91 In a traditional Multilevel System envionment, IP packets are labeled 92 with clear text labels. This is acceptable because the underlying 93 physical network is assumed to be secure in an MLS environment and 94 clear text labeling has performance advantage in secure physical 95 network envionments. An obvious disadvantage of labeling data in 96 clear text is its reliance on a secure physical network. This 97 limitaion prevents traditional MLS MAC systems from being useful on 98 public networks. With the proposed label extension to IKEv2, security 99 labels can be established as part of the IKE negotiation. The 100 security label is stored in the Security Association making it 101 unnecessary for data packets to carry security label information, 102 i.e. making packet labeling implicit. The implicit label scheme 103 retains security label requirements demanded by MAC systems, but 104 removes the reliance of underlying secure physical networks. 106 4. Security Label Transform 108 This document introduces a new transform type to communicate the 109 security label when creating Child SAs during the IKE_AUTH exchange 110 and CREATE_CHILD_SA exchange. Security label transforms are only 111 included in IPsec SAs and not IKE SAs. 113 The transform type value is: 115 Description Transform Type Used In 116 ................................................. 117 Security Label IANA ESP and AH 119 Only one security label transform containing only one security 120 label is required per protocol. The security label data MUST 121 be the same for each protocol within each proposal for a particular 122 SA payload. In other words, only one instance of a security label 123 is communicated for the proposed SA. 125 For Security Label Transform Type, the defined Transform IDs are: 127 Name Number Defined In 128 None 0 129 Label_Format_Selector_1 1 TBD 130 Label_Format_Selector_2 2 TBD 131 ... 133 The acceptable Label_Format_Selectors (LFSs) are described in 134 draft-quigley-label-format-regisry-00 (work-in-progress). The LFS 135 indicates the format of the security label and how the security label 136 is to be interpreted by the MAC layer. 138 This transform requires a transform attribute to communicate the 139 actual security label data. 141 The Transform Attribute Type: 143 Attribute Type Value Attribute Format 144 ............................................................. 145 Security Label IANA TLV 147 4.1 Attribute Negotiation 149 The LFS indicates to a remote peer whether the security label can be 150 understood and interpreted by the peer's MAC layer. 152 An initiating IKE communicates the LFS and the security label data 153 in the security label transform of a proposal. If the responder 154 receives an LFS it does not understand, then it MUST consider the 155 proposal unacceptable. IKE does not interpret the security label 156 data itself. 158 5. Security Considerations 160 [RFC5996] describes the NO_ADDITIONAL_SAS notification. 161 It is possible that a traffic stream may require an SA for each 162 instance of a security label on it. Thus a responder SHOULD be 163 willing to accept more than one SA pair on an IKE_SA in this case. 165 The addition of the security label transform should not change 166 the underlying security characteristics of IKE. 168 6. IANA Considerations 170 This document introduces the following IANA assignments: 172 - IKEv2 Transform Type for the security label. 174 Description Transform type 175 -------------------------------------------- 176 Security Label To be assigned by IANA 178 - IKEv2 Transform Attribute Type 180 Attribute Type Value Attribute Format 181 ------------------------------------------------------------ 182 Security Label To be assigned by IANA TLV 184 7. Acknowledgements 186 The authors would like to acknowledge Trent Jaeger, Serge Hallyn, 187 and George Wilson, architects of the original design and 188 implementation of labeled IPsec in Linux. The authors would also 189 like to thank Stephen Smalley, James Morris and members of the 190 SELinux community for their contributions during the initial design 192 The original design of labeled IPsec was implemented in Linux 193 with SELinux as it's MAC. Sun Microsystems also has a version 194 of labeled IPsec in OpenSolaris Trusted Extensions. 196 8. References 198 8.1 Normative References 200 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 201 Requirement Level", BCP 14, RFC 2119, March 1997. 203 [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., 204 "Internet Key Exchange (IKEv2) Protocol", 205 RFC 5996, September 2010. 207 8.2 Informative References 209 [FIPS188] National Institute of Standards and Technology, 210 "Standard Security Label for Information Transfer", 211 Federal Information Processing Standard (FIPS) 212 Publication 188, September 1994, 213 http://www.itl.nist.gov/fipspubs/fip188.htm 215 [RFC5570] StJohns, M., Atkinson, R., Thomas, G., "Common 216 Architecture Label IPv6 Security Option (CALIPSO)", 217 RFC 5570, July 2009. 219 Authors' Addresses 221 Joy Latten 222 email: latten@austin.ibm.com 224 David Quigley 225 email: dpquigl@tycho.nsa.gov 227 Jarrett Lu 228 email: Jarrett.Lu@oracle.com