dpquigl@davequigley.com

Oracle

jarrett.lu@oracle.com

Primary Data, Inc.

4300 El Camino Real Ste 100 Los Altos CA 94022 United States +1 408 215 1519 thomas.haynes@primarydata.com

NFSv4 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.

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

an identifier used by the client to establish the syntactic format of the security label and the semantic meaning of its components. a reference to a stable, public document that specifies the label format. 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 and ). (Although RFC 2401 has been obsoleted by RFC 4301, RFC 2401 is still the definitive reference for MLS as discussed in this document.) 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. an active entity, usually a process, user, or client, that is requesting access to an object.

The "IP Security Option (IPSO)" label format is defined in . 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 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".

The "Commercial IP Security Option (CIPSO)" label format is documented in and in . While 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.

The "Common Architecture Label IPv6 Security Option (CALIPSO)" label format is specified in and is defined for IPv6. As noted in Section 10 of , CALIPSO is a direct derivative of the IPv4 "Son of IPSO" (SIPSO); therefore, CALIPSO is NOT derived from CIPSO in any way.

The Flux Advanced Security Kernel (FLASK) is an implementation of an architecture to provide flexible support for security policies. Section 2.1 of summarizes the architecture of FLASK and describes: the interactions between a subsystem that enforces security policy decisions and a subsystem that makes those decisions. the requirements on the components within each subsystem.

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.

This section provides guidance to the Internet Assigned Numbers Authority (IANA) regarding the creation of a new registry in accordance with . Per this document, IANA has created a new registry called "Security Label Format Selection Registry". The new registry has the following fields: An integer that maps to a particular label format, e.g., the CALIPSO label format defined by . The namespace of this identifier has the range of 0..65535. 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. 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". A reference to a stable, public document that specifies the label format, e.g., a URL to .

The initial assignments of the registry are as follows: Label Format Specifier Description Status Reference 0 Reserved - - 1 - 127 Private Use - - 128 - 255 Experimental Use - - 256 CIPSO (tag type #1) active 257 CALIPSO active 258 FLASK Security Context active 259 IPSO active 260 - 65535 Available for IANA Assignment - - Label Format Specifier Ranges

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 , 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.

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 Specifier Description Status Reference 0 Reserved - - 1 - 127 Private Use - - 128 - 255 Experimental Use - - 256 CIPSO (tag type #1) active 257 CALIPSO active 258 FLASK Security Context obsoleted by 263 ... 263 FLASK Security Context (v2) active [new spec URL] 264 - 65535 Available for IANA Assignment - - Example Label Format Specifier Updated Ranges

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 . Otherwise, for the update of the label syntax and/or the model, the reviewer will approve the change.

IETF CIPSO Working Group US National Institute of Standards and Technology Secure Computing Corporation

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.