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 Domain of Interpretation (DOI) for Internet Security Association and Key Management Protocol (ISAKMP) draft-jml-ipsec-ikev1-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 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. Latten, et al. Expires July 13, 2009 [Page 1] Internet-Draft IKEv1SecurityContext January 2009 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. IPSO used in conjunction with free form tags [FIPS-188] 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", "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 Latten, et al. Expires July 13, 2009 [Page 2] Internet-Draft IKEv1SecurityContext January 2009 a security context. This document introduces the security context selector. This selector contains the security context data and is only required when MAC networking is deployed. It replaces the data sensitivity selector when a security context contains security attributes other than just a sensitivity level. 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. It 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 labeled SA entries. The security context selector for the SA effectively labels the SA entry, allowing MAC policy to control access to the SA. 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]. 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 Latten, et al. Expires July 13, 2009 [Page 3] Internet-Draft IKEv1SecurityContext 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 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's domains of interpretation accepted by the local system's MAC policy. When a responder receives the security context attribute, then this indicates that the security association is being negotiated for an environment that requires labeled SAs. The doi transmitted in the security context attribute is examined against the list of dois configured by the local management facility. The SA proposal MUST be considered unacceptable if local policy does not recognize the transmitted security context 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 Latten, et al. Expires July 13, 2009 [Page 3] Internet-Draft IKEv1SecurityContext January 2009 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. 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. Latten, et al. Expires July 13, 2009 [Page 4] Internet-Draft IKEv1SecurityContext January 2009 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 [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 5] Internet-Draft IKEv1SecurityContext 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 6] Internet-Draft IKEv1SecurityContext 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 7] Internet-Draft IKEv1SecurityContext 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 8]