Network Working Group J. Latten Internet-Draft G. Wilson Intended Status: Standards Track S. Hallyn Expires: July 13, 2009 IBM T. Jaeger Penn State January 8, 2009 Security Context Addendum to IPsec draft-jml-ipsec-ikev2-security-context-00 Status of This Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. 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". The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on July 13, 2009. Abstract This document describes the high-level requirements needed within IPsec to support Mandatory Access Control (MAC) on network communications. It describes the extensions to the Security Architecture for the Internet Protocol [RFC4301] and the Internet Key Exchange Protocol Version 2 [RFC4306]. It also describes the negotiation of the security context for a particular Authentication Header (AH) [RFC4302] and/or Encapsulating Security Payload (ESP) [RFC4303] security association. Latten, et al. Expires July 13, 2009 [Page 1] Internet-Draft IKEv2SecurityContext January 2009 1. Introduction In computer security, Mandatory Access Control usually refers to a system in which all subjects and objects are labeled with a security context. The security context is comprised of a set of security attributes. The security contexts along with a system authorization policy determine access. Rules within the system authorization policy determine whether the access will be granted based on the security attributes of the subject and object. Traditionally, MAC implied Multilevel Security (MLS) systems. MLS utilizes a security level consisting of a sensitivity and a set of categories [MayMacCap]. This document will refer to the sensitiviy and set of categories as the MLS security level. The MLS security levels allow segregation of information thus facilitating data confidentiality. As MAC systems have become more mainstream, they are no longer just associated with MLS. Within a strictly hierarchical system such as MLS, often there are tasks that need to be exempt from the MLS policy, thus leaving them exposed. Methods such as Domain Type Enforcement (DTE) are not hierarchical and rules may be written about the access using security attributes [MayMacCap]. DTE can be used to control access to these "exempt" tasks. Thus, a MAC system can employ both MLS and DTE to control access. Such systems require additional security attributes besides the MLS security level. For example, a type attribute may be used to control access in DTE [MayMacCap]. These MAC systems concentrate on securing local objects and resources but have no way of applying their security contexts to network communications to ensure the same security. Techniques such as IP Security Options (IPSO) allow IP datagrams to be labeled with a MLS security level [RFC1108]. However, they do not accomodate additional security attributes. IPSO used in conjunction with free form tags [FIPS-188] would allow additional attributes, but the data including the security context is not protected nor are the bindings between the data and the security context. This document will describe how IPsec mechanisms can support MAC on network communications. It will also describe the additions to IKEv2 to support security contexts during negotiations to establish an AH or ESP security association. Within this document, MAC networking and labeled networking are used interchangeably and refer to applying MAC on network communications. Latten, et al. Expires July 13, 2009 [Page 2] Internet-Draft IKEv2SecurityContext January 2009 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 3. Labeled Networking Within a MAC environment, the underlying security mechanism applies a security context to all the subjects and objects on the local system. The security context along with a MAC authorization policy determines whether a subject may access an object. In labeled networking, a security context is applied to data exported over the network. The MAC policy can then use this label to make informed access decisions. IPsec mechanisms can support labeled networking whether implicit or explicit labels are being used. Explicit labeling refers to transmitting the security context in the IP datagram, such as in IPSO. When explicit labeling is used the encryption and authentication services provided in IPsec can be used to authenticate the bindings between the security context in the IP header and payload and provide confidentiality [RFC2401]. In an implicit labeling scheme, the security context is not transmitted as part of the IP datagram. IPsec provides implicit labeling in that the security context is included in the Security Association and not transmitted with each packet. 3.1 Relationship Between a Security Association and Security Context In labeled networking, the traffic between two systems may require several different security contexts. For example, ftp and telnet programs may each label their data with a different security context. Recall that SAs exist in pairs, one for inbound and one for outbound. Each instance of a security context will require an SA pair. Thus traffic between two systems may have several SA pairs with identical selectors except for the security context. If using a combination of ESP and AH for a particular traffic stream, then there will be an ESP SA pair and an AH SA pair per instance of a security context. 3.2 Security Context Selector [RFC4301] describes the Security Policy Database (SPD), and the Security Association Database (SAD) and corresponding selectors. Latten, et al. Expires July 13, 2009 [Page 3] Internet-Draft IKEv2SecurityContext January 2009 This document introduces an additional selector, the Security Context selector. This selector contains security context data and is only required when labeled networking is deployed. When a security context selector is included in an SPD entry, it labels that SPD entry permitting the local MAC policy to control access to the entry. This also allows the system administrator to specify which traffic streams are to be authorized by the system's MAC policy. Labeled SPD entries MUST generate SAs that include a security context selector. The security context within an SA entry labels the SA, allowing the MAC policy to control access to the SA. As discussed earlier in ths document, multiple SAs may exist between two systems differing only in their security contexts. The security context selector will ensure that the appropriate SA pair is selected. 3.3 Security Context Selector and PFP [RFC4301] introduced and described Populate From Packet (PFP) flags. When creating an SA, the PFP flag determines whether to instantiate the corresponding selector in the new SA with information from the packet that triggered the creation or from information in the corresponding SPD entry. Within a MAC environment, the security context associated with an SA will not be the same as the one in the SPD entry. The security contexts in the SPD entry and in the SA entry are to label two different objects respectively. The security context in the SPD entry controls access to the entry itself and it's IPsec configuration information. Thus the SPD entry itself is considered an object. The SA's security context provides security attributes for the packet which may also indicate the security attributes of the sender or process. Therefore, when using IPsec to provide implicit labels, the PFP flag MUST NOT be used to determine where to get the security context for the new SA. This could result in SPD entry and SA having the same security context. 3.4 Consistency Checking [RFC2401] described Sensitivity Consistency Checking for MLS. This description is included here and extended to include security contexts. Latten, et al. Expires July 13, 2009 [Page 4] Internet-Draft IKEv2SecurityContext January 2009 A MAC implementation MAY associate a security context with an interface, or a configured IP address with its associated prefix. If so, the MAC implementation SHOULD authorize the security context associated with the packet and the security context of the interface or address/prefix from which the packet arrived or through which the packet will depart [RFC2401]. The checking SHOULD be done on both inbound and outbound processing. 3.5 Additional Inbound Processing [RFC2401] described Additional Inbound Processing for MLS. This description is included here and extended to include security contexts. The MAC system MUST retain the binding between the data received in an IPsec protected packet and the security context in the SA used for processing, so appropriate policy decisions can be made when delivering the datagram to an application of forwarding engine. The means for maintaining this binding are implementation specific [RFC2401]. 3.5 Additional Outbound Processing [RFC2401] described Additional Outbound Processing for MLS. This description is included here and extended to include security contexts. When consulting the SAD to find an outbound security association, the data's security context MUST be used to select the appropriate outbound SA. 3.6 MAC Processing for Security Gateways [RFC2401] described Additional MLS Processing for Security Gateways. The description is included here and extended to include security contexts. A security gateway enforcing MAC MAY act as an outbound proxy, creating SAs for systems that originate packets forwarded by the gateway. These systems may explicitly label the packets, or the whole originating network may have security attributes associated with it. The security gateway MUST create and use SAs to protect such traffic it forwards [RFC2401]. Similarly, such a gateway SHOULD accept and process inbound IPsec packets and forward appropriately, using explicit packet labeling or security attributes of the destination network [RFC2401]. Latten, et al. Expires July 13, 2009 [Page 5] Internet-Draft IKEv2SecurityContext January 2009 4. Security Context Transform This document introduces a new transform type to communicate the security context when creating Child SAs during the IKE_AUTH exchange and CREATE_CHILD_SA exchange. Security contexts are only included in IPsec SAs and not IKE SAs. The transform type value is: Description Transform Type Used In ................................................. Security Context IANA ESP and AH Only one security context transform containing only one security context is required per protocol. The security context data should be the same for each protocol within each proposal for a particular SA payload. In other words, only one instance of a security context is communicated for the proposed SA. For Security Context Transform Type, the defined Transform IDs are: Name Number No Security Context 0 Security Context 1 RESERVED 2 - 65535 This transform requires a transform attribute to communicate the security context data. The Transform Attribute Type: Attribute Type Value Attribute Format ............................................................. Security context To be assigned by IANA TLV The attribute format is Type/Length/Value allowing for a variable length security context. The security context data has the following format. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | doi | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | security context (variable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: Security Context Format Latten, et al. Expires July 13, 2009 [Page 6] Internet-Draft IKEv2SecurityContext January 2009 - doi (4 octets) - the first 4 octets contains the security context's domain of interpretation. This value must be assigned by IANA. The domain of interpretation indicates the meaning of particular values within the security context. - security context (1 or more octets) - the doi is followed by one or more octets of security context data. IKE leaves interpretation of the security context to the local MAC policy. 4.1 Attribute Negotiation An implementation of IKEv2 that supports labeled SAs MUST also include a management facility that allows a user or system administrator to specify the security context's domains of interpretation accepted by the local system's MAC policy. When a responder receives a security context transform, the security context's doi within the transform is compared to the local list of accepted dois configured by the local management facility. The SA proposal MUST be considered unacceptable if local policy does not accept the transmitted security context doi. Additional SA proposals within the SA payload will have the same security context information, so the SA payload MUST be found unacceptable. 4.3 CREATE_CHILD_SA Exchange [RFC4306] describes the NO_ADDITIONAL_SAS notification. This notification is sent in response to a CREATE_CHILD_SA by a responder who is unwilling to accept additional SAs on an IKE_SA. Within labeled networking, each instance of a security context requires an SA pair. There may be multiple SAs with same selectors except for the security context selector. A responder MUST be willing to accept more than one SA on an IKE_SA when using labeled IPsec. 4. Security Considerations Security is central to IPsec and this document. Security considerations permeate throughout. It is not this document's purpose to define MAC networking but to describe the changes required to IKE and IPsec to support the use of implicit labels on data communications. The addition of the security context transform should not change the underlying security characteristics of IKE nor IPsec. Latten, et al. Expires July 13, 2009 [Page 7] Internet-Draft IKEv2SecurityContext January 2009 5. IANA Considerations This document contains several numbers requiring assignment by IANA which allocates and maintains the following IKE registries. - IKEv2 Transform Types - The Transform Type value for the security context. Description Transform type -------------------------------------------- Security Context To be assigned by IANA - IKEv2 Transform Attribute Types - The Security Context attribute type. Attribute Type Value Attribute Format ------------------------------------------------------------ Security Context To be assigned by IANA TLV - The security context's doi. This requires IANA creating a registry of doi numbers to be consumed by a Domain of Interpretation authority that will provide the mappings. A range of these numbers should be reserved for private use. 6. Acknowledgements The authors would like to thank Stephen Smalley and James Morris for their contributions during the initial design; and the members of the SELinux community who have contributed to the development and improvement of labeled ipsec and this specification. 7. References 7.1 Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Level", BCP 14, RFC 2119, March 1997. [RFC2401] Kent, S., Atkinson, R., Security Architecture for the Internet Protocol, RFC 2401, November 1998. [RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005. [RFC4306] Kaufman, Ed., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005. Latten, et al. Expires July 13, 2009 [Page 8] Internet-Draft IKEv2SecurityContext January 2009 7.2 Informative References [FIPS-188] National Institute of Standards and Technology, "Standard Security Label for Information Transfer", Federal Information Processing Standard (FIPS) Publication 188, September 1994, http://www.itl.nist.gov/fipspubs/fip188.htm [MayMacCap] Mayer, F., Macmillan K., Caplan D., SELinux by Example, Section 1.2.4, Prentice Hall, Upper Saddle River, NJ, 2007 [RFC1108] Kent, S., "U.S. DoD Security Options for the Internet Protocol", RFC 1108, November 1991. [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December 2005. [RFC4303] Kent, S. "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005. Latten, et al. Expires July 13, 2009 [Page 9] Internet-Draft IKEv2SecurityContext January 2009 Authors' Addresses Joy Latten email: latten@austin.ibm.com George Wilson email: gcwilson@us.ibm.com Serge Hallyn email: serue@us.ibm.com Trent Jaeger email: tjaeger@cse.psu.edu Latten, et al. Expires July 13, 2009 [Page 10] Internet-Draft IKEv2SecurityContext January 2009 Full Copyright Statement Copyright (c) 2009 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. Disclaimer All IETF Documents and the information contained therein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in any IETF Document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Copies of Intellectual Property disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement any standard or specification contained in an IETF Document. Please address the information to the IETF at ietf-ipr@ietf.org. The definitive version of an IETF Document is that published by, or Latten, et al. Expires July 13, 2009 [Page 11] Internet-Draft IKEv2SecurityContext January 2009 under the auspices of, the IETF. Versions of IETF Documents that are published by third parties, including those that are translated into other languages, should not be considered to be definitive versions of IETF Documents. The definitive version of these Legal Provisions is that published by, or under the auspices of, the IETF. Versions of these Legal Provisions that are published by third parties, including those that are translated into other languages, should not be considered to be definitive versions of these Legal Provisions. For the avoidance of doubt, each Contributor to the IETF Standards Process licenses each Contribution that he or she makes as part of the IETF Standards Process to the IETF Trust pursuant to the provisions of RFC 5378. No language to the contrary, or terms, conditions or rights that differ from or are inconsistent with the rights and licenses granted under RFC 5378, shall have any effect and shall be null and void, whether published or posted by such Contributor, or included with or in such Contribution. Latten, et al. Expires July 13, 2009 [Page 12]