RFC 1457

Okay bestie, let's start with the title block 🎀. This is RFC 1457, called Security Label Framework for the Internet. It's from the Network Working Group, written by R. Housley of Xerox Special Information Systems, and dated May 1993 💅. It's an informational doc, so it provides information for the Internet community and doesn't specify an Internet standard ✨. The title block doesn't list anything it obsoletes or updates 🦋.

---

Status of this Memo ✨

Bestie, this memo just provides information for the Internet community 📚. It does not specify an Internet standard 🙅‍♀️. Distribution of it is unlimited 🌈.

Acknowledgements 🫶

The members of the Privacy and Security Research Group and the attendees of the invitational Security Labels Workshop (hosted by the National Institute of Standards and Technology) helped R. Housley organize their thoughts 💜. Their ideas are scattered throughout the memo ✨.

1.0 Introduction 🦋

Okay so this memo presents a security labeling framework for the Internet 💖. The framework is meant to help protocol designers figure out what, if any, security labeling should be supported by their protocols 🧠. It should also help network architects check whether a particular collection of protocols fulfills their security labeling requirements 🔥. The Open Systems Interconnection Reference Model [1] gives the structure for the presentation, so OSI protocol designers might find this memo useful too 🌸.

2.0 Security Labels 🎀

Data security is the set of measures taken to protect data from accidental, unauthorized, intentional, or malicious modification, destruction, or disclosure 🛡️. It's also the condition that results from establishing and maintaining those protective measures [2]. With that two-pronged definition in mind, this memo looks at security labeling as one mechanism that provides data security 👀. In general, security labeling by itself does not provide sufficient data security; it must be complemented by other security mechanisms 🙈.

In data communication protocols, security labels tell protocol processing how to handle the data moving between two systems 💅. So the security label says what measures need to be taken to preserve the condition of security. "Handling" means the activities done on data, like collecting, processing, transferring, storing, retrieving, sorting, transmitting, disseminating, and controlling [3] 🧚.

The definition of data security includes protection from modification and destruction. In computer systems, that means protection from writing and deleting 🍓. These protections implement the data integrity service defined in the OSI Security Architecture [4].

Biba [5] defined a data integrity model that includes security labels 💜. The Biba model specifies rule-based controls for writing and deleting that are needed to preserve data integrity. It also specifies rule-based controls for reading, so a high integrity process can't end up relying on data with less integrity than the process has 👑.

The definition of data security also includes protection from disclosure. In computer systems, that's protection from reading 🫣. This is the data confidentiality service defined in the OSI Security Architecture [4].

Bell and LaPadula [6] defined a data confidentiality model that includes security labels 🔐. The Bell and LaPadula model specifies rule-based controls for reading that are needed to preserve data confidentiality. It also specifies rule-based controls for writing, to make sure data isn't copied into a container where confidentiality can't be guaranteed 🙅‍♀️.

In both the Biba model and the Bell and LaPadula model, the security label is an attribute of the data 🏷️. In general, the label stays constant. Exceptions come later in the memo, but relabeling is always the result of some network entity handling the data ✨. Since the label is an attribute of the data, it should be bound to the data. When data moves through the network, the integrity security service [4] is generally used to do this binding 🔗. If the communications environment doesn't include a protocol that provides the integrity security service to bind the label to the data, then the environment should include other mechanisms to preserve that binding 🫶.

2.1 Integrity Labels 💖

Integrity labels are security labels that support data integrity models, like the Biba model. The integrity label tells how much confidence can be placed in the data, and also which measures the data needs for protection from modification and destruction 🛡️.

As data moves through the network, the confidence in that data may change because various network components handle it 🗺️. So the integrity label is a function of the data's integrity before it's transmitted on the network and the path it takes through the network. Confidence in data doesn't go up just because it crossed a network, but it can go down when arbitrary network components handle it 📉. Entities get integrity labels that say how much confidence can be placed in the data they handle. So when data is handled by an entity with an integrity label lower than the data's, the data is relabeled with the entity's integrity label 😬. That relabeling should be avoided by limiting the possible paths the data takes to ones where it's only handled by entities with the same or a higher integrity label than the data 🔒.

