Compartmented Mode Workstation Labeling: Encodings Format

Chapter 7 General Considerations for Specifying Encodings

The sections above describe how each section of the encodings file should be specified. However, when specifying an encoding file, there are some important considerations regarding the relationships among entries in the various sections to be kept in mind. This section describes such considerations.

The Minimum Information Label

The minimum possible information label is indirectly specified in the encodings file, and care must be taken to insure that it is well formed. The minimum information label's classification is the lowest specified classification. The minimum information label's compartments equal the initial compartments of the lowest specified classification, but with all inverse compartment bits set to 0. The minimum information label's markings equal the initial markings of the lowest specified classification, but with all inverse marking bits set to 0.

The human-readable form of the minimum information label contains the lowest specified classification along with those default words specified by the initial compartments and/or markings of this classification, but without any inverse words specified by the initial compartments and/or markings.

The Maximum Sensitivity Label

The maximum possible sensitivity label is indirectly specified in the encodings file and care must be taken to insure that it is well formed. The maximum sensitivity label's classification is the highest specified classification. The maximum sensitivity label's compartments contain 1 bits for every compartment bit referenced in any initial compartments= specification or any compartments= specification in the encodings file, and 0 bits for all other bits.

Consistency of Word Specification among Different Types of Labels

Many words must be specified as being components of all three types of labels: information labels, sensitivity labels, and clearances. In fact, in most cases, words that appear in sensitivity labels also appear in clearances and information labels.

(Sometimes the word may have a different name or prefix in a clearance, but has the same meaning as the sensitivity label word because it is associated with the same compartment bits. See Chapter 5, Sensitivity Label, Clearance, Channels, and Printer Banner Encodings for a discussion of why a clearance word might have a different prefix than an otherwise equivalent sensitivity label word. Also, sometimes the word may have a different name in an information label, but has the same meaning as the sensitivity label word because it is associated with the same compartment bits. In other cases, the word may not appear in an information label, but one or more other words that specify the same compartment bit pattern do appear.)

When the same word appears in multiple types of labels, extreme care must be taken to ensure that the words are specified as consistently as possible in each label. In particular, the words should have the same minclass, maxclass, and the same required combinations and combination constraints with respect to combinations with words that also appear in multiple labels. Any inconsistencies may have undesired results.

For example, consider a system that facilitates downgrading the sensitivity label of an object by setting it equal to the classification and compartments of the object's information label. Consider also the encodings in Example 7–1. With these encodings, CONFIDENTIAL A would be a valid information label, and SECRET A B would be a valid sensitivity label, both for the same object. However, if the system's “downgrade sensitivity label to information label classification and compartments” function is performed, the sensitivity label would become CONFIDENTIAL A. Such a sensitivity label is invalid for two reasons: 1) the word A in a sensitivity label has a minimum classification of SECRET, and 2) the word A requires the word B in a sensitivity label. Consistently encoding the word A for both information and sensitivity labels would have avoided this problem.

Example 7–1 Inconsistent encodings example

CLASSIFICATIONS: 
		NAME= CONFIDENTIAL;   SNAME= C; VALUE= 4;
		NAME= SECRET; SNAME= C; VALUE= 5; 

INFORMATION LABELS:
		WORDS:
			NAME= A;   COMPARTMENTS= 2;  MINCLASS= C;
			NAME= B;   COMPARTMENTS= 3;  MINCLASS= C;
		REQUIRED COMBINATIONS: COMBINATION CONSTRAINTS  

SENSITIVITY LABELS:
		WORDS:
		NAME= A;   COMPARTMENTS= 2;  MINCLASS= S;
		NAME= B;   COMPARTMENTS= 3;  MINCLASS= C;
		REQUIRED COMBINATIONS: A  B
		COMBINATION CONSTRAINTS

Mandatory Access Control Considerations When Encoding Words

