[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: MLS Security Associations, etc.
On Mar 17, 9:16, Andy Bayerl wrote:
} Subject: Re: Routing
% I think Dean was using yet a 3rd meaning to MAC which is very familiar
% to the MLS CMW world, namely "Mandatory Access Control", which refers
% to using sensitivity labels to strictly control access to data. The
% security architecture document itself refers to *MAC* in that context:
Yes, I also think that Dean Throop was using MAC in that manner.
Perhaps it would be less confusing if none of us used the abbreviation
"MAC" in email on this list since there are several possible meanings ?
5.5 USE IN COMPARTMENTED OR MULTI-LEVEL NETWORKS
A multi-level secure (MLS) network is one where a single network is
used to communicate data at different sensitivity levels (e.g.
Unclassified and Secret). Many governments have significant interest
in MLS networking. [DIA] The IPv6 security mechanisms have been
designed to support MLS networking. MLS networking requires the use
of strong Mandatory Access Controls (MAC) which ordinary users are
incapable of controlling or violating. Mandatory Access Controls
differ from Discretionary Access Controls in this respect.
% There is a paragraph in there that I think may have Dean (and I also)
% to infer that the document implied overloading the SAID with *MAC*
The Encapsulating Security Payload can be combined with appropriate
key policies to provide full multi-level secure networking. In this
case each key must be used only at a single sensitivity level and
compartment. For example, Key "A" might be used only for sensitive
Unclassified packets, while Key "B" is used only for
Secret/No-compartments traffic, and Key "C" is used only for
% I (at least) had equated the *key* in this paragraph to the SAID.
The _combination_ of SAID and Destination Address _does_ imply a
particular single key that is in use for that traffic. The SAID
does not "equate" to the key, but it is "related" to the key.
% From Ran's comments on the subject and a closer rereading of the this
% section I believe I now understand it much more clearly in the sense
% that is strictly referring to the authentication strength of the key
% and is not in any way related to the *MAC* dominance rules of CMW
% sensitivity labels.
Not exactly. The "not in any way related" part is incorrect. They
are related, but are not equal.
One has a "Security Association" which is uniquely determined by the
pair of SAID and Destination Address. A Security Association has
a number of different parameters. In an MLS environment, one of those
parameters is the highest sensitivity level of traffic that uses that
Under normal circumstances if one has SECRET traffic, then one will
use a "Security Association" which has a security level of SECRET and
one will use a SECRET-level key. In that case, the combination of
SAID and Destination Address _does_ imply a security level of SECRET.
In an MLS environment, One MUST NOT use a key having a lower
security level (e.g. SECRET) to protect higher security level traffic
(e.g. TOP SECRET). That relation could be expressed by saying that
the sensitivity level of the traffic MUST NOT dominate the sensitivity
level of the key.
If one were to have a single multi-level session, then the
applicable "Security Association" would have a key for the _highest_
level of traffic permitted in that session and that "Security
Association" would have an associated sensitivity level that was equal
to the highest possible level of that session. To give a specific
example, one might have a "Security Association" that was TOP SECRET,
a key that was TOP SECRET, and traffic ranging from SECRET to TOP
SECRET (inclusive). A better approach to this example would be to use
_2_ Security Associations, one at SECRET and another at TOP SECRET.
In this better approach, outgoing traffic would select the lowest
sensitivity level Security Association that dominated the sensitivity
level of the traffic. As a practical matter, implementations might
choose to ignore horizontal compartments when dealing with Security
Associations because the number of compartments can be very large and
the management of Security Associations could become unwieldy if
horizontal compartments had to be taken into consideration all the
If the current text is unclear in this area, I'm happy to try to
clean it up. Folks outside the MLS world need not be worried. The
current specification language clearly indicates that the MLS text
only applies to systems which claim to provide MLS capabilities. The
MLS text does need to be there to ensure interoperability and correct
implementation of ESP/AH within such MLS-capable systems. Some MLS
work (e.g. RFC-1108 IPSO) has been done within the IETF and MLS
discussions have been occurring within IPsec since its beginning, so
this is clearly within scope for the IPsec WG.