When integrity labels are used, each system on the network must implement the integrity model, and the protocol suite must transfer the integrity label with the data if the confidence in the data is going to be maintained across the network 🌐. Each system may have its own internal representation of an integrity label, but the protocols must provide common syntax and semantics for transferring the label along with the data itself 📦. To date, no protocols have been standardized that include integrity labels in the protocol control information 🙃.

2.2 Sensitivity Labels 🌸

Sensitivity labels are security labels that support data confidentiality models, like the Bell and LaPadula model. The sensitivity label tells how much damage will result from disclosing the data, and also which measures the data needs for protection from disclosure 💅. How much damage comes from unauthorized disclosure depends on who gets the data, so the sensitivity label should reflect the worst case 😱.

As data moves through the network, various components process it and may mix it with data of different sensitivity 🌀. If those components aren't trusted to segregate data of differing sensitivities, then all the data they process must be handled as the most sensitive data they processed. For example, poor buffer management may append highly sensitive data to the end of a protocol data unit that was otherwise publicly releasable 💀. So the sensitivity label is a function of the data's sensitivity before it's transmitted on the network, the most sensitive data handled by the network components, and how trustworthy those components are 🧐. The damage from disclosing the data doesn't go down just because it crossed a network, but it may go up when arbitrary network components mix it with more sensitive data 📈. So when an untrusted entity with a sensitivity label higher than the data's handles the data, the data is relabeled with the higher sensitivity label 🚨. That relabeling should be avoided by limiting the possible paths the data takes to ones where it's only handled by entities with the same sensitivity label as the data, or by using trustworthy network components 🛤️. Entities with lower sensitivity labels may not handle the data, because that would be disclosure 🙅‍♀️.

When sensitivity labels are used, each system on the network must implement the sensitivity model, and the protocol suite must transfer the sensitivity label with the data if protection from disclosure is going to be maintained throughout the network 🔒. Each system may have its own internal representation of a sensitivity label, but the protocols must provide common syntax and semantics for transferring the label along with the data itself 🎁. Sensitivity labels, like the ones provided by the IP Security Option (IPSO) [7], have been used in a few networks for years 🕰️.

3.0 Security Label Usage 🧚‍♀️

The Internet includes two major types of systems: end systems and intermediate systems [1]. These terms should be familiar to you, bestie 📖. For this discussion, the definition of intermediate system is understood to include routers, packet switches, and bridges 🌉. End systems and intermediate systems use security labels differently 💕.

3.1 End System Security Label Usage 🖥️

When two end systems communicate, common security label syntax and semantics are needed 🤝. The security label, as an attribute of the data, says what measures need to be taken to preserve the condition of security. The security label must communicate all of the integrity and confidentiality handling requirements. These requirements can get really complex 😵‍💫.

Some operating systems label the data they process. These security labels aren't part of the data; they're attributes of the data 🏷️. Some database management systems (DBMSs) do similar labeling. The format of these security labels is a local matter, but it's usually different from the format used by the data communication protocols. Security labels must be translated by these operating systems and DBMSs between the local format and the format used in the data communication protocols, without any loss of meaning 🔁.

Trusted operating systems that implement rule-based access control policies require security labels on the data they import [8,9] 🏰. These security labels let the Trusted Computing Base (TCB) in the end system do trusted demultiplexing. That means traffic is relayed from the TCB to a process only if the process has sufficient authorization for the data 🔑. In most cases, the TCB must first translate the security label into local syntax before it can make the access control decision 🧩.

3.2 Intermediate System Security Label Usage ✨

okay bestie, this section is about the "user" data security labels sitting inside the intermediate system 🦋 The labeling rules for IS-ES traffic, IS-IS traffic, and IS-NM traffic are not included in this discussion, so we're skipping those.

Intermediate systems can make routing choices or discard traffic based on the security label 🚦 The label an intermediate system uses should only hold enough info to make that routing or discard call. It may be a subset of the label the end system uses. Some parts of the label won't affect routing, but they can still affect processing inside the end system 💅