Before encoding each word, the meaning of the word with respect to national policy must be determined. If national policy dictates that mandatory access control (MAC) must be performed based on the word (which is the case for compartments, subcompartments, SAPs, and SAPIs), or if a policy decision is made to treat a word as a compartment (for example, release markings on which it has been decided to perform MAC, such as REL CNTRY1 and REL CNTRY2 in Appendix B, Annotated Sample Encodings) then the word should be associated with compartment bits in the clearances and sensitivity labels sections of the encodings file, and possibly in the information label section as well. Such a word is called a MAC word. Instead, if the word does not directly enter into MAC decisions, but implies some other word that does, the word would appear only in information labels, be associated with both compartments and markings, and is called a MAC-related word. Finally, if the word has absolutely nothing to do with MAC, the word would appear only in information labels, be associated with only markings, and be called a non-MAC word.

Encoding MAC Words

As mentioned above, words on which mandatory access control must be performed must be associated with compartment bits, and must appear in the CLEARANCES: and SENSITIVITY LABELS: sections, and possibly in the CHANNELS:, PRINTER BANNERS:, and INFORMATION LABELS: sections. The word would appear in the CHANNELS: section if the word represents a handling channel. The word would appear in the PRINTER BANNERS: section if the word requires any special printer banner marking other than a handling channel caveat. The word would appear in the INFORMATION LABELS: section if it is desired that the word appear in information labels. It is conceivable that a mandatory access control word not appear in information labels, but that a codeword that implies the word could appear instead.

When encoded in the clearances:, sensitivity labels:, channels: and PRINTER BANNERS: sections, a mandatory access control word would be associated with only compartment bits. When encoded in the INFORMATION LABELS: section, the word could have associated both compartment and marking bits.

Consider the word A in Appendix B, Annotated Sample Encodings. This word, which appears with the name A in the clearances: and sensitivity labels: sections and the name (CH A) in the channels: section, is associated with compartment bit 0 being 1. Note that the word A in the information labels: section is also associated with compartment bit 0 being 1, but additionally has a marking bit associated, for a reason discussed below.

Some words that represent compartments, and would typically be expected to have only compartment bits associated, nonetheless require association with marking bits in information labels to establish a hierarchy with other information label words. In the INFORMATION LABELS: section, A has marking bit 7 associated. The purpose of marking bit 7 in the specification of A is to establish a hierarchy with A above WNINTEL (which is associated only with marking bit 7). The reason for this hierarchy is that the word WNINTEL was deemed unnecessary along with any word that directly represents or implies a compartment. The hierarchy prevents WNINTEL from appearing in a label with any such word.

Encoding MAC-Related Words

Words that are not directly used for MAC, yet imply the presence of a compartment or other MAC word, are encoded in the information labels: section using both compartment and marking bits. This situation typically occurs when there are multiple words, sometimes called codewords, associated with a compartment. In such a case, users are cleared for the compartment as a whole, not for the individual codewords. However, the presence of the codeword in an information label implies that the data is in the compartment. In such a case, the codeword must have a compartment bit associated to identify the compartment, but must additionally have one or more marking bits associated to distinguish the word as a codeword (as opposed to a MAC word) and to differentiate among the multiple codewords. An example of this case appears in Appendix B, Annotated Sample Encodings with the words alpha1, alpha2, and alpha3. All three words are associated with compartment bit 0 (and hence the compartment A), but additionally have marking bits associated. This particular pattern of marking bits determines which of the three codewords are present.

It is also possible to encode MAC-related words in the PRINTER BANNERS: section if desired. There is no such example in Appendix B, Annotated Sample Encodings.

Encoding Non-MAC-Related Words

Words having nothing to do with MAC, either directly as compartments or indirectly as codewords, are encoded in the information labels: section using only marking bits. In Appendix B, Annotated Sample Encodings, the word WNINTEL is such a word.

It is also possible to encode non-MAC-related words in the PRINTER BANNERS: section if desired. There is no such example in Appendix B, Annotated Sample Encodings.

Using Initial Compartments and Markings to Specify Inverse Compartment and Marking Bits

