< draft-jml-ipsec-ikev2-security-label-00.txt		draft-jml-ipsec-ikev2-security-label-01.txt >
	Network Working Group J. Latten		Network Working Group J. Latten
	Internet-Draft IBM		Internet-Draft IBM
	Intended Status: Standards Track D. Quigley		Intended Status: Standards Track D. Quigley
	Expires: January 28, 2010 NSA		Expires: July 27, 2011 J. Lu
	J. Lu
	Oracle		Oracle
	July 27, 2010		January 28, 2011
	Security Label Extension to IKE		Security Label Extension to IKE
	draft-jml-ipsec-ikev2-security-label-00		draft-jml-ipsec-ikev2-security-label-01
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that other		Task Force (IETF), its areas, and its working groups. Note that other
	groups may also distribute working documents as Internet-Drafts.		groups may also distribute working documents as Internet-Drafts.
	skipping to change at page 1, line 34 ¶		skipping to change at page 1, line 33 ¶
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress".		material or to cite them other than as "work in progress".
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.		http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on January 28, 2010.		This Internet-Draft will expire on July 27, 2011.
	Copyright Notice		Copyright Notice
	Copyright (c) 2010 IETF Trust and the persons identified as the		Copyright (c) 2010 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Abstract		Abstract
	This document describes extensions to the Internet Key Exchange		This document describes extensions to the Internet Key Exchange
	Protocol Version 2 [RFC4306] to support Mandatory Access Control		Protocol Version 2 [RFC5996] to support Mandatory Access Control
	(MAC) security labels used on deployed systems.		(MAC) security labels used on deployed systems.
	1. Introduction		1. Introduction
	In computer security, Mandatory Access Control usually refers to		In computer security, Mandatory Access Control usually refers to
	systems in which all subjects and objects are assigned a security		systems in which all subjects and objects are assigned a security
	label. A security label is comprised of a set of security attributes.		label. A security label is comprised of a set of security attributes.
	The security labels along with a system authorization policy		The security labels along with a system authorization policy
	determine access. Rules within the system authorization policy		determine access. Rules within the system authorization policy
	determine whether the access will be granted based on the security		determine whether the access will be granted based on the security
	attributes of the subject and object.		attributes of the subject and object.
	Traditionally, security labels used by Multilevel Systems (MLS) are		Traditionally, security labels used by Multilevel Systems (MLS) are
	comprised of a sensitivity level (or classification) field and a		comprised of a sensitivity level (or classification) field and a
	compartment (or category) field, as defined in [FIPS188] and		compartment (or category) field, as defined in [FIPS188] and
	[RFC5570]. As MAC systems evolved, other MAC models gained in		[RFC5570]. As MAC systems evolved, other MAC models gained in
	popularity. For example, SELinux uses Type Enforcement MAC model,		popularity. For example, SELinux, a Flux Advanced Security Kernel
	where security labels are represented as colon-separated ASCII		(FLASK) implementation, has security labels represented as
	strings composed of values for identity, role, and type, and often		colon-separated ASCII strings composed of values for identity, role,
	referred to as security contexts. This document will refer to the		and type. The security labels are often referred to as security
	aggregation of security label representations, including MLS security		contexts.
	label and SELinux security context, as security label.
	This document will describe extensions to IKEv2 to support its		This document will describe extensions to IKEv2 to support its
	handling of security labels for implicit labeling schemes on		handling of security labels for implicit labeling schemes on
	network communications.		network communications.
	2. Terminology		2. Terminology
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in [RFC2119].		document are to be interpreted as described in [RFC2119].
	skipping to change at page 4, line 24 ¶		skipping to change at page 4, line 24 ¶
	understood and interpreted by the peer's MAC layer.		understood and interpreted by the peer's MAC layer.
	An initiating IKE communicates the LFS and the security label data		An initiating IKE communicates the LFS and the security label data
	in the security label transform of a proposal. If the responder		in the security label transform of a proposal. If the responder
	receives an LFS it does not understand, then it MUST consider the		receives an LFS it does not understand, then it MUST consider the
	proposal unacceptable. IKE does not interpret the security label		proposal unacceptable. IKE does not interpret the security label
	data itself.		data itself.
	5. Security Considerations		5. Security Considerations
	[RFC4306] describes the NO_ADDITIONAL_SAS notification.		[RFC5996] describes the NO_ADDITIONAL_SAS notification.
	It is possible that a traffic stream may require an SA for each		It is possible that a traffic stream may require an SA for each
	instance of a security label on it. Thus a responder SHOULD be		instance of a security label on it. Thus a responder SHOULD be
	willing to accept more than one SA on an IKE_SA in this case.		willing to accept more than one SA pair on an IKE_SA in this case.
	The addition of the security label transform should not change		The addition of the security label transform should not change
	the underlying security characteristics of IKE.		the underlying security characteristics of IKE.
	6. IANA Considerations		6. IANA Considerations
	This document introduces the following IANA assignments:		This document introduces the following IANA assignments:
	- IKEv2 Transform Type for the security label.		- IKEv2 Transform Type for the security label.
	skipping to change at page 5, line 17 ¶		skipping to change at page 5, line 17 ¶
	The original design of labeled IPsec was implemented in Linux		The original design of labeled IPsec was implemented in Linux
	with SELinux as it's MAC. Sun Microsystems also has a version		with SELinux as it's MAC. Sun Microsystems also has a version
	of labeled IPsec in OpenSolaris Trusted Extensions.		of labeled IPsec in OpenSolaris Trusted Extensions.
	8. References		8. References
	8.1 Normative References		8.1 Normative References
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Level", BCP 14, RFC 2119, March 1997.		Requirement Level", BCP 14, RFC 2119, March 1997.
	Internet Protocol", RFC 4301, December 2005.
	[RFC4306] Kaufman, Ed., "Internet Key Exchange (IKEv2) Protocol",		[RFC5996] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P.,
	RFC 4306, December 2005.		"Internet Key Exchange (IKEv2) Protocol",
			RFC 5996, September 2010.
	8.2 Informative References		8.2 Informative References
	[FIPS188] National Institute of Standards and Technology,		[FIPS188] National Institute of Standards and Technology,
	"Standard Security Label for Information Transfer",		"Standard Security Label for Information Transfer",
	Federal Information Processing Standard (FIPS)		Federal Information Processing Standard (FIPS)
	Publication 188, September 1994,		Publication 188, September 1994,
	http://www.itl.nist.gov/fipspubs/fip188.htm		http://www.itl.nist.gov/fipspubs/fip188.htm
	[RFC5570] StJohns, M., Atkinson, R., Thomas, G., "Common		[RFC5570] StJohns, M., Atkinson, R., Thomas, G., "Common
End of changes. 10 change blocks.
	17 lines changed or deleted		15 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/