summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc7569.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc7569.txt')
-rw-r--r--doc/rfc/rfc7569.txt563
1 files changed, 563 insertions, 0 deletions
diff --git a/doc/rfc/rfc7569.txt b/doc/rfc/rfc7569.txt
new file mode 100644
index 0000000..0e38df9
--- /dev/null
+++ b/doc/rfc/rfc7569.txt
@@ -0,0 +1,563 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) D. Quigley
+Request for Comments: 7569
+Category: Standards Track J. Lu
+ISSN: 2070-1721 Oracle
+ T. Haynes
+ Primary Data
+ July 2015
+
+
+ Registry Specification for Mandatory Access Control (MAC)
+ Security Label Formats
+
+Abstract
+
+ In the past, Mandatory Access Control (MAC) systems have used very
+ rigid policies that were implemented in particular protocols and
+ platforms. As MAC systems become more widely deployed, additional
+ flexibility in mechanism and policy will be required. While
+ traditional trusted systems implemented Multi-Level Security (MLS)
+ and integrity models, modern systems have expanded to include such
+ technologies as type enforcement. Due to the wide range of policies
+ and mechanisms that need to be accommodated, it is unlikely that the
+ 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
+ network, this document creates a registry of label format
+ specifications. This registry contains label format identifiers and
+ provides for the association of each such identifier with a
+ corresponding extensive document outlining the exact syntax and use
+ of the particular label format.
+
+Status of This Memo
+
+ This is an Internet Standards Track document.
+
+ This document is a product of the Internet Engineering Task Force
+ (IETF). It represents the consensus of the IETF community. It has
+ received public review and has been approved for publication by the
+ Internet Engineering Steering Group (IESG). Further information on
+ Internet Standards is available in Section 2 of RFC 5741.
+
+ 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.
+
+
+
+
+
+
+
+Quigley, et al. Standards Track [Page 1]
+
+RFC 7569 Labeled NFS Registry July 2015
+
+
+Copyright Notice
+
+ Copyright (c) 2015 IETF Trust and the persons identified as the
+ document authors. All rights reserved.
+
+ This document is subject to BCP 78 and the IETF Trust's Legal
+ Provisions Relating to IETF Documents
+ (http://trustee.ietf.org/license-info) in effect on the date of
+ publication of this document. Please review these documents
+ carefully, as they describe your rights and restrictions with respect
+ to this document. Code Components extracted from this document must
+ include Simplified BSD License text as described in Section 4.e of
+ the Trust Legal Provisions and are provided without warranty as
+ described in the Simplified BSD License.
+
+Table of Contents
+
+ 1. Introduction ....................................................3
+ 2. Definitions .....................................................4
+ 3. Existing Label Format Specifications ............................4
+ 3.1. IP Security Option (IPSO), Basic Security Option (BSO) .....4
+ 3.2. Commercial IP Security Option (CIPSO) ......................5
+ 3.3. Common Architecture Label IPv6 Security Option (CALIPSO) ...5
+ 3.4. Flux Advanced Security Kernel (FLASK) ......................5
+ 4. Security Considerations .........................................5
+ 5. IANA Considerations .............................................5
+ 5.1. Initial Registry ...........................................6
+ 5.2. Adding a New Entry to the Registry .........................7
+ 5.3. Obsoleting a Label Format Specifier ........................8
+ 5.4. Modifying an Existing Entry in the Registry ................8
+ 6. References ......................................................9
+ 6.1. Normative References .......................................9
+ 6.2. Informative References .....................................9
+ Acknowledgments ...................................................10
+ Authors' Addresses ................................................10
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Quigley, et al. Standards Track [Page 2]
+
+RFC 7569 Labeled NFS Registry July 2015
+
+
+1. Introduction
+
+ With the acceptance of security labels in several mainstream
+ operating systems, the need to communicate labels between these
+ systems becomes more important. In a typical client-and-server
+ scenario, the client request to the server acts as a subject trying
+ to access an object on the server [RFC7204]. Unfortunately, these
+ systems are diverse enough that attempts at establishing one common
+ label format have been unsuccessful. This is because systems
+ implement different Mandatory Access Control (MAC) models, which
+ typically do not share any common ground.
+
+ One solution might be to define a single label format that consists
+ of the union of the requirements of all MAC models/implementations,
+ known at a given time. This approach is not desirable, because it
+ introduces an environment where either (1) many MAC models would
+ have blank fields for many of the label's components or (2) many
+ implementations would ignore altogether many of the values that are
+ present. The resulting complexity would be likely to result in a
+ confusing situation in which the interaction of fields that are
+ derived from different MAC models is never clearly specified and the
+ addition of new models or extensions of existing models is unduly
+ difficult.
+
+ An additional consideration is that if a policy authority or
+ identifier field is specified in the label format, it would require
+ a robust description that would encompass multiple MAC models where
+ an implementation would lock policy administration into the
+ described model.
+
+ Ideally, a mechanism to address this problem should allow the most
+ flexibility possible in terms of policy administration while
+ providing a specification that is sufficient to allow for
+ implementation of the label format and understanding of the
+ semantics of the label. This means that the label format
+ specification would ideally contain a syntactic description of the
+ label format and a description of the semantics for each component
+ in the label. This allows protocols to specify the type of label
+ and label semantics that it requires while leaving policy and policy
+ administration to the individual organizations using the protocol in
+ their environment.
+
+ Policy administration within an organization is a difficult problem.
+ This should not be made even more difficult by having to request
+ permission from external entities when crafting new policy or just
+ making department specific modifications to existing policies. The
+ policy authority field would allow a label format specification to
+ specify a scheme for policy administration without forcing it on all
+
+
+
+Quigley, et al. Standards Track [Page 3]
+
+RFC 7569 Labeled NFS Registry July 2015
+
+
+ users of security labels. However, by agreeing to implement a
+ particular label format specification, the protocol agrees to that
+ policy administration mechanism when processing labels of that type.
+
+ This document creates 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 the future.
+
+2. Definitions
+
+ Label Format Specifier: an identifier used by the client to
+ establish the syntactic format of the security label and the
+ semantic meaning of its components.
+
+ Label Format Specification: a reference to a stable, public document
+ that specifies the label format.
+
+ Multi-Level Security (MLS): a traditional model where subjects are
+ given a security level (Unclassified, Secret, Top Secret, etc.)
+ and objects are given security labels that mandate the access of
+ 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
+ protect. Objects can be entities such as files, directories,
+ pipes, sockets, and many other system resources relevant to the
+ protection of the system state.
+
+ subject: an active entity, usually a process, user, or client, that
+ is requesting access to an object.
+
+3. Existing Label Format Specifications
+
+3.1. IP Security Option (IPSO), Basic Security Option (BSO)
+
+ The "IP Security Option (IPSO)" label format is defined in [RFC1108].
+ IANA has assigned IPv4 Option 130 to the IPSO Basic Security Option
+ (BSO). IPSO is the only IPv4 sensitivity label option implemented in
+ commercial IP routers. IPSO BSO continues to have widespread
+ implementation in hosts, and widespread deployment. For the purposes
+ of this document, only the BSO labels in Table 1 on Page 3 of
+ [RFC1108] are used.
+
+
+
+
+Quigley, et al. Standards Track [Page 4]
+
+RFC 7569 Labeled NFS Registry July 2015
+
+
+ In some locales, the BSO value "(Reserved 2)" is used for marking
+ information that is considered "Restricted" by local policy, where
+ "Restricted" is less sensitive than "Confidential" but more sensitive
+ than "Unclassified".
+
+3.2. Commercial IP Security Option (CIPSO)
+
+ The "Commercial IP Security Option (CIPSO)" label format is
+ documented in [CIPSO] and in [FIPS-188]. While [CIPSO] is long
+ expired, it is widely supported in deployed MLS systems that support
+ IPv4. IANA has assigned IPv4 option number 134 to CIPSO. CIPSO is
+ defined ONLY as an IPv4 option. IANA has never assigned any IPv6
+ option value to CIPSO.
+
+3.3. Common Architecture Label IPv6 Security Option (CALIPSO)
+
+ The "Common Architecture Label IPv6 Security Option (CALIPSO)" label
+ format is specified in [RFC5570] and is defined for IPv6. As noted
+ in Section 10 of [RFC5570], CALIPSO is a direct derivative of the
+ IPv4 "Son of IPSO" (SIPSO); therefore, CALIPSO is NOT derived from
+ CIPSO in any way.
+
+3.4. Flux Advanced Security Kernel (FLASK)
+
+ The Flux Advanced Security Kernel (FLASK) [FLASK99] is an
+ implementation of an architecture to provide flexible support for
+ security policies. Section 2.1 of [FLASK99b] summarizes the
+ architecture of FLASK and describes:
+
+ 1. the interactions between a subsystem that enforces security
+ policy decisions and a subsystem that makes those decisions.
+
+ 2. the requirements on the components within each subsystem.
+
+4. Security Considerations
+
+ This document defines a mechanism to associate the Label Format
+ Specifier identifier with a document outlining the syntax and format
+ of a label. There are no security considerations for such an
+ association. The label specification documents referenced by each
+ registration entry should state security considerations for the label
+ mechanism it specifies.
+
+5. IANA Considerations
+
+ This section provides guidance to the Internet Assigned Numbers
+ Authority (IANA) regarding the creation of a new registry in
+ accordance with [RFC5226].
+
+
+
+Quigley, et al. Standards Track [Page 5]
+
+RFC 7569 Labeled NFS Registry July 2015
+
+
+ Per this document, IANA has created a new registry called "Security
+ Label Format Selection Registry". The new registry has the following
+ fields:
+
+ Label Format Specifier: An integer that maps to a particular label
+ format, e.g., the CALIPSO label format defined by [RFC5570]. The
+ namespace of this identifier has the range of 0..65535.
+
+ Label Description: A human-readable ASCII [RFC20] text string that
+ describes the label format, e.g., "Common Architecture Label IPv6
+ Security Option (CALIPSO)". The length of this field is limited
+ to 128 bytes.
+
+ Status: A short ASCII text string indicating the status of an entry
+ in the registry. The status field for most entries should have
+ the value "active". In the case where a label format selection
+ entry is obsolete, the status field of the obsoleted entry should
+ be "obsoleted by entry NNN".
+
+ Label Format Specification: A reference to a stable, public document
+ that specifies the label format, e.g., a URL to [RFC5570].
+
+5.1. Initial Registry
+
+ The initial assignments of the registry are as follows:
+
+ +---------------+---------------------+--------+--------------------+
+ | Label Format | Description | Status | Reference |
+ | Specifier | | | |
+ +---------------+---------------------+--------+--------------------+
+ | 0 | Reserved | - | - |
+ | 1 - 127 | Private Use | - | - |
+ | 128 - 255 | Experimental Use | - | - |
+ | 256 | CIPSO (tag type #1) | active | [FIPS-188] |
+ | 257 | CALIPSO [RFC5570] | active | [RFC5570] |
+ | 258 | FLASK Security | active | [FLASK99] |
+ | | Context | | |
+ | 259 | IPSO | active | [RFC1108] |
+ | 260 - 65535 | Available for IANA | - | - |
+ | | Assignment | | |
+ +---------------+---------------------+--------+--------------------+
+
+ Label Format Specifier Ranges
+
+ Table 1
+
+
+
+
+
+
+Quigley, et al. Standards Track [Page 6]
+
+RFC 7569 Labeled NFS Registry July 2015
+
+
+5.2. Adding a New Entry to the Registry
+
+ A label format specification document is required to add a new entry
+ to the "Security Label Format Selection Registry". If the label
+ format document is inside the RFC path, then the IANA Considerations
+ section of the label format document should clearly reference the
+ "Security Label Format Selection Registry" and request allocation of
+ a new entry. The well-known IANA policy Specification Required, as
+ defined in Section 4.1 of [RFC5226], will be used to handle such
+ requests. Note that the "Specification Required" policy implies that
+ this process requires a Designated Expert, i.e., adding a new 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
+ Expert should consider whether or not the specification provides
+ sufficient semantics for the object and subject labels to enforce the
+ MAC model and policy administration when deployed within an
+ organization. Another consideration is if the label format allows a
+ correct and complete implementation of the protocol to process and
+ enforce labels as a policy administration mechanism. Finally, to
+ reduce interoperability issues, the reviewer must determine if the
+ new label format specification has clearly defined syntax and
+ semantics for the proposed new labels.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Quigley, et al. Standards Track [Page 7]
+
+RFC 7569 Labeled NFS Registry July 2015
+
+
+5.3. Obsoleting a Label Format Specifier
+
+ In the case where a label format selector number is assigned to a
+ label format and the label format specification is changed later, a
+ new selector assignment should be requested. The same Specification
+ Required IANA policy applies to such requests. The IANA
+ Considerations section of the updated label format specification
+ should be explicit regarding which old label selector assignment it
+ obsoletes. Below is an example of an obsoleted entry in the
+ registry:
+
+ +--------------+--------------------+-----------+-------------------+
+ | Label Format | Description | Status | Reference |
+ | Specifier | | | |
+ +--------------+--------------------+-----------+-------------------+
+ | 0 | Reserved | - | - |
+ | 1 - 127 | Private Use | - | - |
+ | 128 - 255 | Experimental Use | - | - |
+ | 256 | CIPSO (tag type | active | [FIPS-188] |
+ | | #1) | | |
+ | 257 | CALIPSO [RFC5570] | active | [RFC5570] |
+ | 258 | FLASK Security | obsoleted | [FLASK99] |
+ | | Context | by 263 | |
+ | ... | | | |
+ | 263 | FLASK Security | active | [new spec URL] |
+ | | Context (v2) | | |
+ | 264 - 65535 | Available for IANA | - | - |
+ | | Assignment | | |
+ +--------------+--------------------+-----------+-------------------+
+
+ Example Label Format Specifier Updated Ranges
+
+ 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 or updates the label syntax and/
+ or model. If the Label Format Specifier is obsoleted, then the
+ reviewer will follow the process defined in Section 5.3. Otherwise,
+ for the update of the label syntax and/or the model, the reviewer
+ will approve the change.
+
+
+
+
+
+
+Quigley, et al. Standards Track [Page 8]
+
+RFC 7569 Labeled NFS Registry July 2015
+
+
+6. References
+
+6.1. Normative References
+
+ [RFC20] Cerf, V., "ASCII format for network interchange", STD 80,
+ 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
+ IANA Considerations Section in RFCs", BCP 26, RFC 5226,
+ DOI 10.17487/RFC5226, May 2008,
+ <http://www.rfc-editor.org/info/rfc5226>.
+
+6.2. Informative References
+
+ [BL73] Bell, D. and L. LaPadula, "Secure Computer Systems:
+ Mathematical Foundations and Model", Technical Report
+ M74-244, The MITRE Corporation, Bedford, MA, May 1973.
+
+ [CIPSO] IETF CIPSO Working Group, "Commercial IP Security Option
+ (CIPSO 2.2)", Work in Progress,
+ draft-ietf-cipso-ipsecurity-01, July 1992.
+
+ [FIPS-188] US National Institute of Standards and Technology,
+ "Standard Security Labels for Information Transfer",
+ Federal Information Processing Standards (FIPS) 188,
+ September 1994, <http://csrc.nist.gov/publications/
+ fips/fips188/fips188.pdf>.
+
+ [FLASK99] Spencer, R., Smalley, S., Loscocco, P., Hibler, M.,
+ Andersen, D., and J. Lepreau, "The Flask Security
+ Architecture: System Support for Diverse Security
+ Policies", In Proceedings of the Eighth USENIX
+ Security Symposium, pages 123-139, August 1999,
+ <https://www.cs.cmu.edu/~dga/papers/
+ flask-usenixsec99.pdf>.
+
+ [FLASK99b] Secure Computing Corporation, "Assurance in the Fluke
+ Microkernel Formal Security Policy Model", Document
+ 00-0930896A001 Rev B, 17 Feb 1999, Secure Computing
+ Corporation, Roseville, MN, USA, February 1999,
+ <http://www.cs.utah.edu/flux/fluke/html/fspm.ps.gz>.
+
+ [RFC1108] Kent, S., "U.S. Department of Defense Security Options for
+ the Internet Protocol", RFC 1108, DOI 10.17487/RFC1108,
+ November 1991, <http://www.rfc-editor.org/info/rfc1108>.
+
+
+
+
+
+Quigley, et al. Standards Track [Page 9]
+
+RFC 7569 Labeled NFS Registry July 2015
+
+
+ [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the
+ 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
+ Architecture Label IPv6 Security Option (CALIPSO)", RFC
+ 5570, DOI 10.17487/RFC5570, July 2009,
+ <http://www.rfc-editor.org/info/rfc5570>.
+
+ [RFC7204] Haynes, T., "Requirements for Labeled NFS", RFC 7204, DOI
+ 10.17487/RFC7204, April 2014,
+ <http://www.rfc-editor.org/info/rfc7204>.
+
+Acknowledgments
+
+ Ran Atkinson contributed the text for IPSO.
+
+ Dave Noveck helped detangle the terminology.
+
+ Alexey Melnikov caught that a process was needed for modifying
+ entries in the registry.
+
+Authors' Addresses
+
+ David P. Quigley
+
+ Email: dpquigl@davequigley.com
+
+
+ Jarrett Lu
+ Oracle
+
+ Email: jarrett.lu@oracle.com
+
+
+ Thomas Haynes
+ Primary Data, Inc.
+ 4300 El Camino Real Ste 100
+ Los Altos, CA 94022
+ United States
+
+ Phone: +1 408 215 1519
+ Email: thomas.haynes@primarydata.com
+
+
+
+
+
+
+
+
+Quigley, et al. Standards Track [Page 10]
+