The intended usage of the initial compartments and initial markings specifications when used to specify inverse compartment or marking bits is described below. Potentially, the initial compartments and initial markings keywords can be used more flexibly than described below, but any such usage should be very carefully scrutinized to determine that the desired security and labeling properties are represented.

The intended usage is described below in terms of inverse words of the form REL XX, whose meaning is that data associated with the word is releasable to XX, where XX could represent a country, an organizational affiliation, or even a person.

It is often true that data of the lowest classification (or possibly classifications) is always releasable without restrictions. Therefore, the internal format of labels with the lowest classification would specify that all such REL XX words be logically present. Having these words present means that their associated bits should be 0. Therefore, it is not necessary to specify these inverse bits as initial compartments or markings in the lowest classification.
For classifications greater than the lowest, it would therefore typically follow that the bits associated with the REL XX words should be 1, because data whose label is one of these classifications standing alone is not releasable. Therefore, the same initial compartments (representing inverse bits)—if any—are intended to be specified for all classification values other than the lowest, and the same initial markings (representing inverse bits)—if any—are intended to be specified for all classification values other than the lowest.
When allocating compartment and marking bits, careful consideration must be given to deciding how many inverse bits should ever be needed throughout the life of the system. All inverse bits ever anticipated to be used on the system should be specified in the initial compartments and markings specifications even if they are not used initially for any marking words in the encodings. The best way to describe why this preallocation of inverse bits is necessary is to show what happens if inverse bits are not preallocated. Assume that marking bit 11 is encoded as an inverse bit whose meaning is REL CNTRY3 (as specified in Appendix B, Annotated Sample Encodings). Further assume that there are no other inverse marking bits and that marking bit 12 is assigned no meaning. Since marking bit 11 is the only inverse marking bit, the initial markings specification would be:
```
initial markings= 11;
```
If the system was used with the encoding file in this condition, a large number of information labels would be stored on the system (and on backup tapes) with marking bit 12 (and all other unused bits) having the value 0. Then, if it is later decided that REL CNTRY4 must be encoded using an inverse marking bit and bit 12 (or any other unused bit) is chosen, then all data previously stored on the system would automatically be treated as REL CNTRY4 because that would be the meaning of marking bit 12 being 0. Of course, all of the data would not be releasable to CNTRY4, such that all data on the system (and on backup tapes) would have to be relabeled. Therefore, it is best to preallocate some range of bits as inverse bits when the encodings file for a system is first loaded. Then, preallocated unused inverse bits can be later assigned meaning without the need to relabel.

Note that the above discussion covers the simplest and most common usage of inverse bits. More complex usage of inverse bits is possible, and needed in some instances. As an example, see the hypothetical bravo4 codeword in Appendix B, Annotated Sample Encodings.

Using Prefixes to Specify Special Inverse Compartment and Marking Bits

The intended usage of prefix words that specify compartments or markings is to specify special inverse bits that allow special inverse words. Special inverse words are words that specify a prefix that in turn specifies compartments or markings. The intended purpose and usage of special inverse bits and special inverse words is best described by the example below.

Special inverse words can be used to implement the ORiginator CONtrolled (ORCON) handling caveat with organizations to which the ORCON data can be released specified in the label. For example, given that three organizations use a particular system (ORG1, ORG@, and ORG3), the encodings to handle ORCON for these three organizations might look as follows. Only the SENSITIVITY LABELS words are shown in this example.

SENSITIVITY LABELS:
		WORDS:
		name=ORCON RELEASABLE TO; sname=OR; compartments=1-4;
		prefix;
		name=ORCON; minclass=C; compartments=1-4;
		name=ORG1; minclass=C; compartments=~1 4; prefix=OR;
		name=ORG2 minclass=C; compartments=~2 4; prefix=OR;
		name=ORG3; minclass=C; compartments=~3 4; prefix=OR;

