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/