As per Relevance of the word intermediate, we have this rfc below:
Network Working Group R.
Request for Comments: 1457 Xerox Special Information
May 1993
Security Label Framework for the
Status of this
This memo provides information for the Internet community. It
not specify an Internet standard. Distribution of this memo
unlimited
The members of the Privacy and Security Research Group and
attendees of the invitational Security Labels Workshop (hosted by
National Institute of Standards and Technology) helped me organize
thoughts on this subject. The ideas of these professionals
scattered throughout the memo
1.0
This memo presents a security labeling framework for the Internet
The framework is intended to help protocol designers determine what
if any, security labeling should be supported by their protocols
The framework should also help network architects determine
or not a particular collection of protocols fulfill their
labeling requirements. The Open Systems Interconnection
Model [1] provides the structure for the presentation, therefore
protocol designers may also find this memo useful
2.0 Security
Data security is the set of measures taken to protect data
accidental, unauthorized, intentional, or malicious modification
destruction, or disclosure. Data security is also the condition
results from the establishment and maintenance of protective
[2]. Given this two-pronged definition for data security, this
examines security labeling as one mechanism which provides
security. In general, security labeling by itself does not
sufficient data security; it must be complemented by other
mechanisms
In data communication protocols, security labels tell the
processing how to handle the data transferred between two systems
That is, the security label indicates what measures need to be
to preserve the condition of security. Handling means the
Housley [Page 1]
RFC 1457 Security Label Framework for the Internet May 1993
performed on data such as collecting, processing, transferring
storing, retrieving, sorting, transmitting, disseminating,
controlling [3].
The definition of data security includes protection from
and destruction. In computer systems, this is protection
writing and deleting. These protections implement the data
service defined in the OSI Security Architecture [4].
Biba [5] has defined a data integrity model which includes
labels. The Biba model specifies rule-based controls for writing
deleting necessary to preserve data integrity. The model
specifies rule-based controls for reading to prevent a high
process from relying on data that has less integrity than
process
The definition of data security also includes protection
disclosure. In computer systems, this is protection from reading
This protection is the data confidentiality service defined in
OSI Security Architecture [4].
Bell and LaPadula [6] defined a data confidentiality model
includes security labels. The Bell and LaPadula model
rule-based controls for reading necessary to preserve
confidentiality. The model also specifies rule-based controls
writing to ensure that data is not copied to a container
confidentiality can not be guaranteed
In both the Biba model and the Bell and LaPadula model, the
label is an attribute of the data. In general, the security
associated with the data remains constant. Exceptions will
discussed later in the memo, but relabeling is always the result
some network entity handling the data. Since the security label
an attribute of data, it should be bound to the data. When
moves through the network, the integrity security service [4]
generally used to accomplish this binding. If the
environment does not include a protocol which provides the
security service to bind the security label to the data, then
communications environment should include other mechanisms
preserve this binding
2.1 Integrity
Integrity labels are security labels which support data
models, like the Biba model. The integrity label tells the degree
confidence that may be placed in the data and also indicates
measures the data requires for protection from modification
destruction
Housley [Page 2]
RFC 1457 Security Label Framework for the Internet May 1993
As data moves through the network, the confidence that may be
in that data may change as a result of being handled by
network components. Therefore, the integrity label is a function
the integrity of the data before being transmitted on the network
the path that the data takes through the network. The
that may be placed in data does not increase because it
transferred across a network, but the confidence that may be
in data may decrease as a result of being handled by
network components. Entities are assigned integrity labels
indicate how much confidence may be placed in data that is handled
them. Thus, when data is handled by an entity with an
label lower than the integrity label of the data, the data
relabeled with the integrity label of the entity. Such
should be avoided by limiting the possible paths that data may
through the network to those where the data will be handled only
entities with the same or a higher integrity label than the data
When integrity labels are used, each of the systems on a network
implement the integrity model and the protocol suite must
the integrity label with the data, if the confidence of the data
to be maintained throughout the network. Each of the systems on
network may have its own internal representation for a
label, but the protocols must provide common syntax and semantics
the transfer of the integrity label, as well as the data itself.
date, no protocols have been standardized which include
labels in the protocol control information
2.2 Sensitivity
Sensitivity labels are security labels which support
confidentiality models, like the Bell and LaPadula model.
sensitivity label tells the amount of damage that will result
the disclosure of the data and also indicates which measures the
requires for protection from disclosure. The amount of damage
results from unauthorized disclosure depends on who obtains the data
the sensitivity label should reflect the worst case
As data moves through the network, it is processed by various
components and may be mixed with data of differing sensitivity.
these network components are not trusted to segregate data
differing sensitivities, then all of the data processed by
components must be handled as the most sensitive data processed
those network components. For example, poor buffer management
append highly sensitive data to the end of a protocol data unit
was otherwise publicly releasable. Therefore, the sensitivity
is a function of the sensitivity of the data before being
on the network and the most sensitive data handled by the
components, and the trustworthiness of those network components.
Housley [Page 3]
RFC 1457 Security Label Framework for the Internet May 1993
amount of damage that will result from the disclosure of the
does not decrease because it was transferred across a network,
the amount of damage that will result from the disclosure of the
may increase as a result of being mixed with more sensitive data
arbitrary network components. Thus, when data is handled by
untrusted entity with a sensitivity label higher than the
label of the data, the data is relabeled with the higher
label. Such relabeling should be avoided by limiting the
paths that data may take through the network to those where the
will be handled only by entities with the same sensitivity label
the data or by using trustworthy network components. Entities
lower sensitivity labels may not handle the data because this
be disclosure
When sensitivity labels are used, each of the systems on a
must implement the sensitivity model and the protocol suite
transfer the sensitivity label with the data, if the protection
disclosure is to be maintained throughout the network. Each of
systems on a network may have its own internal representation for
sensitivity label, but the protocols must provide common syntax
semantics for the transfer of the sensitivity label, as well as
data itself. Sensitivity labels, like the ones provided by the
Security Option (IPSO) [7], have been used in a few networks
years
3.0 Security Label
The Internet includes two major types of systems: end systems
intermediate systems [1]. These terms should be familiar to
reader. For this discussion, the definition of intermediate
is understood to include routers, packet switches, and bridges.
systems and intermediate systems use security labels differently
3.1 End System Security Label
When two end systems communicate, common security label syntax
semantics are needed. The security label, as an attribute of
data, indicates what measures need to be taken to preserve
condition of security. The security label must communicate all
the integrity and confidentiality handling requirements.
requirements can become very complex
Some operating systems label the data they process. These
labels are not part of the data; they are attributes of the data
Some database management systems (DBMSs) perform similar labeling
The format of these security labels is a local matter, but they
usually in a format different than the one used by the
communication protocols. Security labels must be translated by
Housley [Page 4]
RFC 1457 Security Label Framework for the Internet May 1993
operating systems and DBMSs between the local format and the
used in the data communication protocols without any loss of meaning
Trusted operating systems that implement rule-based access
policies require security labels on the data they import [8,9].
These security labels permit the Trusted Computing Base (TCB) in
end system to perform trusted demultiplexing. That is, the
is relayed from the TCB to a process only if the process
sufficient authorization for the data. In most cases, the TCB
first translate the security label into the local syntax before
can make the access control decision
3.2 Intermediate System Security Label
This section discusses "user" data security labels within
intermediate system. The labeling requirements associated
intermediate system-to-end system (IS-ES) traffic,
system-to-intermediate system (IS-IS) traffic, and
system-to-network management (IS-NM) traffic are not included in
discussion
Intermediate systems may make routing choices or discard
based on the security label. The security label used by
intermediate system should contain only enough information to
the routing/discard decision and may be a subset of the
label used by the end system. Some portions of the label may
effect routing decisions, but they may effect processing done
the end system
In the Internet today, very few intermediate systems actually
access control decisions. For performance reasons, only
intermediate systems which do make access control decisions should
burdened with parsing the security label. That is,
hiding principles apply. Further, security labels which are to
parsed only by end systems should not be visible to physical,
link, or network layer protocols, where intermediate systems
have to examine them
Intermediate systems do not usually translate the security labels
a local format. They use them "as is" to make their routing/
decisions. However, when two classification authorities share
network by bilateral agreement, the intermediate systems may
required to perform security label translation. Security
translations should be avoided whenever possible by using a
label format that is supported by all systems that will process
security label. Since end systems do not generally know
intermediate systems will process their traffic, security
translation cannot always be avoided
Housley [Page 5]
RFC 1457 Security Label Framework for the Internet May 1993
Since security labels which are to be parsed only by end
should not be carried by protocols interpreted by
systems, such security labels should be carried by upper
protocols, and end systems which use different formats for
security labels cannot rely on an intermediate systems to
security label translation. Neither the Internet nor the
architecture includes such transformation functions in the transport
session, or presentation layer, which means that application
gateways should be used to translate between different end
security label formats. Such application gateways should be
because they impinge on operation, especially when
compatible protocols are used. This complication is another
why the use of a security label format that is supported by
systems is desirable. A standard label syntax with
security label semantics goes a long way toward avoiding
label translation [10].
4.0 Approaches to
There are several tradeoffs to be made when determining how
particular network will perform security labeling. Explicit
implicit labels can be used. Also, security labels can either
connectionless or connection-oriented. A combination of
alternatives may be appropriate
4.1 Explicit Versus Implicit Security
Explicit security labels are actual bits in the protocol
information (PCI). The IP Security Option (IPSO) is an example of
explicit security label [7]. Explicit security labels may be
connectionless or connection-oriented. The syntax and semantics
the explicit security label may be either tightly or loosely coupled
If the syntax and semantics are tightly coupled, then the
security label format supports a single security policy. If
syntax and semantics are loosely coupled, then the explicit
label format can support multiple security policies
registration. In both cases, software enforces the security policy
but the label parsing software can be written once if the syntax
semantics are loosely coupled. Fixed length explicit security
format parsers are generally faster than parsers for variable
formats. Intermediate systems suffer less performance impact
fixed length explicit security labels can be used, but end
often need variable length explicit security labels to express
handling requirements
Implicit security labels are not actual bits in the PCI; instead
some attribute is used to determine the security label. For example
the choice of cryptographic key in the SP4 protocol [11]
Housley [Page 6]
RFC 1457 Security Label Framework for the Internet May 1993
determine the security label. Implicit security labels may be
connectionless or connection-oriented
4.2 Connectionless Versus Connection-oriented Security
When connectionless security labels are used, the security
appears in every protocol data unit (PDU). The IP Security
(IPSO) [7] is an example of connectionless labeling. All
have limits on the size of their PCI, and the explicit security
cannot exceed this size limit. It cannot use the entire PCI
either; the protocol has other fields that must be transferred
well. This size limitation may prohibit explicit
security labels from meeting the requirements of end systems
However, the requirements of intermediate systems are more
satisfied by explicit connectionless security labels
Connection-oriented security labels are attributes of
circuits, connections, and associations. For simplicity, all
these are subsequently referred to as connections. Connection
oriented security labels are used when the SDNS Key
Protocol (KMP) [12] is used to associate security labels with each
the transport connection protected by the SP4 protocol [10,11] (
SP4C). The security label is defined at connection establishment
and all data transferred over the connection inherits that
label. This approach is more compatible with end system
than intermediate system requirements. One noteworthy exception
X.25 packets switches; these intermediate systems could
connection-oriented labels with each virtual circuit
Connectionless security labels may be used in conjunction
connectionless or connection-oriented data transfer protocols
However, connection-oriented security labels may only be used
conjunction with connection-oriented data transfer protocols
5.0 Labeling Within the OSI Reference
This section examines each of the seven OSI layers with respect
security labels
5.1 Layer 1, The Physical
Explicit security labels are not possible in the Physical Layer.
Physical Layer does not include any protocol control
(PCI), so there is no place to include the bits which represent
label
Implicit security labels are possible in the Physical Layer.
example, all of the data that comes in through a particular
Housley [Page 7]
RFC 1457 Security Label Framework for the Internet May 1993
port could inherit one security label. Most Physical
communication is connectionless, supporting only bit-at-a-time
byte-at-a-time operations. Thus, these implicit security labels
connectionless
Implicit security labels in the Physical Layer may be used to
the requirements of either end systems or intermediate systems
long as the communication is single level. That is, only
security label is associated with all of the data received
transmitted through the physical connection
5.2 Layer 2, The Data Link
Explicit security labels are possible in the Data Link Layer.
fact, the IEEE 802.2 Working Group is currently working on
optional security label standard for the Logical Link Control (LLC
protocol (IEEE 802.2) [13]. These labels will optionally appear
each LLC frame. These are connectionless security labels
Explicit connection-oriented security labels are also possible in
Data Link Layer. One could imagine a security label standard
worked with LLC Type II
Of course, implicit security labels are also possible in the
Link Layer. Such labels could be either connectionless
connection-oriented. One attribute that might be used in IEEE 802.3
(CSMA/CD) [14] to determine the implicit security label is the
address of the frame
Security labels in the Data Link Layer may be used to meet
requirements of end systems and intermediate systems (
bridges). Explicit security labels in this layer tend to be
because the protocol headers for data link layer protocols
themselves small. Therefore, when end systems require large
labels, a higher protocol layer should used to carry them. However
when end systems do not require large security labels, the data
layer is attractive because in many cases the data link
protocol supports several protocol suites simultaneously. Label
based routing/relay decisions made by bridges are best supported
this layer
5.3 Layer 3, The Network
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. IPSO labels
obviously connectionless security labels
Housley [Page 8]
RFC 1457 Security Label Framework for the Internet May 1993
Explicit connection-oriented security labels are also possible in
Network Layer. One could easily imagine a security label
for X.25 [15], but none exists
Of course, implicit security labels are also possible in the
Layer. These labels could be either connectionless or connection
oriented. One attribute that might be used to determine the
security label is the X.25 virtual circuit
Security labels in the Network Layer may be used to meet
requirements of end systems and intermediate systems.
security labels in this layer tend to be small because the
headers for network layer protocols are themselves small.
fixed size network layer protocol headers allow efficient
implementations. Therefore, when end systems require large
labels, a higher protocol layer should used to carry them
Alternatively, the Network Layer (especially the
Independent Convergence Protocol (SNICP) sublayer) is an
place to carry a security label to support trusted demultiplexing
because many implementations demultiplex from an system-wide
to a user process after network layer processing. The SNICP is end
to-end, yet it is low enough in the protocol stack to aid
demultiplexing
Label-based routing/relay decisions made by routers and
switches are best supported in the Network Layer. Routers can
add labels at subnetwork boundaries. However, placement of
security labels must be done carefully to ensure that their
does not degrade overall network performance by forcing routers
do not make label-based routing decisions to parse the
label. Also, performance will suffer if the addition of
labels at subnet boundaries induces fragmentation/segmentation
5.4 Layer 4, The Transport
Explicit security labels are possible in the Transport Layer.
example, the SP4 protocol [10,11] includes them. These labels can
either connectionless (using SP4E) or connection-oriented (
SP4C). SP4 is an addendum to the TP [16] and CLTP [17] protocols
Implicit security labels are also possible in the Transport Layer
Such labels could be either connectionless or connection-oriented
One attribute that might be used to determine the implicit label
the SP4 protocol (when explicit labels are not used as
above) is the choice of cryptographic key
Security labels in the Transport Layer may be used to meet
requirements of end systems. The Transport Layer cannot be used
Housley [Page 9]
RFC 1457 Security Label Framework for the Internet May 1993
meet the requirements of intermediate systems because
systems, by definition, do not process protocols above the
Layer. Connection-oriented explicit security labels in this
are especially good for meeting end system requirements where
labels are required. The security label is transmitted only
connection establishment, so overhead is kept to a minimum.
course, connectionless transport protocols may not take advantage
this overhead reduction technique. Yet, in many implementations
Transport Layer is low enough in the protocol stack to aid
demultiplexing
5.5 Layer 5, The Session
Explicit security labels are possible in the Session Layer.
labels could be either connectionless or connection-oriented
However, it is unlikely that a standard will ever be developed
such labels because the OSI Security Architecture [4] does
allocate any security services to the Session Layer, and the
protocol suite does not have a Session Layer
Implicit security labels are also possible in the Session Layer
These implicit labels could be either connectionless or connection
oriented. Again, the OSI Security Architecture makes this layer
unlikely choice for security labeling
Security labels in the Session Layer may be used to meet
requirements of end systems, but the Session Layer is too high in
protocol stack to support trusted demultiplexing. The Session
cannot be used to meet the requirements of intermediate
because intermediate systems, by definition, do not process
above the Network Layer. Security labels in the Session Layer do
offer any advantages to security labels in the Transport Layer
5.6 Layer 6, The Presentation
Explicit security labels are possible in the Presentation Layer.
presentation syntax may include a security label. This
naturally performs translation to the local label format and
both connectionless and connection-oriented security labeling
Implicit security labels are also possible in the Presentation Layer
Such labels could be either connectionless or connection-oriented
Security labels in the Presentation Layer may be used to meet
requirements of end systems, but the Presentation Layer is too
in the protocol stack to support trusted demultiplexing.
Presentation Layer cannot be used to meet the requirements
intermediate systems because intermediate systems, by definition,
Housley [Page 10]
RFC 1457 Security Label Framework for the Internet May 1993
not process protocols above the Network Layer. To date,
Presentation Layer protocols have been standardized which
security labels
5.7 Layer 7, The Application
Explicit security labels are possible in the Application Layer.
CCITT X.400 message handling system includes security labels
message envelopes [18]. Other Application Layer protocols
probably include security labels in the future. These labels
be either connectionless or connection-oriented. Should
labels be incorporated into transaction processing protocols
message handling protocols, these will most likely be
security labels; should security labels be incorporated into
application protocols, these will most likely be connection-
security labels. Application layer protocols are unique in that
can include security label information which is specific to
particular application without burdening other applications with
syntax or semantics of that security label
Store and forward application protocols, like electronic
and directory protocols, deserve special attention. In terms of
OSI Reference Model, they are end system protocols, but multiple
systems cooperate to provide the communications service. End
may use security labels to determine which end system should be
in a chain of store and forward interactions; this use of
labels is very similar to the label-based routing/relay
made by routers except that the security labels are carried in
Application Layer protocol. Also, Application Layer protocols
be used to carry security labels in a store and forward
when sensitivity labels must be concealed from some end systems
the chain or when some end systems in the chain are untrustworthy
Implicit security labels are also possible in the Application Layer
These labels could be either connectionless or connection-oriented
Application title or well know port number might be used to
the implicit label
Security labels in the Application Layer may be used to meet
requirements of end systems, but the Application Layer is too high
the protocol stack to support trusted demultiplexing.
Application Layer cannot be used to meet the requirements
intermediate systems because intermediate systems, by definition,
not process protocols above the Network Layer
Housley [Page 11]
RFC 1457 Security Label Framework for the Internet May 1993
6.0
Very few hard rules exist for security labels. Internet
and protocol designers face many tradeoffs when making security
placement decisions. However, a few guidelines can be derived
the preceding discussion
First, security label-based routing decisions are best supported
explicit security labels in the Data Link Layer and the
Layer. When bridges are making the routing decisions, the Data
Layer should carry the explicit security label; when routers
making the routing decisions, the Network Layer should carry
explicit security label
Second, when security labels are specific to a particular
it is wise to define them in the application protocol, so that
security labels will not burden other applications on the network
Third, when trusted demultiplexing is a concern, the Network
(preferably the SNICP) or Transport Layer should be used to carry
explicit security label. The SNICP or transport protocol
especially attractive when combined with a cryptographic
that binds the security label to the data and protects the
against undetected modification
Fourth, to avoid explicit security label translation, a
explicit security label format should be defined for the Internet
Registration of security label semantics should be used so that
security policies can be supported by the common explicit
label syntax
[1] ISO Open Systems Interconnection - Basic Reference Model (
7498). International Organization for Standardization, 1981.
[2] Dictionary of Military and Associated Terms (JCS Pub 1).
Chiefs of Staff. 1 April 1984.
[3] Security Requirements for Automatic Data Processing (ADP)
(DODD 5200.28). Department of Defense. 21 March 1988.
[4] Information Processing Systems - Open Systems
Reference Model - Security Architecture (ISO 7498-2).
Organization for Standardization, 1988.
[5] Biba, K. J. "Integrity Considerations for Secure
Systems", MTR-3153, The Mitre Corporation, April 1977.
Housley [Page 12]
RFC 1457 Security Label Framework for the Internet May 1993
[6] Bell, D. E.; LaPadula, L. J. "Secure Computer System:
Exposition and Multics Interpretation", MTR-2997, The
Corporation, March 1976.
[7] Kent, S. "U.S. Department of Defense Security Options for
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
Evaluation Criteria, (NCSC-TG-005, Version-1). National
Security Center, 31 July 1987.
[10] Nazario, Noel (Chairman). "Standard Security Label for GOSIP
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)
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
Engineers, Inc, 1984.
[14] IEEE Standards for Local Area Networks: Carrier Sense
Access with Collision Detection (CSMA/CD) Access Method
Physical Layer Specification, IEEE 802.3. The Institute
Electrical and Electronics Engineers, Inc, 1985.
[15] Recommendation X.25, Interface Between Data Terminal
(DTE) and Data Circuit Terminating Equipment (DCE) for
Operating in the Packet Mode on Public Data Networks
Consultative Committee, International Telephone and
(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
(ISO 8602). Organization for Standardization, 1986.
Housley [Page 13]
RFC 1457 Security Label Framework for the Internet May 1993
[18] Recommendation X.411, Message Handling Systems: Message
System: Abstract Service Definition and Procedures.
Committee, International Telephone and Telegraph (CCITT), 1988.
[Also ISO 8883-1]
Security
This entire memo is devoted to a discussion of a Framework
labeling information for security purposes in network protocols
Author's
Russell
Xerox Special Information
7900 Westpark
McLean, Virginia 22102
Phone: 703-790-3767
EMail: Housley.McLean_CSD@Xerox.
Housley [Page 14]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