In this example, ORG1, ORG2, and ORG3 are special inverse words, each of which requires the prefix ORCON RELEASABLE TO. This prefix specifies compartments bits 1-4, which are therefore special inverse bits. Bit one is for ORG1, bit 2 for ORG2, bit 3 for ORG3, and bit 4 has meaning of ORCON. If only ORCON RELEASABLE TO ORG1 is present in a label, then bit 1 would be off, and bits 2-4 would be on. If only ORG1 is present in a label, then bit 1 would be off, and bits 2-4 would be on. If only ORCON RELEASABLE TO ORG2 is present in a label, then bit 2 would be off, and bits 1, 3, and 4 would be on. If only ORCON RELEASABLE TO ORG3 is present in a label, then bit 3 would be off, and bits 1, 2, and 4 would be on. If ORCON RELEASABLE TO ORG1/ORG2 is present in a label, then bits 1 and 2 would be off and bits 3 and 4 would be on, and so on. The word ORCON, which dominates the three other words, is not an inverse word. If it appears in a label, the data so labeled is not releasable to any of the three organizations.

Note that a label that does not contain any of the above words has bits 1-3 off and is therefore releasable to all organizations, and has bit 4 off and is therefore not ORCON data. Thus, with the same words as above for information labels, data with an information label of SECRET ORCON RELEASABLE TO ORG1 when combined with data with an information label of TOP SECRET, would become TOP SECRET ORCON RELEASEABLE TO ORG1. Special inverse words can be specified using markings bits also.

Unlike regular inverse bits, special inverse bits should not be preallocated to allow for future usage. Special inverse bits can be safely added to a running system without preplanning.

Choosing Names

The names chosen in the classifications:, information labels:, sensitivity labels:, and clearances: sections are extremely important. In general, it is best if all short and long names within each of the above sections are unique. However, because of the way prefix and suffix words are handled by the system, there are two exceptions to this general rule.

A suffix and a non-prefix/non-suffix word can have the same name. This is possible because you can look at labels with both such names and tell them apart. For example, consider suffix SF, word W that requires suffix SF, and regular word SF. The label TS SF contains the regular word SF, because there is no word that requires the suffix SF preceding the SF. The label TS W SF contains the suffix SF, because the word W immediately precedes the SF. Finally, the label TS SF W SF contains both the regular word SF and the suffix SF.
A word that requires a prefix and a non-prefix/non-suffix word can have the same name, as long as the non-prefix/non-suffix word is specified before the word that requires the prefix. This is possible because you can look at labels with both such names and tell them apart. For example, consider word W that requires prefix P, and regular word W. The label TS W contains the regular word W, because there is no prefix before the W. The label TS P W contains the word W that requires the prefix P, because the prefix is present. Finally, the label TS W P W contains both the regular word W and the prefix-requiring word W.

Obviously, use of either of these exceptions should be avoided if at all possible because of the probable confusion that will occur.

There are two additional considerations in specifying names.

Classification names should never be the same as information label, sensitivity label, or clearance names.
If the same name appears in both the sensitivity labels: and clearances: sections, the words with this name should refer to the same compartment, and should therefore have an identical specification in the encodings file.

Specifying Aliases

A word in the information label, sensitivity label, or clearance sections whose specified compartment or marking bits include all of the bits of one or more words above in the encodings is called an alias. The simplest case of an alias is a word that duplicates the compartment and marking bit specifications of the word above it. Such an alias—in effect—simply adds more names to the word above it. The word WARNING in Appendix B, Annotated Sample Encodings is such an alias for the word WNINTEL. Using an input name (iname=) is the preferred method of associating more than two names with a word. See The Iname= Keyword in Chapter 4, Information Label Encodings.

A more complex type of alias is a word whose compartment and/or marking bits includes bits specified in multiple words that appear above it. The word SYSHI in Appendix B, Annotated Sample Encodings is an example of this type of alias. Entering SYSHI is the same as entering the following words from Appendix B, Annotated Sample Encodings: CC SB bravo1 bravo3 SA alpha1 project X/project Y LIMDIS ORCON org x/org Y D/E all eyes NOFORN.

