dpowles@CCD.BBN.COM ("Drew M. Powles") (12/18/87)
Can someone please refresh my memory? What is the status of the basic and extended IP security options verses the single security option in the standard? Have these options been adopted yet? Has the spec on them been turned into an RFC yet? If not, when will some of these things happen, if ever? Thanks for the help! dmp
jkrey@VENERA.ISI.EDU (12/22/87)
Drew, Mike St. Johns' "Draft Revised IP Security Option" is about ready to be issued as an RFC, as soon as Mike provides us with additional information he wanted to include at the end of the document.
smb@ulysses.homer.nj.att.com (Steven Bellovin) (12/23/87)
Understanding the IP security option requires an understanding of the military computer security model, as outlined in the ``Orange Book''. What follows is a somewhat-simplified version of the model. All objects in the computer system, such as files or network channels, and all data exported from them, must have a label indicating the sensitivity of the information in them. This label includes hierarchical components (i.e., Confidential, Secret, and Top Secret) and non-hierarchical components. Subjects -- i.e., processes within the computer system -- are similarly labeled. A subject may read an object if its label has a higher or equal hierarchical level and if all of the object's non-hierarchical components are included in the subject's label. In other words, the process must have sufficient clearance for the information in a file. Similarly, a subject may write to an object if the object has a higher or equal level and the object's non-hierarchical components include all of those in the subject's level. That is, the sensitivity level of the file must be at least as high as that of the process. If it were not, a program with a high clearance could write classified data to a file that is readable by a process with a low security clearance. A corollary to this is that for read/write access to any file, its security label must exactly match that of the process. The same applies to any form of bidirectional interprocess communication (i.e., a TCP virtual circuit): both ends must have identical labels. We can now see how to apply this model to the TCP/IP protocol suite. When a process creates a TCP connection, that connection is given the process's label. This label is encoded in the IP security option. The remote TCP must ensure that the label on received packets matches that of the receiving process. Servers awaiting connections may be eligible to run at multiple levels; when the connection is instantiated, however, the process must be forced to the level of the connection request packet. IP also makes use of the security option. A packet may not be sent over a link with a lower clearance level. If a link is rated for Secret traffic, it may carry Unclassified or Confidential traffic, but it may not carry Top Secret data. Thus, the security option constrains routing decisions. The security level of a link depends on its inherent characteristics, the strength of any encryption algorithms used, the security levels of the hosts on that network, and even the location of the facility. For example, an Ethernet cable located in a submarine is much more secure than if the same cable were running down a deserted hallway. It is obvious from this description that the IP security option is not easily used in civilian environments. The entire strength of the scheme depends on the reliability of the security labels attached to processes; if the system does not maintain such labels -- and most UNIX systems do not -- the IP security option cannot be used.