draft-ietf-nfsv4-lfs-registry-05.txt		draft-ietf-nfsv4-lfs-registry-06.txt
	NFSv4 D. Quigley		NFSv4 D. Quigley
	Internet-Draft		Internet-Draft
	Intended status: Standards Track J. Lu		Intended status: Standards Track J. Lu
	Expires: October 10, 2015 Oracle		Expires: October 22, 2015 Oracle
	T. Haynes		T. Haynes
	Primary Data		Primary Data
	April 08, 2015		April 20, 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-05.txt		draft-ietf-nfsv4-lfs-registry-06.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
	policies and mechanisms which need to be accommodated, it is unlikely		policies and mechanisms which need to be accommodated, it is unlikely
	that use of a single security label format and model will be viable.		that use of a single security label format and model will be viable.
	To allow multiple MAC mechanisms and label formats to co-exist in a		To allow multiple MAC mechanisms and label formats to co-exist in a
	network, this document proposes a registry of label format		network, this document creates a registry of label format
	specifications. This registry would contain label format identifiers		specifications. This registry contains label format identifiers and
	and would provide for the association of each such identifier with a		provides for the association of each such identifier with a
	corresponding extensive document document outlining the exact syntax		corresponding extensive document document outlining the exact syntax
	and use of the particular label format.		and use of the particular label format.
	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). 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 October 10, 2015.		This Internet-Draft will expire on October 22, 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
	skipping to change at page 2, line 34		skipping to change at page 2, line 34
	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) 5		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 . . . . . . . . . . . 7		5.3. Obsoleting a Label Format Specifier . . . . . . . . . . . 7
	5.4. Modifying an Existing Entry in the Registry . . . . . . . 7		5.4. Modifying an Existing Entry in the Registry . . . . . . . 8
	6. References . . . . . . . . . . . . . . . . . . . . . . . . . 8		6. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
	6.1. Normative References . . . . . . . . . . . . . . . . . . 8		6.1. Normative References . . . . . . . . . . . . . . . . . . 8
	6.2. Informative References . . . . . . . . . . . . . . . . . 8		6.2. Informative References . . . . . . . . . . . . . . . . . 8
	Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 9		Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 9
	Appendix B. RFC Editor Notes . . . . . . . . . . . . . . . . . . 9		Appendix B. RFC Editor Notes . . . . . . . . . . . . . . . . . . 9
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 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
	skipping to change at page 6, line 30		skipping to change at page 6, line 30
	| 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 | [[FIPS-188] 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 | Reserved for IANA | - | - |		| 260 - 65535 | Available for IANA | - | - |
	| | Assignment | | |		| | 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 the "Security Label Format Selection Registry". If the label
	path, then The IANA Consideration section of the label format		format document is inside the RFC path, then The IANA Consideration
	document should clearly reference the Label Format Selection registry		section of the label format document should clearly reference the
	and request allocation of a new entry. The well-known IANA policy,		Label Format Selection registry and request allocation of a new
	Specification Required, as defined in section 4.1 of [RFC5226], will		entry. The well-known IANA policy, Specification Required, as
	be used to handle such requests. Note that "Specification Required"		defined in section 4.1 of [RFC5226], will be used to handle such
	policy implies this process requires a Designated Expert reviewer,		requests. Note that "Specification Required" policy implies this
	i.e., adding a new entry to this registry requires both a published		process requires a Designated Expert reviewer, i.e., adding a new
	label format specification and a Designated Expert review.		entry to this registry requires both a published label format
			specification and a Designated Expert review.
	In reviewing the published label format specification, the Designated		In reviewing the published label format specification, the Designated
	Expert should consider whether or not the specification provides		Expert should consider whether or not the specification provides
	sufficient semantics for the object and subject labels to enforce the		sufficient semantics for the object and subject labels to enforce the
	MAC model and policy administration when deployed within an		MAC model and policy administration when deployed within an
	organization. Another consideration is if the label format allows a		organization. Another consideration is if the label format allows a
	correct and complete implementation of the protocol to process and		correct and complete implementation of the protocol to process and
	enforce labels as a policy administration mechanism. Finally, to		enforce labels as a policy administration mechanism. Finally, to
	reduce interoperability issues, the review must determine if the new		reduce interoperability issues, the review must determine if the new
	label format specification has clearly defined syntax and semantics		label format specification has clearly defined syntax and semantics
	skipping to change at page 7, line 39		skipping to change at page 7, line 42
	| 128 - 255 | Experimental Use | - | - |		| 128 - 255 | Experimental Use | - | - |
	| 256 | CIPSO (tag type | active | [[FIPS-188] 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 | Reserved for IANA | - | - |		| 264 - 65535 | Available for IANA | - | - |
	| | Assignment | | |		| | 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		5.4. Modifying an Existing Entry in the Registry
	A request to modify either the Description or the published label		A request to modify either the Description or the published label
End of changes. 9 change blocks.
	19 lines changed or deleted		20 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/