rfc1457.txt

RFC 的详细文档！

   such labels because the OSI Security Architecture [4] does not
   allocate any security services to the Session Layer, and the Internet
   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 an
   unlikely choice for security labeling.

   Security labels in the Session Layer may be used to meet the
   requirements of end systems, but the Session Layer is too high in the
   protocol stack to support trusted demultiplexing.  The Session Layer
   cannot be used to meet the requirements of intermediate systems
   because intermediate systems, by definition, do not process protocols
   above the Network Layer.  Security labels in the Session Layer do not
   offer any advantages to security labels in the Transport Layer.

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.

   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 the
   requirements of end systems, but the Presentation Layer is too high
   in the protocol stack to support trusted demultiplexing.  The
   Presentation Layer cannot be used to meet the requirements of
   intermediate systems because intermediate systems, by definition, do



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


   not process protocols above the Network Layer.  To date, no
   Presentation Layer protocols have been standardized which 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 either connectionless or connection-oriented.  Should security
   labels be incorporated into transaction processing protocols and
   message handling protocols, these will most likely be connectionless
   security labels; should security labels be incorporated into other
   application protocols, these will most likely be connection-oriented
   security labels.  Application layer protocols are unique in that they
   can include security label information which is specific to a
   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 determine 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 that 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.

   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 determine
   the implicit label.

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







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


6.0  Summary

   Very few hard rules exist for security labels. Internet architects
   and protocol designers face many tradeoffs when making security label
   placement decisions.  However, a few guidelines can be derived from
   the preceding discussion:

   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 is wise to define them in the application protocol, so that these
   security labels will not 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 the 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 the common explicit security
   label syntax.

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.



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


   [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.





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


  [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.

Author's Address

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

   Phone:  [phone]
   EMail:  [e-mail]
































Housley                                                        [Page 14]