RFC 7569

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

📅 published July 2015, from ietf

RFC 7569: Registry Specification for Mandatory Access Control (MAC) Security Label Formats 🎀

Okay so this RFC is by D. Quigley, J. Lu (Oracle), and T. Haynes (Primary Data). It came out in July 2015 as a Standards Track doc, ISSN 2070-1721. The title block doesn't list anything it obsoletes or updates, so it's standing on its own 💅

Abstract ✨

Okay, so the vibe is that Mandatory Access Control (MAC) systems used to have super rigid policies baked right into particular protocols and platforms 😤 But as MAC systems get more widely deployed, they're going to need more flexibility in both mechanism and policy. Traditional trusted systems did Multi-Level Security (MLS) and integrity models, and modern systems have expanded to stuff like type enforcement 🧚 With such a wide range of policies and mechanisms to accommodate, using a single security label format and model is unlikely to be viable, bestie.

So to let multiple MAC mechanisms and label formats co-exist in a network, this document creates a registry of label format specifications 🌈 The registry holds label format identifiers, and it links each identifier to a corresponding extensive document that spells out the exact syntax and use of that label format.

Status of This Memo 🦋

This is an Internet Standards Track document.

It's a product of the Internet Engineering Task Force (IETF) and represents the consensus of the IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). For more on Internet Standards, check Section 2 of RFC 5741.

For the current status, any errata, and how to give feedback, go to http://www.rfc-editor.org/info/rfc7569.

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) as in effect on the date of publication. Please read these carefully, because they explain your rights and restrictions for this document. Code Components pulled out of this document have to include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as described in the Simplified BSD License.

Table of Contents 🍓

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

1. Introduction 🌸

Okay, so now that security labels are showing up in several mainstream operating systems, we really need to pass labels between these systems 🙈 In a normal client-and-server setup, the client's request to the server acts as a subject trying to access an object on the server [RFC7204]. The problem is that these systems are so different that every attempt to agree on one common label format has flopped. That's because each system implements a different Mandatory Access Control (MAC) model, and those models usually don't have much in common 😭

One idea would be a single label format that's the union of what every MAC model and implementation needs at a given time. Nope, not doing that. It creates a situation where either (1) lots of MAC models end up with blank fields for many of the label's components, or (2) lots of implementations just ignore a bunch of the values that are there. The result would be super confusing, since how fields from different MAC models interact would never be clearly specified, and adding new models or extending existing ones would be unnecessarily hard 💀

There's also a problem with policy authority or identifier fields. If the label format includes one, it would need a solid description that covers multiple MAC models. Otherwise an implementation would lock policy administration into whatever model got described 🔒

Ideally, the solution gives the most flexibility possible for policy administration while still providing a spec that's enough to implement the label format and understand what the label means ✨ So the label format specification would ideally include a syntactic description of the format and a description of the semantics for each component. That lets protocols say what type of label and label semantics they need, while leaving policy and policy administration to the individual organizations using the protocol in their own environments 🫶

Policy administration within an organization is already hard enough. It shouldn't get even harder by making people ask outside entities for permission whenever they write new policy or just tweak a policy for their own department 😤 The policy authority field lets a label format specification describe a scheme for policy administration without forcing it on every user of security labels. But here's the catch: by agreeing to implement a particular label format specification, the protocol also agrees to that policy administration mechanism whenever it processes labels of that type 👀

This document creates a registry of label format specifications so multiple MAC mechanisms and label formats can co-exist in a network. The first thing to use this registry is the Network File System (NFS) protocol, but other IETF protocols might reference and use it down the line 🦋

2. Definitions 💅

  • Label Format Specifier: an identifier the client uses to establish the syntactic format of the security label and the semantic meaning of its components.
  • Label Format Specification: 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. Existing Label Format Specifications 🧚

3.1. IP Security Option (IPSO), Basic Security Option (BSO) 🌈

Okay, 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, and IPSO BSO is still widely implemented in hosts and widely deployed too 🔥 For this document, we only use the BSO labels in Table 1 on Page 3 of [RFC1108].

In some locales, the BSO value (Reserved 2) is used to mark information that local policy considers "Restricted". "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]. [CIPSO] is long expired, but it's still 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, and IANA has never assigned any IPv6 option value to it 🙅‍♀️

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], CALIPSO is a direct derivative of the IPv4 "Son of IPSO" (SIPSO). So 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 implementation of an architecture that gives flexible support for security policies 💜 Section 2.1 of [FLASK99b] summarizes the FLASK architecture and describes:

  1. the interactions between a subsystem that enforces security policy decisions and a subsystem that makes those decisions.
  2. the requirements on the components within each subsystem.

4. Security Considerations 🔥