Here's the tea: very few intermediate systems on the Internet today actually make access control decisions 🙈 For performance reasons, only the ones that do should be burdened with parsing the security label. That's giving information hiding principles 🔐 Labels that only end systems parse should also stay out of sight of physical, data link, and network layer protocols, since that's where intermediate systems would have to look at them.

Intermediate systems usually don't translate labels into a local format. They use them "as is" to make routing and discard decisions ✨ But when two classification authorities share a network through a bilateral agreement, the intermediate systems may be required to do label translation. Translation should be avoided whenever possible by using a label format that every system processing the label supports 🌸 Since end systems generally don't know which intermediate systems will handle their traffic, translation can't always be avoided 😭

Here's the next bit. Labels that only end systems should parse shouldn't ride on protocols that intermediate systems interpret, so they should be carried by upper layer protocols instead 🧚 End systems that use different formats for those labels can't count on an intermediate system to translate them. Neither the Internet nor the OSI architecture has transformation functions in the transport, session, or presentation layer, which means application layer gateways should be used to translate between different end system label formats. Still, those gateways should be avoided, because they get in the way of operation, especially when otherwise compatible protocols are in use 🙅‍♀️ This is one more reason a format that every system supports is so desirable. A standard label syntax with registered label semantics goes a long way toward avoiding translation [10] 🎀

---

4.0 Approaches to Labeling 🌈

There are several tradeoffs to juggle when deciding how a particular network will do security labeling ⚖️ Explicit or implicit labels can be used. Labels can also be connectionless or connection-oriented. A combination of these options may be the move 💜

4.1 Explicit Versus Implicit Security Labels 💖

Explicit security labels are actual bits in the protocol control information (PCI) 🎯 The IP Security Option (IPSO) is an example of an explicit security label [7]. Explicit security labels may be connectionless or connection-oriented. Their syntax and semantics may be either tightly or loosely coupled. If they're tightly coupled, the explicit label format supports a single security policy. If they're loosely coupled, the format can support multiple security policies through registration 📋 In both cases, software enforces the security policy, but if the syntax and semantics are loosely coupled, the label parsing software can be written once. Fixed length explicit label parsers are generally faster than parsers for variable length formats ⚡ Intermediate systems take less of a performance hit when fixed length explicit labels can be used, but end systems often need variable length explicit labels to express their data handling requirements 🥺

Implicit security labels are not actual bits in the PCI. Instead, some attribute is used to determine the label 🔑 For example, the choice of cryptographic key in the SP4 protocol [11] can determine the security label. Implicit security labels may be connectionless or connection-oriented.

4.2 Connectionless Versus Connection-oriented Security Labels 🦋

When connectionless security labels are used, the label appears in every protocol data unit (PDU) 📦 The IP Security Option (IPSO) [7] is an example of connectionless labeling. Every protocol has limits on the size of its PCI, and the explicit label can't exceed that size limit. It also can't use the entire PCI space, because the protocol has other fields that must be transferred too 😤 This size limitation may stop explicit connectionless labels from meeting end system requirements. The good news is that intermediate system requirements are more easily satisfied by explicit connectionless labels 💅

Connection-oriented security labels are attributes of virtual circuits, connections, and associations. For simplicity, all of these are referred to as connections from here on 🫶 Connection-oriented labels are used when the SDNS Key Management Protocol (KMP) [12] is used to associate security labels with each transport connection protected by the SP4 protocol [10,11] (using SP4C). The label is defined at connection establishment, and all data transferred over that connection inherits it 🔒 This approach is more compatible with end system requirements than with intermediate system requirements. One noteworthy exception is X.25 packet switches, which could associate connection-oriented labels with each virtual circuit 🌸

Connectionless security labels may be used with connectionless or connection-oriented data transfer protocols. Connection-oriented security labels may only be used with connection-oriented data transfer protocols 🎀

---

5.0 Labeling Within the OSI Reference Model 🌍

This section looks at each of the seven OSI layers with respect to security labels 👑

5.1 Layer 1, The Physical Layer 🔌

