[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

SAs and SPIs

        This is in response to Ran Atkinson's comments on my SA-SPI note.
First, I did not propose a specific change in the DOI standard. I was simply
adding some information concerning security categories and their usage.
Further, I specifically said I appreciate the need to "crash out" current
drafts.  At this point in time people will almost surely a) support their
software even if it is clear improvements might be made, and, b) resist any
change that might invoke a delay. We are all hoping the IPSEC will be a big
success and the e-mail comments I have seen tend to be constructive.  IPSEC
is building on TCP/IP in support of which I played an early (and I'd like to
think important) role when its use was hotly contested.  Given the
information in the note I wrote plus what follows, the author(s) of the DOI
standard are on their own. 

        First, to make what follows easier to read, let me mention that in
an earlier SA-SPI note I pointed out that "Security Categories" are of two
types "Release Categories" and "Restrictive" or "Compartment" categories and
that these are different. I also pointed out that both can be readily
represented in bit maps but that operating procedures for both are different
and so programs must know which is being processed. I further pointed out
that the DOI has a single field called Security Categories in which either
type of category could be placed (or both) and that this might lead to
problems if implementers used different strategies. Now, in Ran Atkinson's
note he seems to acknowledge the existence of both types of category but
called the release category a "rat's nest" which can be endlessly discussed.
This is, of course, his opinion: no supporting evidence is given, so I have
written the following short response to Ran in defense of "Release
Categories" and their associated "Release Markings." 

        The current IEEE (802) LAN security standard has both Release
Categories and Compartment (Restrictive) Categories in separate fields as
does the National Institute for Standards and Technology "Security Label for
Information Transfer  (FIPS PUB 188.)  The US Government Military Standard
also has both Release and Compartment (Restrictive) categories in separate
fields, as does the CIPSO. There appears to be no standard with one and not
with the other. The new US Government Orders and the new US Security
Directives have very explicit Release Categories (markings), as did earlier
versions.  There are hundreds of thousands (and probably millions) of
documents around bearing release markings and these regularly traverse
networks. Like it or not, companies continue to release information to
specific subcontractors, and, for example, Biotechs and Pharmaceuticals
continue to release specific test results to the FDA.  Further, Release
Markings and the Release Category are probably easier to understand and use
than compartment markings.  We simply release to whomever we think
appropriate.  "Release to Canada" and "Release to France" seem logically
straightforward as do "Release to Biogen" and "Release to FDA."

        Finally, let me again note that the current DOI has a single field
containing security "categories."  It does not specify which kind of
category, leaving implementers to do as they will with the bit map, using it
for either type of category, or for both.  This could lead to compatibility
problems or possible misuse of the field. Since there are so many standards
containing both and so many users who are familiar with two category types,
this possibility seems real. This may not be the time to decide on a fix
because of the obvious short-term software protective problems, but I think
the subject should clearly be discussed for further versions.   

        The above is intended as informative and is hopefully useful. It
does not contain a specific proposal. As Jack Webb often said "Just the
facts, Mam."