draft-ietf-nfsv4-lfs-registry-01.txt   draft-ietf-nfsv4-lfs-registry-02.txt 
NFSv4 D. Quigley NFSv4 D. Quigley
Internet-Draft Internet-Draft
Intended status: Standards Track J. Lu Intended status: Standards Track J. Lu
Expires: March 20, 2015 Oracle Expires: August 3, 2015 Oracle
T. Haynes T. Haynes
Primary Data Primary Data
September 16, 2014 January 30, 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-01.txt draft-ietf-nfsv4-lfs-registry-02.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 March 20, 2015. This Internet-Draft will expire on August 3, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 3. Exisiting Label Format Specifications . . . . . . . . . . . . 4
4. Exisiting Label Format Specifications . . . . . . . . . . . . 4 3.1. IP Security Option (IPSO), Basic Security Option (BSO) . 4
4.1. IP Security Option (IPSO), Basic Security Option (BSO) . 4 3.2. Commercial IP Security Option (CIPSO) . . . . . . . . . . 4
4.2. Commercial IP Security Option (CIPSO) . . . . . . . . . . 4 3.3. Common Architecture Label IPv6 Security Option (CALIPSO) 4
4.3. Common Architecture Label IPv6 Security Option (CALIPSO) 5 3.4. Flux Advanced Security Kernel (FLASK) . . . . . . . . . . 5
4.4. Flux Advanced Security Kernel (FLASK) . . . . . . . . . . 5 4. Security Considerations . . . . . . . . . . . . . . . . . . . 5
5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 5.1. Initial Registry . . . . . . . . . . . . . . . . . . . . 6
6.1. Initial Registry . . . . . . . . . . . . . . . . . . . . 6 5.2. Adding a New Entry to the Registry . . . . . . . . . . . 6
6.2. Adding a New Entry to the Registry . . . . . . . . . . . 6 5.3. Obsoleting a Label Format Specifier . . . . . . . . . . . 6
6.3. Obsoleting a Label Format Specifier . . . . . . . . . . . 7 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 6.1. Normative References . . . . . . . . . . . . . . . . . . 7
7.1. Normative References . . . . . . . . . . . . . . . . . . 7 6.2. Informative References . . . . . . . . . . . . . . . . . 7
7.2. Informative References . . . . . . . . . . . . . . . . . 8
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 8 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 8
Appendix B. RFC Editor Notes . . . . . . . . . . . . . . . . . . 9 Appendix B. RFC Editor Notes . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
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 4, line 18 skipping to change at page 4, line 18
the subject to the object (see [BL73] and [RFC2401]). the subject to the object (see [BL73] and [RFC2401]).
object: a passive resource within the system that we wish to object: a passive resource within the system that we wish to
protect. Objects can be entities such as files, directories, protect. Objects can be entities such as files, directories,
pipes, sockets, and many other system resources relevant to the pipes, sockets, and many other system resources relevant to the
protection of the system state. protection of the system state.
subject: an active entity, usually a process, user, or client, that subject: an active entity, usually a process, user, or client, that
is requesting access to an object. is requesting access to an object.
3. Requirements Language 3. Exisiting Label Format Specifications
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].
4. Exisiting Label Format Specifications
4.1. IP Security Option (IPSO), Basic Security Option (BSO) 3.1. IP Security Option (IPSO), Basic Security Option (BSO)
The "IP Security Option (IPSO)" label format is defined in [RFC1108]. The "IP Security Option (IPSO)" label format is defined in [RFC1108].
IANA has assigned IPv4 Option 130 to the IPSO Basic Security Option IANA has assigned IPv4 Option 130 to the IPSO Basic Security Option
(BSO). IPSO is the only IPv4 sensitivity label option implemented in (BSO). IPSO is the only IPv4 sensitivity label option implemented in
commercial IP routers. IPSO BSO continues to have widespread commercial IP routers. IPSO BSO continues to have widespread
implementation in hosts, and widespread deployment. For the purposes implementation in hosts, and widespread deployment. For the purposes
of this document, only the BSO labels in Table 1 on Page 3 of of this document, only the BSO labels in Table 1 on Page 3 of
[RFC1108] are used. [RFC1108] are used.
In some locales, the BSO value "(Reserved 2)" is used for marking In some locales, the BSO value "(Reserved 2)" is used for marking
information that is considered "Restricted" by local policy, where information that is considered "Restricted" by local policy, where
"Restricted" is less sensitive than "Confidential" but more sensitive "Restricted" is less sensitive than "Confidential" but more sensitive
than "Unclassified". than "Unclassified".
4.2. Commercial IP Security Option (CIPSO) 3.2. Commercial IP Security Option (CIPSO)
The "Commercial IP Security Option (CIPSO)" label format is The "Commercial IP Security Option (CIPSO)" label format is
documented in [CIPSO] and in [FIPS-188]. While the cited Internet- documented in [CIPSO] and in [FIPS-188]. While the cited Internet-
Draft is long expired, it is widely supported in deployed MLS systems Draft is long expired, it is widely supported in deployed MLS systems
that support IPv4. IANA has assigned IPv4 option number 134 to that support IPv4. IANA has assigned IPv4 option number 134 to
CIPSO. CIPSO is defined ONLY as an IPv4 option. IANA has never CIPSO. CIPSO is defined ONLY as an IPv4 option. IANA has never
assigned any IPv6 option value to CIPSO. assigned any IPv6 option value to CIPSO.
4.3. Common Architecture Label IPv6 Security Option (CALIPSO) 3.3. Common Architecture Label IPv6 Security Option (CALIPSO)
The "Common Architecture Label IPv6 Security Option (CALIPSO)" label The "Common Architecture Label IPv6 Security Option (CALIPSO)" label
format is specified in [RFC5570] and is defined for IPv6. As noted format is specified in [RFC5570] and is defined for IPv6. As noted
in Section 10 of [RFC5570] CALIPSO is a direct derivative of the in Section 10 of [RFC5570] CALIPSO is a direct derivative of the
IPv4 "Simple IP Security Option (SIPSO)", therefore CALIPSO is NOT IPv4 "Simple IP Security Option (SIPSO)", therefore CALIPSO is NOT
derived from CIPSO in any way. derived from CIPSO in any way.
4.4. Flux Advanced Security Kernel (FLASK) 3.4. Flux Advanced Security Kernel (FLASK)
The Flux Advanced Security Kernel (FLASK) [FLASK99] is an The Flux Advanced Security Kernel (FLASK) [FLASK99] is an
impelementation of an architecture to provide flexible support for impelementation of an architecture to provide flexible support for
security policies. Section 2.1 of [FLASK99b], summarizes the security policies. Section 2.1 of [FLASK99b], summarizes the
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.
5. Security Considerations 4. Security Considerations
This document defines a mechanism to associate LFS identifier with a This document defines a mechanism to associate LFS identifier with a
document outlining the syntax and format of a label. There is no document outlining the syntax and format of a label. There is no
security consideration in such an association. The label security consideration in such an association. The label
specification documents referenced by each registration entry should specification documents referenced by each registration entry should
state security considerations for the label mechanism it specifies. state security considerations for the label mechanism it specifies.
6. 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 This submission requests the creation of a new registry called "NFS
"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 text string that describes
the label format, e.g., "Common Architecture Label IPv6 Security the label format, e.g., "Common Architecture Label IPv6 Security
Option (CALIPSO)". The length of this field is limited to 128 Option (CALIPSO)". The length of this field is limited to 128
bytes. 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].
6.1. Initial Registry 5.1. Initial Registry
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 | - | - |
skipping to change at page 6, line 37 skipping to change at page 6, line 28
| 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 | Unassigned | - | - |
+---------------+---------------------+--------+--------------------+ +---------------+---------------------+--------+--------------------+
Label Format Specifier Ranges Label Format Specifier Ranges
Table 1 Table 1
6.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
path, then The IANA Consideration section of the label format path, then The IANA Consideration section of the label format
document should clearly reference the Label Format Selection registry document should clearly reference the Label Format Selection registry
and request allocation of a new entry. The well-known IANA policy, and request allocation of a new entry. The well-known IANA policy,
Specification Required, as defined in section 4.1 of [RFC5226], will Specification Required, as defined in section 4.1 of [RFC5226], will
be used to handle such requests. Note that "Specification Required" be used to handle such requests. Note that "Specification Required"
policy implies this process requires a Designated Expert reviewer, policy implies this process requires a Designated Expert reviewer,
i.e., adding a new entry to this registry requires both a published i.e., adding a new entry to this registry requires both a published
label format specification and a Designated Expert review. label format specification and a Designated Expert review.
6.3. Obsoleting a Label Format Specifier 5.3. Obsoleting a Label Format Specifier
In the case that a label format selector number is assigned to a In the case that a label format selector number is assigned to a
label format and the label format specification is changed later, a label format and the label format specification is changed later, a
new selector assignment should be requested. The same Specification new selector assignment should be requested. The same Specification
Required IANA policy applies to such requests. The IANA Required IANA policy applies to such requests. The IANA
Consideration section of the updated label format specification Consideration section of the updated label format specification
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:
+--------------+--------------------+-----------+-------------------+ +--------------+--------------------+-----------+-------------------+
skipping to change at page 7, line 38 skipping to change at page 7, line 28
| ... | | | | | ... | | | |
| 263 | FLASK Security | active | [new spec URL] | | 263 | FLASK Security | active | [new spec URL] |
| | Context (v2) | | | | | Context (v2) | | |
| 264 - 65535 | Unassigned | - | - | | 264 - 65535 | Unassigned | - | - |
+--------------+--------------------+-----------+-------------------+ +--------------+--------------------+-----------+-------------------+
Example Label Format Specifier Updated Ranges Example Label Format Specifier Updated Ranges
Table 2 Table 2
7. References 6. References
7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 6.1. Normative References
Requirement Levels", March 1997.
[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.
7.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]
 End of changes. 21 change blocks. 
45 lines changed or deleted 35 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/