Explicit security labels are not possible in the Physical Layer. The Physical Layer doesn't include any protocol control information (PCI), so there's no place to put the bits that represent the label 🙃

Implicit security labels are possible in the Physical Layer. For example, all of the data coming in through one particular physical port could inherit one security label 🧃 Most Physical Layer communication is connectionless, supporting only bit-at-a-time or byte-at-a-time operations, so these implicit labels are connectionless too. Implicit labels in the Physical Layer may be used to meet the requirements of either end systems or intermediate systems, as long as the communication is single level. That means only one security label is associated with all of the data received or transmitted through the physical connection 💜

5.2 Layer 2, The Data Link Layer 🌷

Explicit security labels are possible in the Data Link Layer. In fact, the IEEE 802.2 Working Group is currently working on an optional security label standard for the Logical Link Control (LLC) protocol (IEEE 802.2) [13] 🛠️ These labels will optionally appear in each LLC frame, and they're connectionless security labels.

Explicit connection-oriented security labels are also possible in the Data Link Layer. You could imagine a security label standard that worked with LLC Type II 🤔

Of course, implicit security labels are possible in the Data Link Layer too. They could be either connectionless or connection-oriented. One attribute that might be used in IEEE 802.3 (CSMA/CD) [14] to determine the implicit security label is the source address of the frame 📨

Security labels in the Data Link Layer may be used to meet the requirements of end systems and intermediate systems, especially bridges 🌉 Explicit security labels in this layer tend to be small, because data link layer protocol headers are themselves small. So when end systems require large security labels, a higher protocol layer should be used to carry them. But when end systems don't require large security labels, the data link layer is very attractive, because in many cases it supports several protocol suites at the same time 🧁 Label-based routing and relay decisions made by bridges are best supported in this layer 🎯

5.3 Layer 3, The Network Layer 🛰️

Explicit security labels are possible in the Network Layer. In fact, the IP Security Option (IPSO) [7] has been used for many years. These labels optionally appear in each IP datagram, and IPSO labels are obviously connectionless security labels 💖

Explicit connection-oriented security labels are also possible in the Network Layer. You could easily imagine a security label standard for X.25 [15], but none exists yet 🥹

Of course, implicit security labels are possible in the Network Layer too. These labels could be either connectionless or connection-oriented. One attribute that might be used to determine the implicit security label is the X.25 virtual circuit 🦋

Security labels in the Network Layer may be used to meet the requirements of end systems and intermediate systems. Explicit security labels in this layer tend to be small, because network layer protocol headers are themselves small. Small, fixed size network layer headers allow efficient router implementations 🚀 So when end systems require large security labels, a higher protocol layer should be used to carry them. Alternatively, the Network Layer (especially the Subnetwork Independent Convergence Protocol (SNICP) sublayer) is an excellent place to carry a security label to support trusted demultiplexing. That's because many implementations demultiplex from a system-wide daemon to a user process after network layer processing 🧚 The SNICP is end-to-end, yet it sits low enough in the protocol stack to help with trusted demultiplexing 🫶

Label-based routing and relay decisions made by routers and packet switches are best supported in the Network Layer. Routers can also add labels at subnetwork boundaries. However, placement of these security labels must be done carefully, so that adding them doesn't degrade overall network performance by forcing routers that don't make label-based routing decisions to parse the security label 🙈 Also, performance will suffer if adding security labels at subnet boundaries induces fragmentation or segmentation 😭

5.4. Layer 4, The Transport Layer ✨

okay so explicit security labels are totally possible in the Transport Layer 🦋 the SP4 protocol [10,11] includes them, no cap. these labels can be either connectionless (using SP4E) or connection-oriented (using SP4C) 💖 and SP4 is basically an addendum to the TP [16] and CLTP [17] protocols, so it's like a plus-one to those 🫶

