Network Working Group J. Latten Internet-Draft G. Wilson Intended Status: Standards Track S. Hallyn Expires: January 10, 2010 IBM T. Jaeger Penn State July 10, 2009 Security Context Addendum to IPsec draft-jml-ipsec-ikev2-security-context-01 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 January 10, 2010. Copyright Notice 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 in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Latten, et al. Expires January 10, 2010 [Page 1] Internet-Draft IKEv2SecurityContext July 2010 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. 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]. The sensitvity level is hierarchical, the categories are not. This document will refer to the sensitivity 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. Operating system security concerns have expanded beyond the MLS goal of protecting the confidentiality of sensitive data using the model of government classified documents [MayMacCap]. Methods such as Type Enforcement are being used to compose rules about access using security attributes other than a sensitivity level and categories. Some MAC systems employ both MLS and Type Enforcement to control access and require additional security attributes as well as the sensitivity level and categories [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. [FIPS-188] describes free form tags that would allow additional attributes, but the data including the security context is not protected nor are the bindings Latten, et al. Expires January 10, 2010 [Page 2] Internet-Draft IKEv2SecurityContext July 2009 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. 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 transmitted 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 can provide implicit labeling by including the security context in the Security Association. Thus requiring the use of only one protocol, IPsec, to associate a label with the data, protect the label and the data, as well as protect and preserve the binding between the label and the data. 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 Latten, et al. Expires January 10, 2010 [Page 3] Internet-Draft IKEv2SecurityContext July 2010 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 on a traffic stream will require an SA pair. Thus traffic between two systems may have several SA pairs with identical selector information except for the security context. If using both 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. This document introduces an additional selector, the Security Context selector. Both the SPD and SA entries contain a security context selector and this selector is only required when labeled networking is deployed. The selector contains security context data that is determined by the MAC layer. The security context selector effectively labels the SPD and SA entries, permitting the local MAC policy to authorize use of the entries. The security context within the SPD entry also indicates that labeled networking is to be deployed on this particular traffic stream. Thus, SPD entries containing a security context MUST generate SAs that contain a security context. The security context data within the SA also provides a label for the data. [RFC4301] describes the use of selectors to determine the granularity of the SA. An SA pair will exist for each unique instance of a security context on a traffic stream. Thus for a given traffic stream, there may be multiple SAs with the same selector values except for the security context selector. Matching the data's security context determined by the MAC layer to the security context in the security context selector ensures the appropriate SA is chosen when using labeled networking. 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 Latten, et al. Expires January 10, 2010 [Page 4] Internet-Draft IKEv2SecurityContext July 2009 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. 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 Latten, et al. Expires January10, 2010 [Page 5] Internet-Draft IKEv2SecurityContext July 2009 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]. 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 MUST 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. Latten, et al. Expires January 10, 2010 [Page 6] Internet-Draft IKEv2SecurityContext July 2009 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 - 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 for the MAC implementation. - 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 data for SPD and manual SA entries. The security context data includes the security context and the security context's DOI. The DOI aids the MAC layer in interpreting the security context. For example, if two systems are running different versions of the same MAC, the DOI can indicate to each MAC how to interpret the differences. How this is done is left to the MAC implementation and not in the scope of this paper. IPsec just needs to be able to indicate the DOI. The security context DOI is entered along with the security context in the SPD entries. Thus each labeled SPD includes a DOI. Each Latten, et al. Expires January 10, 2010 [Page 7] Internet-Draft IKEv2SecurityContext July 2009 labeled SA generated from a labeled SPD entry must contain a matching DOI. In other words, the DOIs of the labeled SA and the labeled SPD entry that created it, MUST match. Therefore assuring the security contexts are understood between two systems. An SPD entry containing an invalid DOI should fail to be included into the SPD. How this failure is handled is left to the implementation. The validity of the DOI is determined by the MAC implementation. SPD entries with valid security context DOIs ensure SAs with valid DOIs. An initiating IKE communicates the security context data in the security context transform. IKE does not interpret security contexts so the responding IKE should accept the security context transform. Because two communicating systems use the same security context DOI in their SPD entries, the transform's DOI should match the responder's corresponding SPD entry's DOI. 4.2 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 the same selector values except for the security context. A responder SHOULD be willing to accept more than one SA on an IKE_SA when using labeled IPsec. 5. 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. 6. 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. Latten, et al. Expires January 10, 2010 [Page 8] Internet-Draft IKEv2SecurityContext July 2009 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. 7. 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. 8. References 8.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. 8.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 Latten, et al. Expires January 10, 2010 [Page 9] Internet-Draft IKEv2SecurityContext July 2009 [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. 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 January 10, 2010 [Page 10]