Aliases can be used while entering labels or adding to labels (e.g., by entering +alias to add alias to an existing label), but cannot be used for removing words from labels (e.g., by entering -alias to remove alias from an existing label) and will never appear in output labels (assuming the alias and the words being aliased have the same flags= specification). For example, given the above alias WARNING for the word WNINTEL, the following table shows how the label TOP SECRET can and cannot be modified using the alias.

Table 7–1 Modifying With Alias


LABEL	TYPED CHANGE	COMMENTS
TOP SECRET	+WARNING	Alias added to existing label; aliased word (WNINTEL) will appear in label instead of alias itself
TOP SECRET WNINTEL	-WARNING	Produces an error because “WARNING” is not in the label
TOP SECRET WNINTEL	-WNINTEL	Aliased word will be removed
TOP SECRET		Aliased word was removed

Alias words can be combined with flags to produce aliases that can optionally be used in output labels. The system does not use the flags feature, but applications can be specifically written to use this feature. As an example, consider the case where you have a word that normally appears as NORMAL NAME, but that must, under certain conditions, appear in labels as ALTERNATE NAME. This could be accomplished with the following encodings:

name= NORMAL NAME; markings= 34;  
name= ALTERNATE NAME; markings= 34; flags= 1;

Under normal circumstances NORMAL NAME would appear in labels, but if the translation software is explicitly told to use only words with flag 1, then ALTERNATE NAME would appear in labels. See [DDS-2600-6215-91] for information on how applications can use the flags feature in this manner.

Avoiding “Loops” In Required Combinations

Extreme care must be taken in specifying required combinations to ensure that there are no “loops” in the specifications. A “loop” occurs when, through a series of required combination specifications, a word requires itself. The simplest case of a loop is:

A B
B A

whereby word A requires word B, which in turn requires word A. Such a specification makes no sense. If words A and B must always appear together, why are they encoded as separate words? A more complex case of a loop occurs in the following specification:

A B
B C
C A

whereby word A requires word B, which in turn requires word C, which in turn requires word A.

Visibility Restrictions for Required Combinations

The fact that information labels must be dominated by their associated sensitivity label, and that sensitivity labels specified by a user must be dominated by that user's clearance, places some constraints on what words can be added to certain labels. For example, if adding a word to an information label raises the information label such that it is no longer dominated by the associated sensitivity label, then that word is not visible in the information label. Similarly, if adding a word to a sensitivity label raises the sensitivity of the label such that it is no longer dominated by the associated user's clearance, then that word is not visible in the sensitivity label.

It is important that any word required by another word in a required combination be visible whenever the requiring word is visible. For example, given the required combination:

A B

which means A requires B, word B must be visible whenever word A is visible. If B were not visible at some point when A was visible, a situation could occur whereby A could legally be added to a label, were it not for the fact that doing so would require also adding B, which would violate a dominance relationship. Such a situation must be prevented by careful construction of required combinations. There are no restrictions on required combinations of words with only marking bits (i.e., no compartment bits) associated, because marking bits do not participate in the dominance relationships mentioned above.

One practical ramification of this restriction is that 1) sensitivity label required combinations should not be more restrictive than the equivalent clearance restrictions, and that 2) information label required combinations should not be more restrictive than the equivalent sensitivity label restrictions. A concrete example of this problem can be taken from the sample encodings in Appendix B, Annotated Sample Encodings.

Consider the SA and CC compartments in the CLEARANCES: and SENSITIVITY LABELS: encodings. The REQUIRED COMBINATIONS: in both of these sections are:

SB B
SA A

Now, consider the same where an additional required combination is added to only the SENSITIVITY LABELS: encodings:

SA CC

This additional required combination, which makes the sensitivity label required combinations more restrictive than those for clearances, specifies that if SA is present in a sensitivity label, CC must also be present. Now consider the case of a user with the clearance TS A B SA SB. Such a clearance is perfectly valid according to the encodings, but such a user can never put SA in a sensitivity label because SA requires CC, yet the user is not cleared for CC.

Relationships between Required Combinations and Combination Constraints

It is possible for a valid required combination, when combined with a valid combination constraint, to yield an anomalous situation. Consider the required combination:

A B

