draft-ietf-nfsv4-lfs-registry-06.txt   rfc7569.txt 
NFSv4 D. Quigley Internet Engineering Task Force (IETF) D. Quigley
Internet-Draft Request for Comments: 7569
Intended status: Standards Track J. Lu Category: Standards Track J. Lu
Expires: October 22, 2015 Oracle ISSN: 2070-1721 Oracle
T. Haynes T. Haynes
Primary Data Primary Data
April 20, 2015 July 2015
Registry Specification for Mandatory Access Control (MAC) Security Label Registry Specification for Mandatory Access Control (MAC)
Formats Security Label Formats
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 that were implemented in particular protocols and
platforms. As MAC systems became more widely deployed, additional platforms. As MAC systems become 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 such
technologies such as type enforcement. Due to the wide range of technologies as type enforcement. Due to the wide range of policies
policies and mechanisms which need to be accommodated, it is unlikely and mechanisms that need to be accommodated, it is unlikely that the
that use of a single security label format and model will be viable. 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 creates a registry of label format network, this document creates a registry of label format
specifications. This registry contains label format identifiers and specifications. This registry contains label format identifiers and
provides 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 outlining the exact syntax and use
and use of the particular label format. of the particular label format.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
This Internet-Draft will expire on October 22, 2015. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc7569.
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 ....................................................3
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Definitions .....................................................4
3. Exisiting Label Format Specifications . . . . . . . . . . . . 4 3. Existing 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) ......................5
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 .........................7
5.3. Obsoleting a Label Format Specifier . . . . . . . . . . . 7 5.3. Obsoleting a Label Format Specifier ........................8
5.4. Modifying an Existing Entry in the Registry . . . . . . . 8 5.4. Modifying an Existing Entry in the Registry ................8
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 6. References ......................................................9
6.1. Normative References . . . . . . . . . . . . . . . . . . 8 6.1. Normative References .......................................9
6.2. Informative References . . . . . . . . . . . . . . . . . 8 6.2. Informative References .....................................9
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 9 Acknowledgments ...................................................10
Appendix B. RFC Editor Notes . . . . . . . . . . . . . . . . . . 9 Authors' Addresses ................................................10
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 unsuccessful. This is because systems
systems implement different Mandatory Access Control (MAC) models, implement different Mandatory Access Control (MAC) models, which
which typically do not share any common ground. typically do not share any common ground.
One solution might be to define a single label format which consists One solution might be to define a single label format that consists
of the union of the requirements of all MAC models/implementations, of the union of the requirements of all MAC models/implementations,
known at a given time. This approach is not desirable because it known at a given time. This approach is not desirable, because it
introduces an environment where many MAC models would either have introduces an environment where either (1) many MAC models would
blank fields for many of the label's components or where many have blank fields for many of the label's components or (2) many
implementations would ignore many of values that are present implementations would ignore altogether many of the values that are
altogether. The resulting complexity would be likely to result in a present. The resulting complexity would be likely to result in a
confusing situation in which the interaction of fields that that confusing situation in which the interaction of fields that are
derive from different MAC models is never clearly specified and the derived from different MAC models is never clearly specified and the
addition of new models or extension of existing models is unduly addition of new models or extensions of existing models is unduly
difficult. difficult.
An additional consideration is that if a policy authority or An additional consideration is that if a policy authority or
identifier field is specified in the label format it would require a identifier field is specified in the label format, it would require
robust description that encompassed multiple MAC models where a robust description that would encompass multiple MAC models where
implementation would lock policy administration into the described an implementation would lock policy administration into the
model. described model.
Ideally a mechanism to address this problem should allow the most Ideally, a mechanism to address this problem should allow the most
flexibility possible in terms of policy administration while flexibility possible in terms of policy administration while
providing a specification that is suffient to allow for providing a specification that is sufficient to allow for
implementation of the label format and understanding of the semantics implementation of the label format and understanding of the
of the label. This means that the label format specification would semantics of the label. This means that the label format
ideally contain a syntactic description of the label format and a specification would ideally contain a syntactic description of the
description of the semantics for each component in the label. This label format and a description of the semantics for each component
allows protocols to specify the type of label and label semantics in the label. This allows protocols to specify the type of label
that it requires while leaving policy and policy administration to and label semantics that it requires while leaving policy and policy
the individual organizations using the protocol in their environment. administration to the individual organizations using the protocol in
their environment.
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 a 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 This document creates a registry of label format specifications to
allow multiple MAC mechanisms and label formats to co-exist in a allow multiple MAC mechanisms and label formats to co-exist in a
network. While the initial use of this registry is for the Network network. While the initial use of this registry is for the Network
File System (NFS) protocol, it might also be referenced and used by File System (NFS) protocol, it might also be referenced and used by
other IETF protocols in future. other IETF protocols in the 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: a reference to a stable, public document
document that specifies the label format. 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
given a security level (Unclassified, Secret, Top Secret, etc.) given a security level (Unclassified, Secret, Top Secret, etc.)
and objects are given security labels that mandate the access of and objects are given security labels that mandate the access of
the subject to the object (see [BL73] and [RFC2401]). the subject to the object (see [BL73] and [RFC2401]).
(Although RFC 2401 has been obsoleted by RFC 4301, RFC 2401 is
still the definitive reference for MLS as discussed in this
document.)
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. Exisiting Label Format Specifications 3. Existing Label Format Specifications
3.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".
3.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 [CIPSO] is long
Draft is long expired, it is widely supported in deployed MLS systems expired, it is widely supported in deployed MLS systems that support
that support IPv4. IANA has assigned IPv4 option number 134 to IPv4. IANA has assigned IPv4 option number 134 to CIPSO. CIPSO is
CIPSO. CIPSO is defined ONLY as an IPv4 option. IANA has never defined ONLY as an IPv4 option. IANA has never assigned any IPv6
assigned any IPv6 option value to CIPSO. option value to CIPSO.
3.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 "Son of IPSO" (SIPSO); therefore, CALIPSO is NOT derived from
derived from CIPSO in any way. CIPSO in any way.
3.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 implementation 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 and describes:
1. describe the interactions between a subsystem which enforces 1. the interactions between a subsystem that enforces security
security policy decisions and a subsystem which makes those policy decisions and a subsystem that 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 the Label Format This document defines a mechanism to associate the Label Format
Specifier identifier with a document outlining the syntax and format Specifier identifier with a document outlining the syntax and format
of a label. There is no security consideration in such an of a label. There are no security considerations for such an
association. The label specification documents referenced by each association. The label specification documents referenced by each
registration entry should state security considerations for the label registration entry should state security considerations for the label
mechanism it specifies. 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 the creation of a new registry in
with [RFC5226]. accordance with [RFC5226].
This submission requests the creation of a new registry called Per this document, IANA has created a new registry called "Security
"Security Label Format Selection Registry". The new registry has the Label Format Selection Registry". The new registry has the following
following fields: fields:
Label Format Specifier: An integer number that maps to a particular Label Format Specifier: An integer that maps to a particular label
label format, e.g., the CALIPSO label format defined by [RFC5570]. format, e.g., the CALIPSO label format defined by [RFC5570]. The
The name space of this identifier has the range of 0..65,535. namespace of this identifier has the range of 0..65535.
Label Description: A human readable ASCII ([RFC20]) text string that Label Description: A human-readable ASCII [RFC20] text string that
describes the label format, e.g., "Common Architecture Label IPv6 describes the label format, e.g., "Common Architecture Label IPv6
Security Option (CALIPSO)". The length of this field is limited Security Option (CALIPSO)". The length of this field is limited
to 128 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 where 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., a URL to [RFC5570].
5.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 | - | - |
| 256 | CIPSO (tag type #1) | active | [[FIPS-188] URL] | | 256 | CIPSO (tag type #1) | active | [FIPS-188] |
| 257 | CALIPSO ([RFC5570]) | active | [[RFC5570] URL] | | 257 | CALIPSO [RFC5570] | active | [RFC5570] |
| 258 | FLASK Security | active | [[FLASK99] URL] | | 258 | FLASK Security | active | [FLASK99] |
| | Context | | | | | Context | | |
| 259 | IPSO | active | [[RFC1108] URL] | | 259 | IPSO | active | [RFC1108] |
| 260 - 65535 | Available 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 the "Security Label Format Selection Registry". If the label to the "Security Label Format Selection Registry". If the label
format document is inside the RFC path, then The IANA Consideration format document is inside the RFC path, then the IANA Considerations
section of the label format document should clearly reference the section of the label format document should clearly reference the
Label Format Selection registry and request allocation of a new "Security Label Format Selection Registry" and request allocation of
entry. The well-known IANA policy, Specification Required, as a new entry. The well-known IANA policy Specification Required, as
defined in section 4.1 of [RFC5226], will be used to handle such defined in Section 4.1 of [RFC5226], will be used to handle such
requests. Note that "Specification Required" policy implies this requests. Note that the "Specification Required" policy implies that
process requires a Designated Expert reviewer, i.e., adding a new this process requires a Designated Expert, i.e., adding a new entry
entry to this registry requires both a published label format to this registry requires both a published label format specification
specification and a Designated Expert review. 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 reviewer must determine if the
label format specification has clearly defined syntax and semantics new label format specification has clearly defined syntax and
for the proposed new labels. semantics for the proposed new labels.
5.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 where 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 Considerations section of the updated label format specification
should be explicit in which old label selector assignment it should be explicit regarding which old label selector assignment it
obsoletes. Below is an example of obsoleted entry in the registry: obsoletes. Below is an example of an 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 | [[FIPS-188] URL] | | 256 | CIPSO (tag type | active | [FIPS-188] |
| | #1) | | | | | #1) | | |
| 257 | CALIPSO | active | [[RFC5570] URL] | | 257 | CALIPSO [RFC5570] | active | [RFC5570] |
| | ([RFC5570]) | | | | 258 | FLASK Security | obsoleted | [FLASK99] |
| 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 | Available 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
format specification will also require the Specification Required format specification will also require the Specification Required
IANA policy to be applied. The Designated Expert reviewer will need IANA policy to be applied. The Designated Expert reviewer will need
to determine if the published label format specification either to determine if the published label format specification either
obsoletes the Label Format Specifier or updates the label syntax and/ obsoletes the Label Format Specifier or updates the label syntax and/
or model. If the Label Format Specifier is obsoleted, then the or model. If the Label Format Specifier is obsoleted, then the
reviewer will follow the process defined in Section 5.3. Otherwise reviewer will follow the process defined in Section 5.3. Otherwise,
for the update of either the label syntax and/or the model, the for the update of the label syntax and/or the model, the reviewer
reviewer will approve the change. will 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, [RFC20] Cerf, V., "ASCII format for network interchange", STD 80,
October 1969. RFC 20, DOI 10.17487/RFC0020, October 1969,
<http://www.rfc-editor.org/info/rfc20>.
[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. DOI 10.17487/RFC5226, May 2008,
<http://www.rfc-editor.org/info/rfc5226>.
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)", Work in Progress,
July 1992. draft-ietf-cipso-ipsecurity-01, 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 Standards (FIPS) 188,
September 1994, <http://csrc.nist.gov/publications/fips/ September 1994, <http://csrc.nist.gov/publications/
fips188/fips188.pdf>. 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
Symposium, pages 123-139, August 1999. Security Symposium, pages 123-139, August 1999,
<https://www.cs.cmu.edu/~dga/papers/
flask-usenixsec99.pdf>.
[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
00-0930896A001 Rev B, 17 Feb 1999, Secure Computing 00-0930896A001 Rev B, 17 Feb 1999, Secure Computing
Corporation, Roseville, MN, USA, February 1999. Corporation, Roseville, MN, USA, February 1999,
<http://www.cs.utah.edu/flux/fluke/html/fspm.ps.gz>.
[RFC1108] Kent, S., "Security Options for the Internet Protocol", [RFC1108] Kent, S., "U.S. Department of Defense Security Options for
RFC 1108, November 1991. the Internet Protocol", RFC 1108, DOI 10.17487/RFC1108,
November 1991, <http://www.rfc-editor.org/info/rfc1108>.
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998. Internet Protocol", RFC 2401, DOI 10.17487/RFC2401,
November 1998, <http://www.rfc-editor.org/info/rfc2401>.
[RFC5570] StJohns, M., Atkinson, R., and G. Thomas, "Common [RFC5570] StJohns, M., Atkinson, R., and G. Thomas, "Common
Architecture Label IPv6 Security Option (CALIPSO)", RFC Architecture Label IPv6 Security Option (CALIPSO)", RFC
5570, July 2009. 5570, DOI 10.17487/RFC5570, July 2009,
<http://www.rfc-editor.org/info/rfc5570>.
[RFC7204] Haynes, T., "Requirements for Labeled NFS", RFC 7204, [RFC7204] Haynes, T., "Requirements for Labeled NFS", RFC 7204, DOI
April 2014. 10.17487/RFC7204, April 2014,
<http://www.rfc-editor.org/info/rfc7204>.
Appendix A. Acknowledgments 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 Alexey Melnikov caught that a process was needed for modifying
entries in the registry. entries in the registry.
Appendix B. RFC Editor Notes
[RFC Editor: please remove this section prior to publishing this
document as an RFC]
Authors' Addresses Authors' Addresses
David P. Quigley David P. Quigley
Email: dpquigl@davequigley.com Email: dpquigl@davequigley.com
Jarrett Lu Jarrett Lu
Oracle Oracle
Email: jarrett.lu@oracle.com Email: jarrett.lu@oracle.com
skipping to change at page 10, line 4 skipping to change at page 10, line 37
Authors' Addresses Authors' Addresses
David P. Quigley David P. Quigley
Email: dpquigl@davequigley.com Email: dpquigl@davequigley.com
Jarrett Lu Jarrett Lu
Oracle Oracle
Email: jarrett.lu@oracle.com Email: jarrett.lu@oracle.com
Thomas Haynes Thomas Haynes
Primary Data, Inc. Primary Data, Inc.
4300 El Camino Real Ste 100 4300 El Camino Real Ste 100
Los Altos, CA 94022 Los Altos, CA 94022
USA United States
Phone: +1 408 215 1519 Phone: +1 408 215 1519
Email: thomas.haynes@primarydata.com Email: thomas.haynes@primarydata.com
 End of changes. 56 change blocks. 
180 lines changed or deleted 182 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/