draft-ietf-nfsv4-lfs-registry-02.txt		draft-ietf-nfsv4-lfs-registry-03.txt
	NFSv4 D. Quigley		NFSv4 D. Quigley
	Internet-Draft		Internet-Draft
	Intended status: Standards Track J. Lu		Intended status: Standards Track J. Lu
	Expires: August 3, 2015 Oracle		Expires: September 27, 2015 Oracle
	T. Haynes		T. Haynes
	Primary Data		Primary Data
	January 30, 2015		March 26, 2015
	Registry Specification for Mandatory Access Control (MAC) Security Label		Registry Specification for Mandatory Access Control (MAC) Security Label
	Formats		Formats
	draft-ietf-nfsv4-lfs-registry-02.txt		draft-ietf-nfsv4-lfs-registry-03.txt
	Abstract		Abstract
	In the past Mandatory Access Control (MAC) systems have used very		In the past Mandatory Access Control (MAC) systems have used very
	rigid policies which were implemented in particular protocols and		rigid policies which were implemented in particular protocols and
	platforms. As MAC systems became more widely deployed, additional		platforms. As MAC systems became more widely deployed, additional
	flexibility in mechanism and policy will be required. While		flexibility in mechanism and policy will be required. While
	traditional trusted systems implemented Multi-Level Security (MLS)		traditional trusted systems implemented Multi-Level Security (MLS)
	and integrity models, modern systems have expanded to include		and integrity models, modern systems have expanded to include
	technologies such as type enforcement. Due to the wide range of		technologies such as type enforcement. Due to the wide range of
	skipping to change at page 1, line 49		skipping to change at page 1, line 49
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	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."
	This Internet-Draft will expire on August 3, 2015.		This Internet-Draft will expire on September 27, 2015.
	Copyright Notice		Copyright Notice
	Copyright (c) 2015 IETF Trust and the persons identified as the		Copyright (c) 2015 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.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4
	3. Exisiting Label Format Specifications . . . . . . . . . . . . 4		3. Exisiting Label Format Specifications . . . . . . . . . . . . 4
	3.1. IP Security Option (IPSO), Basic Security Option (BSO) . 4		3.1. IP Security Option (IPSO), Basic Security Option (BSO) . 4
	3.2. Commercial IP Security Option (CIPSO) . . . . . . . . . . 4		3.2. Commercial IP Security Option (CIPSO) . . . . . . . . . . 4
	3.3. Common Architecture Label IPv6 Security Option (CALIPSO) 4		3.3. Common Architecture Label IPv6 Security Option (CALIPSO) 5
	3.4. Flux Advanced Security Kernel (FLASK) . . . . . . . . . . 5		3.4. Flux Advanced Security Kernel (FLASK) . . . . . . . . . . 5
	4. Security Considerations . . . . . . . . . . . . . . . . . . . 5		4. Security Considerations . . . . . . . . . . . . . . . . . . . 5
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
	5.1. Initial Registry . . . . . . . . . . . . . . . . . . . . 6		5.1. Initial Registry . . . . . . . . . . . . . . . . . . . . 6
	5.2. Adding a New Entry to the Registry . . . . . . . . . . . 6		5.2. Adding a New Entry to the Registry . . . . . . . . . . . 6
	5.3. Obsoleting a Label Format Specifier . . . . . . . . . . . 6		5.3. Obsoleting a Label Format Specifier . . . . . . . . . . . 7
	6. References . . . . . . . . . . . . . . . . . . . . . . . . . 7		5.4. Modifying an Existing Entry in the Registry . . . . . . . 7
	6.1. Normative References . . . . . . . . . . . . . . . . . . 7		6. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
	6.2. Informative References . . . . . . . . . . . . . . . . . 7		6.1. Normative References . . . . . . . . . . . . . . . . . . 8
	Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 8		6.2. Informative References . . . . . . . . . . . . . . . . . 8
	Appendix B. RFC Editor Notes . . . . . . . . . . . . . . . . . . 8		Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 9
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8		Appendix B. RFC Editor Notes . . . . . . . . . . . . . . . . . . 9
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
	1. Introduction		1. Introduction
	With the acceptance of security labels in several mainstream		With the acceptance of security labels in several mainstream
	operating systems the need to communicate labels between these		operating systems the need to communicate labels between these
	systems becomes more important. In a typical client and server		systems becomes more important. In a typical client and server
	scenario, the client request to the server acts as a subject trying		scenario, the client request to the server acts as a subject trying
	to access an object on the server [RFC7204]. Unfortunately these		to access an object on the server [RFC7204]. Unfortunately these
	systems are diverse enough that attempts at establishing one common		systems are diverse enough that attempts at establishing one common
	label format have been unsucessful. The reason for this is that		label format have been unsucessful. The reason for this is that
	skipping to change at page 3, line 44		skipping to change at page 3, line 44
	Policy administration within an organization is a difficult problem.		Policy administration within an organization is a difficult problem.
	This should not be made even more difficult by having to request		This should not be made even more difficult by having to request
	permission from external entities when crafting new policy or just		permission from external entities when crafting new policy or just
	making department specific modifications to existing policies. The		making department specific modifications to existing policies. The
	policy authority field would allow an label format specification to		policy authority field would allow an label format specification to
	specify a scheme for policy administration without forcing it on all		specify a scheme for policy administration without forcing it on all
	users of security labels. However by agreeing to implement a		users of security labels. However by agreeing to implement a
	particular label format specification, the protocol agrees to that		particular label format specification, the protocol agrees to that
	policy administration mechanism when processing labels of that type.		policy administration mechanism when processing labels of that type.
			This document presents a registry of label format specifications to
			allow multiple MAC mechanisms and label formats to co-exist in a
			network. While the initial use of this registry is for the Network
			File System (NFS) protocol, it might also be referenced and used by
			other IETF protocols in future.
	2. Definitions		2. Definitions
	Label Format Specifier: an identifier used by the client to		Label Format Specifier: an identifier used by the client to
	establish the syntactic format of the security label and the		establish the syntactic format of the security label and the
	semantic meaning of its components.		semantic meaning of its components.
	Label Format Specification: is a reference to a stable, public		Label Format Specification: is a reference to a stable, public
	document that specifies the label format.		document that specifies the label format.
	Multi-Level Security (MLS): a traditional model where subjects are		Multi-Level Security (MLS): a traditional model where subjects are
	skipping to change at page 5, line 20		skipping to change at page 5, line 28
	architecture of FLASK to:		architecture of FLASK to:
	1. describe the interactions between a subsystem which enforces		1. describe the interactions between a subsystem which enforces
	security policy decisions and a subsystem which makes those		security policy decisions and a subsystem which makes those
	decisions		decisions
	2. the requirements on the components within each subsystem.		2. the requirements on the components within each subsystem.
	4. Security Considerations		4. Security Considerations
	This document defines a mechanism to associate LFS identifier with a		This document defines a mechanism to associate the Label Format
	document outlining the syntax and format of a label. There is no		Specifier identifier with a document outlining the syntax and format
	security consideration in such an association. The label		of a label. There is no security consideration in such an
	specification documents referenced by each registration entry should		association. The label specification documents referenced by each
	state security considerations for the label mechanism it specifies.		registration entry should state security considerations for the label
			mechanism it specifies.
	5. IANA Considerations		5. IANA Considerations
	This section provides guidance to the Internet Assigned Numbers		This section provides guidance to the Internet Assigned Numbers
	Authority (IANA) regarding creation of a new registry in accordance		Authority (IANA) regarding creation of a new registry in accordance
	with [RFC5226].		with [RFC5226].
	This submission requests the creation of a new registry called "NFS		This submission requests the creation of a new registry called
	Security Label Format Selection Registry". The new registry has the		"Security Label Format Selection Registry". The new registry has the
	following fields:		following fields:
	Label Format Specifier: An integer number that maps to a particular		Label Format Specifier: An integer number that maps to a particular
	label format, e.g., the CALIPSO label format defined by [RFC5570].		label format, e.g., the CALIPSO label format defined by [RFC5570].
	The name space of this identifier has the range of 0..65,535.		The name space of this identifier has the range of 0..65,535.
	Label Description: A human readable ASCII text string that describes		Label Description: A human readable ASCII ([RFC20]) text string that
	the label format, e.g., "Common Architecture Label IPv6 Security		describes the label format, e.g., "Common Architecture Label IPv6
	Option (CALIPSO)". The length of this field is limited to 128		Security Option (CALIPSO)". The length of this field is limited
	bytes.		to 128 bytes.
	Status: A short ASCII text string indicating the status of an entry		Status: A short ASCII text string indicating the status of an entry
	in the registry. The status field for most entries should have		in the registry. The status field for most entries should have
	the value "active". In the case that a label format selection		the value "active". In the case that a label format selection
	entry is obsolete, the status field of the obsoleted entry should		entry is obsolete, the status field of the obsoleted entry should
	be "obsoleted by entry NNN".		be "obsoleted by entry NNN".
	Label Format Specification: A reference to a stable, public document		Label Format Specification: A reference to a stable, public document
	that specifies the label format, e.g., an URL to [RFC5570].		that specifies the label format, e.g., an URL to [RFC5570].
	skipping to change at page 6, line 16		skipping to change at page 6, line 25
	The initial assignments of the registry are as follows:		The initial assignments of the registry are as follows:
	+---------------+---------------------+--------+--------------------+		+---------------+---------------------+--------+--------------------+
	| Label Format | Description | Status | Reference |		| Label Format | Description | Status | Reference |
	| Specifier | | | |		| Specifier | | | |
	+---------------+---------------------+--------+--------------------+		+---------------+---------------------+--------+--------------------+
	| 0 | Reserved | - | - |		| 0 | Reserved | - | - |
	| 1 - 127 | Private Use | - | - |		| 1 - 127 | Private Use | - | - |
	| 128 - 255 | Experimental Use | - | - |		| 128 - 255 | Experimental Use | - | - |
	| 256 | CIPSO (tag type #1) | active | [[CIPSO] URL] |		| 256 | CIPSO (tag type #1) | active | [[FIPS-188] URL] |
	| 257 | CALIPSO ([RFC5570]) | active | [[RFC5570] URL] |		| 257 | CALIPSO ([RFC5570]) | active | [[RFC5570] URL] |
	| 258 | FLASK Security | active | [[FLASK99] URL] |		| 258 | FLASK Security | active | [[FLASK99] URL] |
	| | Context | | |		| | Context | | |
	| 259 | IPSO | active | [[RFC1108] URL] |		| 259 | IPSO | active | [[RFC1108] URL] |
	| 260 - 65535 | Unassigned | - | - |		| 260 - 65535 | Reserved for IANA | - | - |
			| | Assignment | | |
	+---------------+---------------------+--------+--------------------+		+---------------+---------------------+--------+--------------------+
	Label Format Specifier Ranges		Label Format Specifier Ranges
	Table 1		Table 1
	5.2. Adding a New Entry to the Registry		5.2. Adding a New Entry to the Registry
	A label format specification document is required to add a new entry		A label format specification document is required to add a new entry
	to this registry. If the label format document is inside the RFC		to this registry. If the label format document is inside the RFC
	skipping to change at page 7, line 12		skipping to change at page 7, line 22
	should be explicit in which old label selector assignment it		should be explicit in which old label selector assignment it
	obsoletes. Below is an example of obsoleted entry in the registry:		obsoletes. Below is an example of obsoleted entry in the registry:
	+--------------+--------------------+-----------+-------------------+		+--------------+--------------------+-----------+-------------------+
	| Label Format | Description | Status | Reference |		| Label Format | Description | Status | Reference |
	| Specifier | | | |		| Specifier | | | |
	+--------------+--------------------+-----------+-------------------+		+--------------+--------------------+-----------+-------------------+
	| 0 | Reserved | - | - |		| 0 | Reserved | - | - |
	| 1 - 127 | Private Use | - | - |		| 1 - 127 | Private Use | - | - |
	| 128 - 255 | Experimental Use | - | - |		| 128 - 255 | Experimental Use | - | - |
	| 256 | CIPSO (tag type | active | [[CIPSO] URL] |		| 256 | CIPSO (tag type | active | [[FIPS-188] URL] |
	| | #1) | | |		| | #1) | | |
	| 257 | CALIPSO | active | [[RFC5570] URL] |		| 257 | CALIPSO | active | [[RFC5570] URL] |
	| | ([RFC5570]) | | |		| | ([RFC5570]) | | |
	| 258 | FLASK Security | obsoleted | [[FLASK99] URL] |		| 258 | FLASK Security | obsoleted | [[FLASK99] URL] |
	| | Context | by 263 | |		| | Context | by 263 | |
	| ... | | | |		| ... | | | |
	| 263 | FLASK Security | active | [new spec URL] |		| 263 | FLASK Security | active | [new spec URL] |
	| | Context (v2) | | |		| | Context (v2) | | |
	| 264 - 65535 | Unassigned | - | - |		| 264 - 65535 | Reserved for IANA | - | - |
			| | Assignment | | |
	+--------------+--------------------+-----------+-------------------+		+--------------+--------------------+-----------+-------------------+
	Example Label Format Specifier Updated Ranges		Example Label Format Specifier Updated Ranges
	Table 2		Table 2
			5.4. Modifying an Existing Entry in the Registry
			A request to modify either the Description or the published label
			format specification will also require the Specification Required
			IANA policy to be applied. The Designated Expert reviewer will need
			to determine if the published label format specification either
			obsoletes the Label Format Specifier - follow the process in
			Section 5.3
			updates the label syntax and/or model - approve the change.
	6. References		6. References
	6.1. Normative References		6.1. Normative References
			[RFC20] Cerf, V., "ASCII format for network interchange", RFC 20,
			October 1969.
	[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an		[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
	IANA Considerations Section in RFCs", BCP 26, RFC 5226,		IANA Considerations Section in RFCs", BCP 26, RFC 5226,
	May 2008.		May 2008.
	6.2. Informative References		6.2. Informative References
	[BL73] Bell, D. and L. LaPadula, "Secure Computer Systems:		[BL73] Bell, D. and L. LaPadula, "Secure Computer Systems:
	Mathematical Foundations and Model", Technical Report		Mathematical Foundations and Model", Technical Report
	M74-244, The MITRE Corporation, Bedford, MA, May 1973.		M74-244, The MITRE Corporation, Bedford, MA, May 1973.
	[CIPSO] IETF CIPSO Working Group, "Commercial IP Security Option		[CIPSO] IETF CIPSO Working Group, "Commercial IP Security Option
	(CIPSO 2.2)", draft-ietf-cipso-ipsecurity-01 (expired),		(CIPSO 2.2)", draft-ietf-cipso-ipsecurity-01 (expired),
	July 1992.		July 1992.
	[FIPS-188]		[FIPS-188]
	US National Institute of Standards and Technology,		US National Institute of Standards and Technology,
	"Standard Security Labels for Information Transfer",		"Standard Security Labels for Information Transfer",
	Federal Information Processing Standard (FIPS) 188,		Federal Information Processing Standard (FIPS) 188,
	September 1994.		September 1994, <http://csrc.nist.gov/publications/fips/
			fips188/fips188.pdf>.
	[FLASK99] Spencer, R., Smalley, S., Loscocco, P., Hibler, M.,		[FLASK99] Spencer, R., Smalley, S., Loscocco, P., Hibler, M.,
	Andersen, D., and J. Lepreau, "The Flask Security		Andersen, D., and J. Lepreau, "The Flask Security
	Architecture: System Support for Diverse Security		Architecture: System Support for Diverse Security
	Policies", In Proceedings of the Eighth USENIX Security		Policies", In Proceedings of the Eighth USENIX Security
	Symposium, pages 123-139, August 1999.		Symposium, pages 123-139, August 1999.
	[FLASK99b]		[FLASK99b]
	Secure Computing Corporation, "Assurance in the Fluke		Secure Computing Corporation, "Assurance in the Fluke
	Microkernel Formal Security Policy Model", Document		Microkernel Formal Security Policy Model", Document
	skipping to change at page 8, line 36		skipping to change at page 9, line 18
	[RFC7204] Haynes, T., "Requirements for Labeled NFS", RFC 7204,		[RFC7204] Haynes, T., "Requirements for Labeled NFS", RFC 7204,
	April 2014.		April 2014.
	Appendix A. Acknowledgments		Appendix A. Acknowledgments
	Ran Atkinson contributed the text for IPSO.		Ran Atkinson contributed the text for IPSO.
	Dave Noveck helped detangle the terminology.		Dave Noveck helped detangle the terminology.
			Alexey Melnikov caught that a process was needed for modifying
			entries in the registry.
	Appendix B. RFC Editor Notes		Appendix B. RFC Editor Notes
	[RFC Editor: please remove this section prior to publishing this		[RFC Editor: please remove this section prior to publishing this
	document as an RFC]		document as an RFC]
	Authors' Addresses		Authors' Addresses
	David P. Quigley		David P. Quigley
	Email: dpquigl@davequigley.com		Email: dpquigl@davequigley.com
End of changes. 19 change blocks.
	29 lines changed or deleted		58 lines changed or added
This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/