combined with the combination constraint:

A ! B

These specifications say that word A requires word B, yet words A and B cannot be combined. Such contradictory specifications must be avoided.

Restrictions on Specifying Information Label Combination Constraints

Information label combination constraints are used by the labeling software to ensure that no invalid combinations of words are allowed to be specified in a single information label. However, any two valid information labels can be combined by the system by bitwise or-ing the compartment and marking bits. Thus if a combination constraint is specified that (using examples from Appendix B, Annotated Sample Encodings) subcompartment SA and subcompartment SB cannot be combined, an inconsistent situation has arisen. The inconsistency is that SA and SB cannot be combined by entering them in a single information label, yet two separate information labels, each with one of the subcompartments, can be combined to produce a new information label with both subcompartments. Therefore, to avoid such inconsistencies, you should never specify any combination constraints that are not automatically enforced on combinations by the encodings.

Examples of constraints automatically enforced on combinations by the encodings abound when considering inverse words. If two inverse words IW1 and IW2 are constrained not to be combined with the combination constraint:

IW1 ! IW2

then you can be assured that IW1 and IW2 can never be put together as a result of the combination of two labels. Why? Because inverse words combine by having only those inverse words in both of the labels being combined appear in the resulting label. Therefore, if both IW1 and IW2 cannot appear in any single information label, then no combination of information labels can combine IW1 and IW2 together.

Thus, you can be assured of avoiding inconsistencies if only inverse words are used in ! constraints and in the left hand side of & constraints.

Modifying Encodings Already Used by the System

Extreme care must be taken when modifying an encodings file that has already been loaded and run on a CMW system. The reason for concern is the fact that once the system has run with the encodings, many objects will become labeled with sensitivity labels and information labels that are well formed with respect to the encodings loaded. If the encodings are subsequently changed, it is possible that the existing labels will no longer be well formed unless care is taken. Changing the bit patterns associated with words will cause existing objects whose labels contain the words to have possibly invalid labels. Raising the minimum classification or lowering the maximum classification associated with words will likely cause existing objects whose labels contain the words to no longer be well formed.

Therefore, changes to encodings that have already been used should generally be limited to adding new classifications or words, or changing the names of existing words only. However, as described above, it is important to reserve extra inverse bits when the encodings file is first created to allow for later expansion of the encodings to incorporate new inverse words. If an inverse word is added not using reserved inverse bits, all existing objects on the system will erroneously have labels that include the new inverse word.

Consistency of Default Word Specification

A default word is a word whose presence is specified by the initial compartments and initial markings associated with a classification value. In other words, a default word appears in all labels containing the classification(s) whose initial compartments and markings specify the presence of the word.

As with all other words, an output minimum classification can be specified (ominclass=) with a default word, in which case the word will appear in human-readable labels at or above the output minimum classification only. Also, a minimum classification can be specified (minclass=) with a default word, as long as the minimum classification is less than or equal to each classification for which the word is default. For example, the following encodings would be in error.

CLASSIFICATIONS:

name= SECRET; sname= S; value= 5; initial markings= 3;

name= TOP SECRET; sname= TS; value= 6; initial markings= 3;

INFORMATION LABELS:

		WORDS:

		name= word1;  markings= 3;  minclass= TS;

The error is that word1 is a default word for the classification SECRET, but has a minimum classification of TOP SECRET, which is greater than SECRET.

Care must be taken in the specification of default words to ensure consistency between the default words specified and any combination constraints involving a default word. If a combination constraint prevents a default word from being combined with a second word, then the second word should not be specified as a default word for the same classifications for which the first word is default. For example, the following encodings would be in error.

CLASSIFICATIONS:

name= SECRET; sname= S; value= 5; initial markings= 3 4;

INFORMATION LABELS:

		WORDS:

		name= word1;  markings= 3; 

		name= word2;  markings= 4;

		REQUIRED COMBINATIONS:

		COMBINATION CONSTRAINTS:

		word1 ! word2

The error is that word1 and word2 are both default words, but are constrained not to be combined together.