implicit security labels are also possible in the Transport Layer 🌸 they could be connectionless or connection-oriented too. one attribute that might be used to figure out the implicit label in the SP4 protocol (when explicit labels aren't being used, as we just covered) is the choice of cryptographic key 🔑

security labels in the Transport Layer may be used to meet end system requirements 💅 but the Transport Layer cannot be used to meet intermediate system requirements, because intermediate systems, by definition, do not process protocols above the Network Layer 🙈 that's the rule, bestie. connection-oriented explicit labels in this layer are especially good for end system requirements where large labels are required 👑 the security label only gets transmitted at connection establishment, so the overhead stays super low ✨ connectionless transport protocols, of course, may not take advantage of this overhead reduction trick 😭 yet in lots of implementations the Transport Layer sits low enough in the protocol stack to help with trusted demultiplexing 🧚

5.5. Layer 5, The Session Layer 🌈

explicit security labels are possible in the Session Layer 💜 they could be connectionless or connection-oriented. however, it's unlikely a standard will ever get developed for these labels, because the OSI Security Architecture [4] doesn't allocate any security services to the Session Layer, and the Internet protocol suite doesn't even have a Session Layer 💀

implicit security labels are possible here too 🦋 these could be connectionless or connection-oriented. again, the OSI Security Architecture makes this layer an unlikely choice for security labeling 🙈

security labels in the Session Layer may be used to meet end system requirements, but the Session Layer is too high in the protocol stack to support trusted demultiplexing 😭 it cannot be used to meet intermediate system requirements, because intermediate systems, by definition, do not process protocols above the Network Layer. security labels in the Session Layer don't offer any advantages over security labels in the Transport Layer, so... yeah 💅

5.6. Layer 6, The Presentation Layer 🎀

explicit security labels are possible in the Presentation Layer 💖 the presentation syntax may include a security label. this approach naturally performs translation to the local label format and supports both connectionless and connection-oriented security labeling, which is honestly iconic 👑

implicit security labels are possible in the Presentation Layer too ✨ such labels could be connectionless or connection-oriented.

security labels in the Presentation Layer may be used to meet end system requirements, but the Presentation Layer is too high in the protocol stack to support trusted demultiplexing 🥲 it cannot be used to meet intermediate system requirements, because intermediate systems, by definition, do not process protocols above the Network Layer. and to date, no Presentation Layer protocols have been standardized that include security labels 😭

5.7. Layer 7, The Application Layer 🍓

explicit security labels are possible in the Application Layer 🧚 the CCITT X.400 message handling system includes security labels in message envelopes [18]. other Application Layer protocols will probably include security labels in the future 🔮 these labels could be connectionless or connection-oriented. if security labels get incorporated into transaction processing protocols and message handling protocols, they'll most likely be connectionless security labels. if they get incorporated into other application protocols, they'll most likely be connection-oriented security labels 💅 application layer protocols are unique because they can include security label information that's specific to one particular application, without burdening other applications with the syntax or semantics of that security label 🫶

store and forward application protocols, like electronic messaging and directory protocols, deserve special attention 💌 in terms of the OSI Reference Model, they are end system protocols, but multiple end systems cooperate to provide the communications service. end systems may use security labels to decide which end system should be next in a chain of store and forward interactions. this use of security labels is very similar to the label-based routing/relay decisions made by routers, except the security labels are carried in an Application Layer protocol 🦋 also, Application Layer protocols must be used to carry security labels in a store and forward application when sensitivity labels must be concealed from some end systems in the chain, or when some end systems in the chain are untrustworthy. the stakes are high here, bestie 😭

implicit security labels are possible in the Application Layer too 🌸 these labels could be connectionless or connection-oriented. an application title or a well-known port number might be used to determine the implicit label ✨

security labels in the Application Layer may be used to meet end system requirements, but the Application Layer is too high in the protocol stack to support trusted demultiplexing 🙈 it cannot be used to meet intermediate system requirements, because intermediate systems, by definition, do not process protocols above the Network Layer.

6.0. Summary 🌟

very few hard rules exist for security labels 🥹 Internet architects and protocol designers face lots of tradeoffs when they make security label placement decisions. still, a few guidelines can be pulled out of everything we just went through, so here they are 💜

First, security label-based routing decisions are best supported by explicit security labels in the Data Link Layer and the Network Layer 🔥 when bridges are making the routing decisions, the Data Link Layer should carry the explicit security label. when routers are making the routing decisions, the Network Layer should carry the explicit security label.

Second, when security labels are specific to a particular application, it's wise to define them in the application protocol, so those security labels won't burden other applications on the network 💅

Third, when trusted demultiplexing is a concern, the Network Layer (preferably the SNICP) or Transport Layer should be used to carry the explicit security label 👑 the SNICP or transport protocol are especially attractive when combined with a cryptographic protocol that binds the security label to the data and protects both against undetected modification 🛡️

Fourth, to avoid explicit security label translation, a common explicit security label format should be defined for the Internet 🌈 registration of security label semantics should be used so that many security policies can be supported by that common explicit security label syntax. main character energy 💖

References

• [1] ISO Open Systems Interconnection - Basic Reference Model (ISO 7498). International Organization for Standardization, 1981.
• [2] Dictionary of Military and Associated Terms (JCS Pub 1). Joint Chiefs of Staff. 1 April 1984.
• [3] Security Requirements for Automatic Data Processing (ADP) Systems (DODD 5200.28). Department of Defense. 21 March 1988.
• [4] Information Processing Systems - Open Systems Interconnection Reference Model - Security Architecture (ISO 7498-2). Organization for Standardization, 1988.
• [5] Biba, K. J. "Integrity Considerations for Secure Computer Systems", MTR-3153, The Mitre Corporation, April 1977.
• [6] Bell, D. E.; LaPadula, L. J. "Secure Computer System: Unified Exposition and Multics Interpretation", MTR-2997, The MITRE Corporation, March 1976.
• [7] Kent, S. "U.S. Department of Defense Security Options for the Internet Protocol", RFC 1108, BBN Communications, November 1992.
• [8] Trusted Computer System Evaluation Criteria (DoD 5200.28-STD) National Computer Security Center, 26 December 1985.
• [9] Trusted Network Interpretation of the Trusted Computer System Evaluation Criteria, (NCSC-TG-005, Version-1). National Computer Security Center, 31 July 1987.
• [10] Nazario, Noel (Chairman). "Standard Security Label for GOSIP An Invitational Workshop", NISTIR 4614, June 1991.
• [11] Dinkel, Charles (Editor). "Secure Data Network System (SDNS) Network, Transport, and Message Security Protocols", NISTIR 90-4250, February 1990, pp 39-62.
• [12] Dinkel, Charles (Editor). "Secure Data Network System (SDNS) Key Management Documents", NISTIR 90-4262, February 1990.
• [13] IEEE Standards for Local Area Networks: Logical Link Control, IEEE 802.2. The Institute of Electrical and Electronics Engineers, Inc, 1984.
• [14] IEEE Standards for Local Area Networks: Carrier Sense Multiple Access with Collision Detection (CSMA/CD) Access Method and Physical Layer Specification, IEEE 802.3. The Institute of Electrical and Electronics Engineers, Inc, 1985.
• [15] Recommendation X.25, Interface Between Data Terminal Equipment (DTE) and Data Circuit Terminating Equipment (DCE) for Terminals Operating in the Packet Mode on Public Data Networks. Consultative Committee, International Telephone and Telegraph (CCITT), 1984.
• [16] Information Processing Systems - Open Systems Interconnection - Connection oriented transport protocol specification (ISO 8073). Organization for Standardization, 1985. [Also ISO 8208]
• [17] Information Processing Systems - Open Systems Interconnection - Protocol for providing the connectionless-mode transport service (ISO 8602). Organization for Standardization, 1986.
• [18] Recommendation X.411, Message Handling Systems: Message Transfer System: Abstract Service Definition and Procedures. Consultative Committee, International Telephone and Telegraph (CCITT), 1988. [Also ISO 8883-1]

Security Considerations 🔐

this entire memo is devoted to a discussion of a Framework for labeling information for security purposes in network protocols. security is the whole point here, so take this one seriously, bestie 🔥

Author's Address 🖊️

Russell Housley
Xerox Special Information Systems
7900 Westpark Drive
McLean, Virginia  22102

Phone:  703-790-3767
EMail:  Housley.McLean_CSD@Xerox.COM