--- 1/draft-ietf-nfsv4-lfs-registry-02.txt 2015-03-26 15:15:09.493815149 -0700 +++ 2/draft-ietf-nfsv4-lfs-registry-03.txt 2015-03-26 15:15:09.517815736 -0700 @@ -1,22 +1,22 @@ NFSv4 D. Quigley Internet-Draft Intended status: Standards Track J. Lu -Expires: August 3, 2015 Oracle +Expires: September 27, 2015 Oracle T. Haynes Primary Data - January 30, 2015 + March 26, 2015 Registry Specification for Mandatory Access Control (MAC) Security Label Formats - draft-ietf-nfsv4-lfs-registry-02.txt + draft-ietf-nfsv4-lfs-registry-03.txt Abstract In the past Mandatory Access Control (MAC) systems have used very rigid policies which were implemented in particular protocols and platforms. As MAC systems became 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 as type enforcement. Due to the wide range of @@ -38,57 +38,58 @@ 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 and may be updated, replaced, or obsoleted by other documents 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 August 3, 2015. + This Internet-Draft will expire on September 27, 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 - 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Exisiting 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) 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 . . . . . . . . . . . 6 - 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 - 6.1. Normative References . . . . . . . . . . . . . . . . . . 7 - 6.2. Informative References . . . . . . . . . . . . . . . . . 7 - Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 8 - Appendix B. RFC Editor Notes . . . . . . . . . . . . . . . . . . 8 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 + 5.3. Obsoleting a Label Format Specifier . . . . . . . . . . . 7 + 5.4. Modifying an Existing Entry in the Registry . . . . . . . 7 + 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 + 6.1. Normative References . . . . . . . . . . . . . . . . . . 8 + 6.2. Informative References . . . . . . . . . . . . . . . . . 8 + Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 9 + Appendix B. RFC Editor Notes . . . . . . . . . . . . . . . . . . 9 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 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 unsucessful. The reason for this is that @@ -127,20 +128,26 @@ 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 label format specification to specify a scheme for policy administration without forcing it on all 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 presents 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 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 @@ -198,44 +205,45 @@ architecture of FLASK to: 1. describe the interactions between a subsystem which enforces security policy decisions and a subsystem which makes those decisions 2. the requirements on the components within each subsystem. 4. Security Considerations - This document defines a mechanism to associate LFS identifier with a - document outlining the syntax and format of a label. There is no - security consideration in such an association. The label - specification documents referenced by each registration entry should - state security considerations for the label mechanism it specifies. + 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 no security consideration in 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 creation of a new registry in accordance with [RFC5226]. - This submission requests the creation of a new registry called "NFS - Security Label Format Selection Registry". The new registry has the + This submission requests the creation of 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 of this identifier has the range of 0..65,535. - Label Description: A human readable ASCII 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. + 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 that 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 URL to [RFC5570]. @@ -243,26 +251,27 @@ 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 | [[CIPSO] URL] | + | 256 | CIPSO (tag type #1) | active | [[FIPS-188] URL] | | 257 | CALIPSO ([RFC5570]) | active | [[RFC5570] URL] | | 258 | FLASK Security | active | [[FLASK99] URL] | | | Context | | | | 259 | IPSO | active | [[RFC1108] URL] | - | 260 - 65535 | Unassigned | - | - | + | 260 - 65535 | Reserved 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 this registry. If the label format document is inside the RFC @@ -285,59 +294,76 @@ should be explicit in which old label selector assignment it obsoletes. Below is an example of 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 | [[CIPSO] URL] | + | 256 | CIPSO (tag type | active | [[FIPS-188] URL] | | | #1) | | | | 257 | CALIPSO | active | [[RFC5570] URL] | | | ([RFC5570]) | | | | 258 | FLASK Security | obsoleted | [[FLASK99] URL] | | | Context | by 263 | | | ... | | | | | 263 | FLASK Security | active | [new spec URL] | | | Context (v2) | | | - | 264 - 65535 | Unassigned | - | - | + | 264 - 65535 | Reserved 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 - follow the process in + Section 5.3 + + updates the label syntax and/or model - approve the change. + 6. References 6.1. Normative References + [RFC20] Cerf, V., "ASCII format for network interchange", RFC 20, + October 1969. + [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. 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), July 1992. [FIPS-188] US National Institute of Standards and Technology, "Standard Security Labels for Information Transfer", Federal Information Processing Standard (FIPS) 188, - September 1994. + September 1994, . [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. [FLASK99b] Secure Computing Corporation, "Assurance in the Fluke Microkernel Formal Security Policy Model", Document @@ -356,20 +382,23 @@ [RFC7204] Haynes, T., "Requirements for Labeled NFS", RFC 7204, April 2014. Appendix A. 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: dpquigl@davequigley.com