This document defines a mechanism for associating the Label Format Specifier identifier with a document that outlines the syntax and format of a label. There are no security considerations for that association itself 🙌

Here's the real tea though: the label specification documents referenced by each registration entry should state the security considerations for the label mechanism they specify. Those are the docs to check for the actual security stuff, periodt 😤

5. IANA Considerations ✨

okay so this section is literally IANA telling everyone how to make a brand new registry 💅 it's called the "Security Label Format Selection Registry" and it's giving organized bestie energy 🎀

Each entry in the registry has these fields:

  • Label Format Specifier: an integer that points to a particular label format, like the CALIPSO label format defined by [RFC5570] 🦋 The namespace of this identifier runs from 0..65535.
  • Label Description: a human-readable ASCII [RFC20] text string describing the label format, like "Common Architecture Label IPv6 Security Option (CALIPSO)" 🌸 This field is limited to 128 bytes.
  • Status: a short ASCII text string showing the status of an entry 💜 Most entries should have the value "active". If a label format selection entry gets obsoleted, its status should be "obsoleted by entry NNN".
  • Label Format Specification: a reference to a stable, public document that specifies the label format, like a URL to [RFC5570] 🧚

5.1. Initial Registry

Here are the starting assignments, and honestly the table is so iconic 🍓

+---------------+---------------------+--------+--------------------+
| Label Format  | Description         | Status | Reference          |
| Specifier     |                     |        |                    |
+---------------+---------------------+--------+--------------------+
| 0             | Reserved            | -      | -                  |
| 1 - 127       | Private Use         | -      | -                  |
| 128 - 255     | Experimental Use    | -      | -                  |
| 256           | CIPSO (tag type #1) | active | [FIPS-188]         |
| 257           | CALIPSO [RFC5570]   | active | [RFC5570]          |
| 258           | FLASK Security      | active | [FLASK99]          |
|               | Context             |        |                    |
| 259           | IPSO                | active | [RFC1108]          |
| 260 - 65535   | Available for IANA  | -      | -                  |
|               | Assignment          |        |                    |
+---------------+---------------------+--------+--------------------+

Label Format Specifier Ranges

Table 1

5.2. Adding a New Entry to the Registry

Okay, so, to add a new entry you need a label format specification document 🎀 If the label format document is inside the RFC path, its IANA Considerations section should clearly reference the "Security Label Format Selection Registry" and request a new entry. The well-known IANA policy Specification Required, from Section 4.1 of [RFC5226], handles these requests. Note that Specification Required means there's a Designated Expert involved, so adding a new entry needs both a published label format specification and a Designated Expert review 👑

When the Designated Expert looks at the published label format specification, they should consider whether it gives enough semantics for the object and subject labels to enforce the MAC model and policy administration when deployed inside an organization 🔥 They should also check whether the label format allows a correct and complete implementation of the protocol to process and enforce labels as a policy administration mechanism 🫶 Finally, to cut down on interoperability problems, the reviewer must confirm that the new label format specification has clearly defined syntax and semantics for the proposed new labels ✨

5.3. Obsoleting a Label Format Specifier

Say a label format selector number is already assigned, and then the label format specification changes later. In that case, a new selector assignment should be requested 🦋 The same Specification Required IANA policy applies here too. The IANA Considerations section of the updated label format specification should be explicit about which old label selector assignment it obsoletes. Here's an example of an obsoleted entry in the registry, and it's so cute 🌈

+--------------+--------------------+-----------+-------------------+
| Label Format | Description        | Status    | Reference         |
| Specifier    |                    |           |                   |
+--------------+--------------------+-----------+-------------------+
| 0            | Reserved           | -         | -                 |
| 1 - 127      | Private Use        | -         | -                 |
| 128 - 255    | Experimental Use   | -         | -                 |
| 256          | CIPSO (tag type    | active    | [FIPS-188]        |
|              | #1)                |           |                   |
| 257          | CALIPSO [RFC5570]  | active    | [RFC5570]         |
| 258          | FLASK Security     | obsoleted | [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

Changing either the Description or the published label format specification also needs the Specification Required IANA policy 💖 The Designated Expert reviewer has to figure out whether the published spec either obsoletes the Label Format Specifier or just updates the label syntax and/or model. If it obsoletes the specifier, the reviewer follows the process in Section 5.3. Otherwise, for an update to the label syntax and/or the model, the reviewer approves the change 💅

6. References 📚

6.1. Normative References

6.2. Informative References

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 🎀

Authors' Addresses 🦋

David P. Quigley

Email: dpquigl@davequigley.com

Jarrett Lu Oracle

Email: jarrett.lu@oracle.com

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

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

📦 where this page comes from