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 Domain of Interpretation (DOI) for Internet Security Association and Key Management Protocol (ISAKMP) draft-jml-ipsec-ikev1-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 July 13, 2009. Copyright and License 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 IKEv1SecurityContext July 2009 Abstract This document describes the need for and use of a security context within IPsec. It describes the extension to the Internet IP Security Domain of Interpretation (IPsec DOI) [RFC2407] for the Internet Security Association and Key Management Protocol (ISAKMP) [RFC2408]. This extension supports the negotiation of the security context for a particular IP Authentication Header (AH) [RFC4302] or IP Encapsulating Security Payload (ESP) [RFC4303] security association. 1. Introduction Traditionally, a security context referred to the security level used by Multilevel Systems (MLS). The security level consisted of a sensitivity and a set of categories. This document will refer to the sensitivity and set of categories as the MLS security level. Current security mechanisms, such as SELinux, use the MLS security level and additional security attributes to form the security context. For example, a type attribute may be included for Domain Type Enforcement (DTE). This document will refer to the aggregation of security attributes including the MLS security level as the security context. Techniques such as IP Security Options (IPSO) allow IP datagrams to include an MLS security level [RFC1108]. This ensures that the same security applied to local objects and resources is used when communicating over the network. However, these techniques did not include the additional security attributes used in current security mechanisms. [FIPS-188] describes free form tags that would allow additional attributes, but the data including the security context isn't protected nor are the bindings between the data and the security context. The ISAKMP specification defines a Situation field in the Security Association payload [RFC2408]. The IPsec DOI describes the use of this field to communicate sensitivity and integrity classification information between initiator and responder when negotiating a security association [RFC2407]. However, it does not provide for additional security attributes that may be required by the security mechanism being deployed in the environment. This document describes the additions to the IPsec DOI for ISAKMP that are needed for IPsec to support security contexts, consisting of various security attributes, on network communications. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", Latten, et al. Expires January 10, 2010 [Page 2] Internet-Draft IKEv1SecurityContext July 2009 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 3. Security Context Selector [RFC2401] described the Security Policy Database (SPD), and the Security Association Database (SAD) and corresponding selectors. Data Sensitivity Level was one of the selectors outlined. The sensitivity level may be only one of several security attributes in a security context. This document introduces the security context selector. This selector contains security context data determined by the MAC implementation and is only required when MAC networking is deployed. It is to be used when a security context contains security attributes other than just a sensitivity and/or integrity level. 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. An SA pair exists 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. Matching the data's security context, which has been 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. IPsec Security Association Attribute The following SA attribute definition is used in Phase II of an Internet Key Exchange Protocol (IKE) negotiation that includes a security context. The attribute type is Variable-Length (V). Encoding of attributes is defined in the base ISAKMP specification [RFC2408]. IKE negotiation includes an SA payload which in turn contains a Proposal payload. The proposal may be comprised of one or more Transforms. Each transform in a proposal MUST contain the same security context data. The security context data is communicated and its values are non-negotiable. Latten, et al. Expires January 10, 2010 [Page 3] Internet-Draft IKEv1SecurityContext July 2009 Attribute Type class value type ------------------------------------------------------ Security Context ? V Class Value Security Context Indicates that the security association is being negotiated in an environment that requires labeled security. This field will contain the security context data. The security context 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. - security context (1 or more octets) - The DOI is followed by one or more octets of security context data. IKE leaves the interpretation of the security context data to the local MAC policy. 3. Attribute Negotiation If an implementation receives an IPsec DOI attribute or attribute value that it does not support, it SHOULD send an ATTRIBUTES-NOT-SUPPORT and the security association negotiation and setup MUST be aborted. An implementation of IKEv1 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 Latten, et al. Expires January 10, 2010 [Page 4] Internet-Draft IKEv1SecurityContext July 2009 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 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. Security Considerations This document describes an extension to IKE [RFC2409] and ISAKMP [RFC2408] protocols. The use of security contexts should not change the basic security features of the two. The IPsec DOI describes a Situation field whose values can be SIT_SECRECY and/or SIT_INTEGRITY. When SIT_SECRECY is used, it indicates an environment requiring labeled secrecy and is followed with sensitivity label. When SIT_INTEGITY is used, it indicates an environment requiring labeled integrity and is followed with integrity information. SIT_SECRECY and SIT_INTEGRITY themselves indicate the use of a security label. Thus, the security context selector and attribute described in this document MUST NOT be used in conjunction with either. Otherwise, it could result in assigning two possibly different security contexts to an SA or data communication and violating the local MAC policy. Latten, et al. Expires January 10, 2010 [Page 5] Internet-Draft IKEv1SecurityContext July 2009 5. IANA Considerations This document contains 2 numbers to be assigned by IANA. The IP Security Domain of Interpretation [RFC2407] defined the IPsec Security Association attributes. The security context represents a new IPsec SA attribute and requires a number from IANA. class value type ----------------------------------------- Security Context IANA V The second number is the security context's DOI. This requires IANA creating a new registry of DOI numbers that will be used to indicate the domain of interpretation for the security context in the security association. A range of these numbers should be reserved for private use. Acknowledgements The authors would like to thank Stephen Smalley, James Morris and the SELinux community for their work on labeled ipsec. 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. [RFC2407] Piper, D., "The Internet IP Security Domain of Interpretation for ISAKMP", RFC 2407, November 1998. [RFC2408] Maughan, D., Schertler, M., Schneider, M., and J. Turner, "Internet Security Association and Key Management Protocol", RFC 2408, November 1998. [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange", RFC 2409, November 1998. 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 6] Internet-Draft IKEv1SecurityContext July 2009 [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 7]