diff options
Diffstat (limited to 'doc/rfc/rfc1457.txt')
| -rw-r--r-- | doc/rfc/rfc1457.txt | 787 |
1 files changed, 787 insertions, 0 deletions
diff --git a/doc/rfc/rfc1457.txt b/doc/rfc/rfc1457.txt new file mode 100644 index 0000000..22d64dd --- /dev/null +++ b/doc/rfc/rfc1457.txt @@ -0,0 +1,787 @@ + + + + + + +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 + hiding principles apply. Further, security labels which are to be + parsed only by end systems should not be visible to physical, data + link, or network layer protocols, where intermediate systems will + have to examine them. + + Intermediate systems do not usually translate the security labels to + a local format. They use them "as is" to make their routing/discard + decisions. However, when two classification authorities share a + network by bilateral agreement, the intermediate systems may be + required to perform security label translation. Security label + translations should be avoided whenever possible by using a security + label format that is supported by all systems that will process the + security label. Since end systems do not generally know which + intermediate systems will process their traffic, security label + 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 systems + should not be carried by protocols interpreted by intermediate + systems, such security labels should be carried by upper layer + protocols, and end systems which use different formats for such + security labels cannot rely on an intermediate systems to perform + security label translation. Neither the Internet nor the OSI + architecture includes such transformation functions in the transport, + session, or presentation layer, which means that application layer + gateways should be used to translate between different end system + security label formats. Such application gateways should be avoided + because they impinge on operation, especially when otherwise + compatible protocols are used. This complication is another reason + why the use of a security label format that is supported by all + systems is desirable. A standard label syntax with registered + security label semantics goes a long way toward avoiding security + label translation [10]. + +4.0 Approaches to Labeling + + There are several tradeoffs to be made when determining how a + particular network will perform security labeling. Explicit or + implicit labels can be used. Also, security labels can either be + connectionless or connection-oriented. A combination of these + alternatives may be appropriate. + +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 either + connectionless or connection-oriented. The syntax and semantics of + the explicit security label may be either tightly or loosely coupled. + If the syntax and semantics are tightly coupled, then the explicit + security label format supports a single security policy. If the + syntax and semantics are loosely coupled, then the explicit security + label format can support multiple security policies through + registration. In both cases, software enforces the security policy, + but the label parsing software can be written once if the syntax and + semantics are loosely coupled. Fixed length explicit security label + format parsers are generally faster than parsers for variable length + formats. Intermediate systems suffer less performance impact when + fixed length explicit security labels can be used, but end systems + often need variable length explicit security labels to express data + 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] can + + + +Housley [Page 6] + +RFC 1457 Security Label Framework for the Internet May 1993 + + + determine the security label. Implicit security labels may be either + connectionless or connection-oriented. + +4.2 Connectionless Versus Connection-oriented Security Labels + + When connectionless security labels are used, the security label + appears in every protocol data unit (PDU). The IP Security Option + (IPSO) [7] is an example of connectionless labeling. All protocols + have limits on the size of their PCI, and the explicit security label + cannot exceed this size limit. It cannot use the entire PCI space + either; the protocol has other fields that must be transferred as + well. This size limitation may prohibit explicit connectionless + security labels from meeting the requirements of end systems. + However, the requirements of intermediate systems are more easily + satisfied by explicit connectionless security labels. + + Connection-oriented security labels are attributes of virtual + circuits, connections, and associations. For simplicity, all of + these are subsequently referred to as connections. Connection- + oriented security labels are used when the SDNS Key Management + Protocol (KMP) [12] is used to associate security labels with each of + the transport connection protected by the SP4 protocol [10,11] (using + SP4C). The security label is defined at connection establishment, + and all data transferred over the connection inherits that security + label. This approach is more compatible with end system requirements + than intermediate system requirements. One noteworthy exception is + X.25 packets switches; these intermediate systems could associate + connection-oriented labels with each virtual circuit. + + Connectionless security labels may be used in conjunction with + connectionless or connection-oriented data transfer protocols. + However, connection-oriented security labels may only be used in + conjunction with connection-oriented data transfer protocols. + +5.0 Labeling Within the OSI Reference Model + + This section examines 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 does not include any protocol control information + (PCI), so there is no place to include the bits which represent the + label. + + Implicit security labels are possible in the Physical Layer. For + example, all of the data that comes in through a particular physical + + + +Housley [Page 7] + +RFC 1457 Security Label Framework for the Internet May 1993 + + + port could inherit one security label. Most Physical Layer + communication is connectionless, supporting only bit-at-a-time or + byte-at-a-time operations. Thus, these implicit security labels are + connectionless. + + Implicit security labels in the Physical Layer may be used to meet + the requirements of either end systems or intermediate systems so + long as the communication is single level. That is, 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. These are connectionless security labels. + + Explicit connection-oriented security labels are also possible in the + Data Link Layer. One could imagine a security label standard which + worked with LLC Type II. + + Of course, implicit security labels are also possible in the Data + Link Layer. Such labels 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 the protocol headers for data link layer protocols are + themselves small. Therefore, when end systems require large security + labels, a higher protocol layer should used to carry them. However, + when end systems do not require large security labels, the data link + layer is attractive because in many cases the data link layer + protocol supports several protocol suites simultaneously. Label- + based routing/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. IPSO labels are + 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 the + Network Layer. One could easily imagine a security label standard + for X.25 [15], but none exists. + + Of course, implicit security labels are also possible in the Network + Layer. 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 the protocol + headers for network layer protocols are themselves small. Small + fixed size network layer protocol headers allow efficient router + implementations. Therefore, when end systems require large security + labels, a higher protocol layer should 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, + because many implementations demultiplex from an system-wide daemon + 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 trusted + demultiplexing. + + Label-based routing/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 to ensure that their addition + does not degrade overall network performance by forcing routers that + do not make label-based routing decisions to parse the security + label. Also, performance will suffer if the addition of security + labels at subnet boundaries induces fragmentation/segmentation. + +5.4 Layer 4, The Transport Layer + + Explicit security labels are possible in the Transport Layer. For + example, the SP4 protocol [10,11] includes them. These labels can be + either connectionless (using SP4E) or connection-oriented (using + 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 in + the SP4 protocol (when explicit labels are not used as discussed + above) is the choice of cryptographic key. + + Security labels in the Transport Layer may be used to meet the + requirements of end systems. The Transport Layer cannot be used to + + + +Housley [Page 9] + +RFC 1457 Security Label Framework for the Internet May 1993 + + + meet the requirements of intermediate systems because intermediate + systems, by definition, do not process protocols above the Network + Layer. Connection-oriented explicit security labels in this layer + are especially good for meeting end system requirements where large + labels are required. The security label is transmitted only at + connection establishment, so overhead is kept to a minimum. Of + course, connectionless transport protocols may not take advantage of + this overhead reduction technique. Yet, in many implementations the + Transport Layer is low enough in the protocol stack to aid trusted + demultiplexing. + +5.5 Layer 5, The Session Layer + + Explicit security labels are possible in the Session Layer. Such + labels could be either connectionless or connection-oriented. + However, it is unlikely that a standard will ever be developed for + 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: 703-790-3767 + EMail: Housley.McLean_CSD@Xerox.COM + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Housley [Page 14] +
\ No newline at end of file |