NFSv4
Internet Engineering Task Force (IETF)                        D. Quigley
Internet-Draft
Intended status:
Request for Comments: 7569
Category: Standards Track                                          J. Lu
Expires: October 22, 2015
ISSN: 2070-1721                                                   Oracle
                                                               T. Haynes
                                                            Primary Data
                                                          April 20,
                                                               June 2015

       Registry Specification for Mandatory Access Control (MAC)
                         Security Label Formats
                  draft-ietf-nfsv4-lfs-registry-06.txt

Abstract

   In the past past, Mandatory Access Control (MAC) systems have used very
   rigid policies which that were implemented in particular protocols and
   platforms.  As MAC systems became 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
   technologies such
   technologies as type enforcement.  Due to the wide range of policies
   and mechanisms which 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 document outlining the exact syntax and use
   of the particular label format.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents an Internet Standards Track document.

   This document is a product of the Internet Engineering Task Force
   (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list  It represents the consensus of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid the IETF community.  It has
   received public review and has been approved for a maximum publication by the
   Internet Engineering Steering Group (IESG).  Further information on
   Internet Standards is available in Section 2 of six months RFC 5741.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be updated, replaced, or obsoleted by other documents obtained at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on October 22, 2015.
   http://www.rfc-editor.org/info/rfc7569.

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  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Definitions . . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  Exisiting  Existing Label Format Specifications  . . . . . . . . . . . .   4
     3.1.  IP Security Option (IPSO), Basic Security Option (BSO)  .   4
     3.2.  Commercial IP Security Option (CIPSO) . . . . . . . . . .   4
     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  . . . . . . . . . . .   6
     5.3.  Obsoleting a Label Format Specifier . . . . . . . . . . .   7
     5.4.  Modifying an Existing Entry in the Registry . . . . . . .   8
   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
     6.1.  Normative References  . . . . . . . . . . . . . . . . . .   8
     6.2.  Informative References  . . . . . . . . . . . . . . . . .   8
   Appendix A.
   Acknowledgments . . . . . . . . . . . . . . . . . .   9
   Appendix B.  RFC Editor Notes . . . . . . . . . . . . . . . . . .   9  10
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   9  10

1.  Introduction

   With the acceptance of security labels in several mainstream
   operating systems systems, the need to communicate labels between these
   systems becomes more important.  In a typical client and server client-and-server
   scenario, the client request to the server acts as a subject trying
   to access an object on the server [RFC7204].  Unfortunately  Unfortunately, these
   systems are diverse enough that attempts at establishing one common
   label format have been unsucessful.  The reason for this unsuccessful.  This is that 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 which that consists
   of the union of the requirements of all MAC models/implementations,
   known at a given time.  This approach is not desirable desirable, because it
   introduces an environment where either (1) many MAC models would either have
   blank fields for many of the label's components or where (2) many
   implementations would ignore altogether many of the values that are present
   altogether.
   present.  The resulting complexity would be likely to result in a
   confusing situation in which the interaction of fields that that
   derive are
   derived from different MAC models is never clearly specified and the
   addition of new models or extension 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 format, it would require a
   robust description that encompassed would encompass multiple MAC models where an
   implementation would lock policy administration into the described
   model.

   Ideally

   Ideally, a mechanism to address this problem should allow the most
   flexibility possible in terms of policy administration while
   providing a specification that is suffient 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 an a label format specification to
   specify a scheme for policy administration without forcing it on all
   users of security labels.  However  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 presents 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:  is  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.  Exisiting  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.

   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 the cited Internet-
   Draft [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] [RFC5570], CALIPSO is a direct derivative of the
   IPv4 "Simple IP Security Option (SIPSO)", therefore "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
   impelementation
   implementation of an architecture to provide flexible support for
   security policies.  Section 2.1 of [FLASK99b], [FLASK99b] summarizes the
   architecture of FLASK to: and describes:

   1.  describe  the interactions between a subsystem which that enforces security
       policy decisions and a subsystem which that makes those
       decisions 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 is are no security consideration in 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].

   This submission requests the creation of

   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 number that maps to a particular label
      format, e.g., the CALIPSO label format defined by [RFC5570].  The name space
      namespace of this identifier has the range of 0..65,535. 0..65535.

   Label Description:  A human readable human-readable ASCII ([RFC20]) [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 that 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., an 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] URL] [FIPS-188]         |
   | 257           | CALIPSO ([RFC5570]) [RFC5570]   | active | [[RFC5570] URL] [RFC5570]          |
   | 258           | FLASK Security      | active | [[FLASK99] URL] [FLASK99]          |
   |               | Context             |        |                    |
   | 259           | IPSO                | active | [[RFC1108] URL] [RFC1108]          |
   | 260 - 65535   | Available for IANA  | -      | -                  |
   |               | Assignment          |        |                    |
   +---------------+---------------------+--------+--------------------+

                       Label Format Specifier Ranges

                                  Table 1

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 the IANA Consideration Considerations
   section of the label format document should clearly reference the
   "Security Label Format Selection registry Registry" and request allocation of
   a new entry.  The well-known IANA policy, policy Specification Required, as
   defined in section 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 reviewer, 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 review reviewer must determine if the
   new label format specification has clearly defined syntax and
   semantics for the proposed new labels.

5.3.  Obsoleting a Label Format Specifier

   In the case that 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
   Consideration
   Considerations section of the updated label format specification
   should be explicit in 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] URL] [FIPS-188]        |
   |              | #1)                |           |                   |
   | 257          | CALIPSO [RFC5570]  | active    | [[RFC5570] URL]   |
   |              | ([RFC5570])        |           | [RFC5570]         |
   | 258          | FLASK Security     | obsoleted | [[FLASK99] URL] [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  Otherwise,
   for the update of either the label syntax and/or the model, the reviewer
   will approve the change.

6.  References

6.1.  Normative References

   [RFC20]    Cerf, V., "ASCII format for network interchange", STD 80,
              RFC 20, DOI 10.17487/RFC0020, October 1969. 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. 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)", draft-ietf-cipso-ipsecurity-01 (expired), 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 Standard Standards (FIPS) 188,
              September 1994, <http://csrc.nist.gov/publications/fips/
              fips188/fips188.pdf>.
              <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. 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. 1999,
              <http://www.cs.utah.edu/flux/fluke/html/fspm.ps.gz>.

   [RFC1108]  Kent, S., "Security "U.S. Department of Defense Security Options for
              the Internet Protocol", RFC 1108, DOI 10.17487/RFC1108,
              November 1991. 1991, <http://www.rfc-editor.org/info/rfc1108>.

   [RFC2401]  Kent, S. and R. Atkinson, "Security Architecture for the
              Internet Protocol", RFC 2401, DOI 10.17487/RFC2401,
              November 1998. 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. 2009,
              <http://www.rfc-editor.org/info/rfc5570>.

   [RFC7204]  Haynes, T., "Requirements for Labeled NFS", RFC 7204, DOI
              10.17487/RFC7204, April 2014.

Appendix A. 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.

Appendix B.  RFC Editor Notes

   [RFC Editor: please remove this section prior to publishing this
   document as an RFC]

Authors' Addresses

   David P. Quigley

   Email:

   EMail: dpquigl@davequigley.com

   Jarrett Lu
   Oracle

   Email:

   EMail: jarrett.lu@oracle.com

   Thomas Haynes
   Primary Data, Inc.
   4300 El Camino Real Ste 100
   Los Altos, CA  94022
   USA
   United States

   Phone: +1 408 215 1519
   Email:
   EMail: thomas.haynes@primarydata.com