rfc1457.txt

RFC 的详细文档！

Network Working Group                                         R. Housley
Request for Comments: 1457             Xerox Special Information Systems
                                                                May 1993


               Security Label Framework for the Internet

Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard.  Distribution of this memo 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 me organize my
   thoughts on this subject.  The ideas of these professionals are
   scattered throughout the memo.

1.0  Introduction

   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 whether
   or not a particular collection of protocols fulfill their security
   labeling requirements.  The Open Systems Interconnection Reference
   Model [1] provides the structure for the presentation, therefore OSI
   protocol designers may also find this memo useful.

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.  Data security is also the condition that
   results from the establishment and maintenance of protective measures
   [2].  Given this two-pronged definition for data security, this memo
   examines security labeling as one mechanism which 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 the protocol
   processing how to handle the data transferred between two systems.
   That is, the security label indicates what measures need to be taken
   to preserve the condition of security.  Handling means the activities



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, and
   controlling [3].

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

   Biba [5] has defined a data integrity model which includes security
   labels.  The Biba model specifies rule-based controls for writing and
   deleting necessary to preserve data integrity.  The model also
   specifies rule-based controls for reading to prevent a high integrity
   process from relying on data that has less integrity than the
   process.

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

   Bell and LaPadula [6] defined a data confidentiality model which
   includes security labels.  The Bell and LaPadula model specifies
   rule-based controls for reading necessary to preserve data
   confidentiality.  The model also specifies rule-based controls for
   writing to ensure that data is not copied to a container where
   confidentiality can not 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 security label
   associated with the data remains constant.  Exceptions will be
   discussed later in the memo, but relabeling is always the result of
   some network entity handling the data.  Since the security label is
   an attribute of data, it should be bound to the data.  When data
   moves through the network, the integrity security service [4] is
   generally used to accomplish this binding.  If the communications
   environment does not include a protocol which provides the integrity
   security service to bind the security label to the data, then the
   communications environment should include other mechanisms to
   preserve this binding.

2.1  Integrity Labels

   Integrity labels are security labels which support data integrity
   models, like the Biba model.  The integrity label tells the degree of
   confidence that may be placed in the data and also indicates which
   measures the data requires for protection from modification and
   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 placed
   in that data may change as a result of being handled by various
   network components.  Therefore, the integrity label is a function of
   the integrity of the data before being transmitted on the network and
   the path that the data takes through the network.  The confidence
   that may be placed in data does not increase because it was
   transferred across a network, but the confidence that may be placed
   in data may decrease as a result of being handled by arbitrary
   network components.  Entities are assigned integrity labels which
   indicate how much confidence may be placed in data that is handled by
   them.  Thus, when data is handled by an entity with an integrity
   label lower than the integrity label of the data, the data is
   relabeled with the integrity label of the entity.  Such relabeling
   should be avoided by limiting the possible paths that data may take
   through the network to those where the data will be handled only by
   entities with the same or a higher integrity label than the data.

   When integrity labels are used, each of the systems on a network must
   implement the integrity model and the protocol suite must transfer
   the integrity label with the data, if the confidence of the data is
   to be maintained throughout the network.  Each of the systems on a
   network may have its own internal representation for a integrity
   label, but the protocols must provide common syntax and semantics for
   the transfer of the integrity label, as well as the data itself.  To
   date, no protocols have been standardized which include integrity
   labels in the protocol control information.

2.2  Sensitivity Labels

   Sensitivity labels are security labels which support data
   confidentiality models, like the Bell and LaPadula model.  The
   sensitivity label tells the amount of damage that will result from
   the disclosure of the data and also indicates which measures the data
   requires for protection from disclosure.  The amount of damage that
   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 network
   components and may be mixed with data of differing sensitivity.  If
   these network components are not trusted to segregate data of
   differing sensitivities, then all of the data processed by those
   components must be handled as the most sensitive data processed by
   those network components.  For example, poor buffer management may
   append highly sensitive data to the end of a protocol data unit that
   was otherwise publicly releasable.  Therefore, the sensitivity label
   is a function of the sensitivity of the data before being transmitted
   on the network and the most sensitive data handled by the network
   components, and the trustworthiness of those network components.  The



Housley                                                         [Page 3]

RFC 1457       Security Label Framework for the Internet        May 1993


   amount of damage that will result from the disclosure of the data
   does not decrease because it was transferred across a network, but
   the amount of damage that will result from the disclosure of the data
   may increase as a result of being mixed with more sensitive data by
   arbitrary network components.  Thus, when data is handled by an
   untrusted entity with a sensitivity label higher than the sensitivity
   label of the data, the data is relabeled with the higher sensitivity
   label.  Such relabeling should be avoided by limiting the possible
   paths that data may take through the network to those where the data
   will be handled only 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 this would
   be disclosure.

   When sensitivity labels are used, each of the systems on a network
   must implement the sensitivity model and the protocol suite must
   transfer the sensitivity label with the data, if the protection from
   disclosure is to be maintained throughout the network.  Each of the
   systems on a network may have its own internal representation for a
   sensitivity label, but the protocols must provide common syntax and
   semantics for the transfer of the sensitivity label, as well as 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 the
   reader.  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, indicates 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 become very complex.

   Some operating systems label the data they process.  These security
   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 are
   usually in a format different than the one used by the data
   communication protocols.  Security labels must be translated by these



Housley                                                         [Page 4]

RFC 1457       Security Label Framework for the Internet        May 1993


   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 permit the Trusted Computing Base (TCB) in the
   end system to perform trusted demultiplexing.  That is, the 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 the local syntax before it
   can make the access control decision.

3.2  Intermediate System Security Label Usage

   This section discusses "user" data security labels within the
   intermediate system.  The labeling requirements associated with
   intermediate system-to-end system (IS-ES) traffic, intermediate
   system-to-intermediate system (IS-IS) traffic, and intermediate
   system-to-network management (IS-NM) traffic are not included in this
   discussion.

   Intermediate systems may make routing choices or discard traffic
   based on the security label.  The security label used by the
   intermediate system should contain only enough information to make
   the routing/discard decision and may be a subset of the security
   label used by the end system.  Some portions of the label may not
   effect routing decisions, but they may effect processing done within
   the end system.

   In the Internet today, very few intermediate systems actually make
   access control decisions.  For performance reasons, only those
   intermediate systems which do make access control decisions should be
   burdened with parsing the security label.  That is, information