doc: Add RFC documents

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]
+