Network Working Group D. Quigley Internet-Draft Intended status: Standards Track J. Lu Expires: September 15, 2011 Oracle March 14, 2011 Registry Specification for MAC Security Label Formats draft-quigley-label-format-registry-01 Abstract In the past Mandatory Access Control(MAC) systems have used very rigid policies which were hardcoded into the particular protocol and platform. As MAC systems are more widely deployed additional flexibility in mechanism and policy is required. Where traditional trusted systems implemented Multi-Level Security and integrity models, modern systems have expanded to include technologies such as type enforcement. Due to the wide range of policies and mechanisms it has proven through past efforts to be virtually impossible to accomodate all parties in one security label format and model. To accomodate multiple MAC mechanisms and label formats this document proposes a registry of label format specifications. This registry contains several identifiers to accomodate both integer and string preferences and associates those identifiers with an extensive 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 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 September 15, 2011. Copyright Notice Quigley & Lu Expires September 15, 2011 [Page 1] Internet-Draft LSF Registry March 2011 Copyright (c) 2011 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. Requirements notation . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Security Considerations . . . . . . . . . . . . . . . . . . . . 4 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4 5. Normative References . . . . . . . . . . . . . . . . . . . . . 6 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 Quigley & Lu Expires September 15, 2011 [Page 2] Internet-Draft LSF Registry March 2011 1. Requirements notation The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 2. Introduction With the acceptance of security labels in several mainstream operating systems the need to communicate labels between these systems becomes more important. Unfortunately these systems are diverse enough that attempts at establishing one common label format have been unsucessful. The reason for this is that systems implement different MAC models some of which do not share any common ground. One solution is to define a single label format which consists of the union of the requirements of all MAC models/implementations. This is not ideal because it introduces an environment where many MAC models would either have blank fields for many of the label's components or will ignore the values that are present all together. This environment introduces waste and complexity where it isn't needed. Additionally if a policy authority or identifier field is specified in the label format it would require a robust description that could be implemented which 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 suffient to allow for implementation of the label format and understanding of the semantics of the label. This means that the label format specification (LFS) 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 LFS to specify a scheme for policy administration without forcing it on all users of security labels. However by agreeing to implement a particular LFS the protocol agrees to that policy administration mechanism when processing labels of that type. Quigley & Lu Expires September 15, 2011 [Page 3] Internet-Draft LSF Registry March 2011 3. Security Considerations This document defines a mechanism to associate label selection 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. 4. IANA Considerations This section provides guidance to the Internet Assigned Numbers Authority (IANA) regarding creation of a new registry in accordance with RFC 5226. This submission requests the creation of a new registry called "Security Label Format Selection Registry". The new registry has the following fields: o Label Format Selector: An integer number that maps to a particular label format (e.g. CALIPSO label format defined by RFC 5570). The name space of this identifier has the range of 0..65,535. o 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. o 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". o Label Format Specification: A reference to a stable, public document that specify the label format, e.g. an URL to RFC 5570. The Label Format Selector name space ranges from 0 to 65,535. The initial assignments of the registry are as follows: Quigley & Lu Expires September 15, 2011 [Page 4] Internet-Draft LSF Registry March 2011 +------------------+-------------------+--------+-------------------+ | Label Format | Description | Status | Reference | | Selector | | | | +------------------+-------------------+--------+-------------------+ | 0 | Reserved | - | - | | 1 - 127 | Private Use | - | - | | 128 - 255 | Experimental Use | - | - | | 256 | CIPSO (tag type | active | [Reference to | | | #1) | | document] | | 257 | CALIPSO (RFC | active | [RFC 5570 URL] | | | 5570) | | | | 258 | FLASK Security | active | [TBD] | | | Context | | | | 258 - 65535 | Unassigned | - | - | +------------------+-------------------+--------+-------------------+ Table 1: Label Format Specifier Ranges A label format specification document is required to add a new entry to this registry. The IANA Consideration section of the label format document should clearly reference the 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 RFC 5226, will be used to handle such requests. Note that "Specification Required" policy implies this process requires a Designated Expert reviewer, i.e. adding a new entry to this registry requires both a published label format specification and a Designated Expert review. In the case that 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 section of the updated label format specification should be explicit in which old label selector assignment it obsoletes. Below is an example of obsoleted entry in the registry: Quigley & Lu Expires September 15, 2011 [Page 5] Internet-Draft LSF Registry March 2011 +---------------+-------------------+-------------+-----------------+ | Label Format | Description | Status | Reference | | Selector | | | | +---------------+-------------------+-------------+-----------------+ | 0 | Reserved | - | - | | 1 - 127 | Private Use | - | - | | 128 - 255 | Experimental Use | - | - | | 256 | CIPSO (tag type | active | [Reference to | | | #1) | | document] | | 257 | CALIPSO (RFC | active | [RFC 5570 URL] | | | 5570) | | | | 258 | FLASK Security | obsoleted | [old spec URL] | | | Context | by 263 | | | . | | | | | . | | | | | 263 | FLASK Security | active | [new spec URL] | | | Context (v2) | | | | 264 - 65535 | Unassigned | - | - | +---------------+-------------------+-------------+-----------------+ Table 2: Label Specifier Updated Ranges 5. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Authors' Addresses David P. Quigley Email: dpquigl@davequigley.com Jarrett Lu Oracle Email: jarrett.lu@oracle.com Quigley & Lu Expires September 15, 2011 [Page 6]