rfc-7569

Registry Specification for Mandatory Access Control (MAC) Security Label Formats

D. Quigley, J. Lu, T. Haynes

date2015-07 streamIETF areawit wgnfsv4 statusPROPOSED STANDARD pages10 canonicalhttps://www.rfc-editor.org/rfc/rfc7569 doi10.17487/RFC7569

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.

Extracted elements (16)

design-rationale §1

A single unified label format encompassing all MAC models is rejected because it would result in either many blank fields per model or widespread ignoring of values, creating unclear interactions between fields from different models and making extensions unduly difficult.

security

design-rationale §1

The registry approach allows protocols to specify the type of label and label semantics while leaving policy and policy administration to individual organizations, avoiding external permission requirements for crafting or modifying internal policies.

security

design-rationale §1

The registry is initially intended for the NFS protocol (Labeled NFS per RFC 7204) but is designed for reuse by other IETF protocols, motivating its creation as a general-purpose IANA registry rather than an NFS-specific construct.

registry, security

interoperability-note §3.3

CALIPSO (RFC 5570) is a direct derivative of the IPv4 'Son of IPSO' (SIPSO) and is explicitly NOT derived from CIPSO in any way, which is relevant for implementations that need to interoperate across IPv4/IPv6 boundaries.

security, ip, v6ops

interoperability-note §3.2

CIPSO (Commercial IP Security Option) is defined only as an IPv4 option assigned to IPv4 option number 134; IANA has never assigned any IPv6 option value to CIPSO, so it cannot be used in IPv6 environments.

security, ip, v6ops

interoperability-note §3.1

IPSO BSO value '(Reserved 2)' is used in some locales to mark information considered 'Restricted' by local policy — less sensitive than 'Confidential' but more sensitive than 'Unclassified' — representing a locally extended interpretation beyond the base RFC 1108 definition.

security, ip

normative-requirement §5.4 REQUIRED

A request to modify the Description or published label format specification of an existing registry entry also requires the Specification Required IANA policy; the Designated Expert determines whether the change obsoletes the specifier or merely updates syntax/model.

registry, security, process

normative-requirement §5.2 REQUIRED

Adding a new entry to the Security Label Format Selection Registry requires both a published label format specification document and a Designated Expert review, following the 'Specification Required' IANA policy defined in RFC 5226 Section 4.1.

registry, security, process

normative-requirement §5.2 MUST

The Designated Expert reviewing a new label format specification must consider whether the specification provides sufficient semantics for object and subject labels to enforce the MAC model, allows correct and complete protocol implementation, and has clearly defined syntax and semantics.

registry, security

normative-requirement §5.3 REQUIRED

The IANA Considerations section of an updated label format specification must explicitly identify which old label selector assignment it obsoletes, and the obsoleted entry's status field must read 'obsoleted by entry NNN'.

registry, security, process

normative-requirement §5.3 MUST

When a label format specification is changed after a selector number is assigned, a new selector assignment MUST be requested rather than reusing the old one. The Specification Required policy applies to such requests.

registry, security, process

protocol-element §3.4

The FLASK Security Context entry (value 258) is included in the initial registry, referencing the Flux Advanced Security Kernel architecture that provides flexible support for diverse security policies through a separation between policy enforcement and policy decision subsystems.

security, registry

protocol-element §5

The Label Description field in the registry is a human-readable ASCII (RFC 20) text string describing the label format; its length is limited to 128 bytes.

registry, security

protocol-element §5.1

The Label Format Specifier is an integer in the range 0..65535. Values 0 is Reserved, 1-127 are Private Use, 128-255 are Experimental Use, 256-259 are assigned to CIPSO, CALIPSO, FLASK, and IPSO respectively, and 260-65535 are available for IANA assignment.

registry, security

registry §5

RFC 7569 creates the IANA 'Security Label Format Selection Registry' with four fields: Label Format Specifier (integer 0..65535), Label Description (ASCII, max 128 bytes), Status (e.g., 'active' or 'obsoleted by entry NNN'), and Label Format Specification (reference to a stable public document).

registry, security

security-consideration §4

The association between a Label Format Specifier identifier and its specification document introduces no security considerations in itself; security considerations are delegated to the individual label specification documents referenced by each registry entry.

security