[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Updated MLS section - "5.4 bis"
IPsec folks,
The following is:
1. A revised version of 5.4-bis that takes into account some comments from
Steve Kent.
2. Steve's comments, with some responses that tie in the the revision.
A reminder for those in the audience, the goal is to make sure that MLS
vendors know that IPsec (in its base form) is there for them, and can be used
w/o _too_much_ additional hassle.
Dan
===================== (Cut up to and including here.) =====================
5.4 Use in Compartmented or Multi-Level Networks
A multi-level secure (MLS) network is one where a single network is
used to communicate data with different sensitivity information labels
(e.g., Unclassified, Company Proprietary, Secret) [DoD85] [DoD87].
The IP security mechanisms can easily support MLS networking. MLS
networking requires the use of strong Mandatory Access Controls (MAC),
which unprivileged users or unprivileged processes are incapable of
controlling or violating [BL73]. This section pertains only to the
use of these IP security mechanisms in MLS environments. Nothing in
this section applies to systems not claiming to provide MLS.
As used in this section, "sensitivity information" might include
implementation-defined hierarchic levels, categories, and/or
releasability information.
The Authentication Header can be used to provide strong assurance
for both mandatory access control decisions in multi-level networks
and discretionary access control decisions in all kinds of networks.
If explicit IP sensitivity information (e.g., IPSO [Ken91]) is used
and confidentiality is not considered necessary within the particular
operational environment, the Authentication Header can be used to
provide authentication for the entire packet, including cryptographic
binding of the sensitivity information to the IP header and user data.
This is a significant improvement over labeled IPv4 networks where the
sensitivity information is trusted even though there is no
authentication or cryptographic binding of the information to the IP
header and user data. IPv4 networks might or might not use explicit
labelling. IPv6 will normally use implicit sensitivity information
that is part of the IPsec Security Association but not transmitted
with each packet instead of using explicit sensitivity information.
All explicit IP sensitivity information MUST be authenticated using
either ESP, AH, or both.
Encryption is useful and can be desirable even when all of the hosts are
within a protected environment, for example, behind a firewall or disjoint
from any external connectivity. The Internet-standard encryption
algorithm could be used, in conjunction with appropriate key management,
to provide strong Discretionary Access Controls (DAC). Key management
could use sensitivity information to provide Mandatory Access Controls
(MAC). Some environments, depending on their local policy, might consider
the Internet-standard encryption algorithm sufficiently strong to provide
MAC. IPsec implementations on systems claiming to provide MLS SHOULD be
capable of using IPsec to provide MAC for IP-based communications.
5.4.1 Relationship Between Security Associations and Data Sensitivity
Both the Encapsulating Security Payload and the Authentication Header
could be combined with appropriate Security Association policies to
provide multi-level secure networking. In this case each SA (or SA
bundle) is normally used for only a single instance of sensitivity
information. For example, "PROPRIETARY - Internet Engineering" must
be associated with a different SA (or SA bundle) from "PROPRIETARY -
Finance".
5.4.2 Sensitivity Consistency Checking
An MLS implementation (both host and router) MAY associate sensitivity
information, or a range of sensitivity information with an interface,
or a configured IP address with its associated prefix (the latter is
sometimes referred to as a logical interface, or an interface alias).
If such properties exist, an implementation SHOULD compare the
sensitivity information associated with the packet against the
sensitivity information associated with the interface or
address/prefix from which the packet will arrive, or to which the
packet will depart. This check will either verify that the
sensitivities match, or that the packet's sensitivity falls within the
range of the interface or address/prefix.
The checking SHOULD be done on both inbound and outbound processing.
5.4.3 Additional MLS Attributes for Security Association Databases
Section 4.4 details three Security Association databases. The first
two, the Security Policy Database (SPD) and the Security Association
Map (SAM), are used primarily for outbound traffic, though the SPD is
also consulted after IPsec inbound processing, but before the IP
datagram is passed to an application or forwarding engine. Both the
SPD and the SAM use common selectors. MLS networking introduces an
additional selector:
- Sensitivity information.
The Sensitivity information aids in selecting the appropriate
algorithms and key strength, so that the traffic gets a level of
protection appropriate to its importance or sensitivity as described
in section 5.4.1. The exact syntax of the sensitivity information is
implementation defined.
The third database is the Security Association Database (SAD). One
additional SAD attribute is:
- Sensitivity information.
Sensitivity information is needed in the model shown in [BL73].
5.4.4 Additional Inbound Processing Steps for MLS Networking
After an inbound packet has passed through IPsec processing, an MLS
implementation SHOULD first check the packet's sensitivity (as defined
by the SA (or SA bundle) used for the packet) with the interface or
address/prefix as described in section 5.4.2 before delivering the
datagram to an upper-layer protocol.
The MLS system MUST retain the binding between the data received in
an IPsec protected packet and the sensitivity information in the SA
or SAs used for processing, so appropriate policy decisions can be
made when delivering the datagram to an application or forwarding
engine. The means for maintaining this binding are implementation
specific.
5.4.5 Additional Outbound Processing Steps for MLS Networking
An MLS implementation of IPsec MUST perform two additional checks
besides the normal steps detailed in section X.Y.Z. When consulting
the SPD or the SAM to find an outbound security association, the MLS
implementation MUST use the sensitivity of the data to select an
appropriate outbound SA or SA bundle. The second check comes before
forwarding the packet out to its destination, and is the sensitivity
consistency checking described in section 5.4.2.
5.4.6 Additional MLS Processing for Security Gateways
An MLS security gateway MUST follow the previously mentioned
inbound and outbound processing rules as well as perform some
additional processing specific to the intermediate protection of
packets in an MLS environment.
A security gateway MAY act as an outbound proxy for creating SAs for
MLS systems that originate packets forwarded by the gateway. These
MLS systems may explicitly label the packets to be forwarded, or the
whole originating network may have sensitivity characteristics
associated with it. The security gateway MUST create and use
appropriate SAs for AH, ESP, or both, to protect such traffic it
forwards.
Similarly such a gateway SHOULD accept and process inbound AH and or
ESP packets and forward appropriately, using explicit packet
labeling, or relying on the sensitivity characteristics of the
destination network.
REFERENCES
[BL73] Bell, D.E. & LaPadula, L.J., "Secure Computer Systems:
Mathematical Foundations and Model", Technical Report
M74-244, The MITRE Corporation, Bedford, MA, May 1973.
[Ken91] Kent, S., "US DoD Security Options for the Internet Protocol",
RFC 1108, BBN Communications, November 1991.
===================== (Cut up to and including here.) =====================
And now, for Steve's comments (> IN CAPS AND QUOTED WITH '>') and Dan's
replies ( Tabbed in):
5.4 Use in Compartmented or Multi-Level Networks
> MAKES IT SOUND LIKE SUCH CONTROLS ARE UNMANAGEABLE! REWORD TO BETTER
> EXPRESS THE NOTION THAT MAC PREVENTS TROJAN HORSES FROM VIOLATING THE
> CONTROLS ....
I think I just fixed this by mentioning that _unprivileged_
users/processes are denied access.
> The Authentication Header can be used to provide strong authentication
> among hosts (OR NETS) in a single-level network. (TRUE, BUT NOT SO
> RELEVANT TO THIS DISCUSSION, RIGHGT?
Removed.
> BE MORE EXPLICIT ABOUT THE DAC TIE-IN, I.E., AH AUTHENTICATES THE SENDER ID
> AND THUS SUPPORTS DAC. ALSO, THE MAC SUPPORT ARISES ONLY IN CONJUNCTION
> WITH THE USE OF LABELS, RIGHT? THE COMMENT ABOUT "STRONG ASSURANCE" IS NOT
> JUSTIFIED HERE; JUST USING AH DOES NOT SAY ANYTHING ABOUT THE LEVEL OF
> ASSURANCE.
MAC support can be implicit with the Security Association information
itself.
> Some environments might
> consider the Internet-standard encryption algorithm sufficiently
> strong to provide Mandatory Access Controls (MAC). (THIS SORT OF
> STATEMENT IS OUTSIDE THE SCOPE OF IPSEC; IT IS A DECISION FOR DOD
> POLICY MAKERS, NOT AN IETF WG.)
Put in "dependent on their local policy". This is also for the
word "might". You're right, we don't dictate policy.
By the way, MLS =!=> DoD. MLS boxes are used by commercial customers
too.
5.4.1 Relationship Between Security Associations and Data Sensitivity
> Both the Encapsulating Security Payload and the Authentication Header
> can be combined with appropriate Security Association policies to
> provide full multi-level secure networking. (WELL, WE CAN MAP SAs
> WELL, WE CAN MAP SAs
> APPROPRIATELY IN AN MLS NETWORK ENVIRONMENT, BUT IT IS NOT AT ALL
> CLEAR THAT COST IPSEC IMPLEMENTATIONS ARE SUITABLE FOR ENFORCING MLS.
We weakened "can" to "could". And any COTS OS needs _some_
modifications to fully enforce MLS, same applies to IPsec.
> For example, "PROPRIETARY - Internet Engineering" must
> be associated with a different SA (or SA bundle) from "PROPRIETARY -
> Finance". (ALTHOUGH THIS IS A REASONABLE MAPPING IT MAY NOT BE
> SUFFICIENT NOR NECESSARY IN ALL INSTANCES.)
That's why it's an example.
5.4.2 Sensitivity Consistency Checking
> (IF THIS APPLIES TO HOSTS AND GATEWAYS, LETS SAY SO EXPLICITLY)
Done.
> The checking SHOULD be done on both inbound and outbound processing.
> (WHY ONLY A SHOULD, INSTEAD OF A MUST? CAN THIS BE TRANALATED INTO A
> CHECK FOR SA LABELS WHEN THEY ARE CREATED, BOUND TO A SPECIFIC
> INTERFACE OR SET OF INTERFACES?)
Because, as you pointed out in a previous bullet, it could be a
matter of local policy.
5.4.3 Additional MLS Attributes for Security Association Databases
> Sensitivity information is needed in the model shown in [BL73].
> (I AGREE WITH THIS TEXT, BUT WE ALSO NEED TO STANDARDIZE THIS INFO AND
> MATCH IT TO THE DATA SENT VIA ISAKMP, SO THAT BOTH ENDS AGREE ON THE
> LABELS USED TO MAP TO THE SA. WHAT HAS BEEN NAILED DOWN FOR ISAKMP?)
Because ISAKMP isn't the only Key Mgmt. out there, we avoided these
questions. Especially in a DoD environment, they may have rolled
something better. This is the IPsec architecture document, which
is deliberately decoupled from Key Mgmt.
5.4.4 Additional Inbound Processing Steps for MLS Networking
> (BUT THE MEANS FOR MAINTAING THIS BINDING ARE OS-SPECIFIC, RIGHT?)
Yep. And it's now noted as such.
5.4.6 Additional MLS Processing for Security Gateways
> ("PERHAPS" SEEMS VAGUE. ...
Yep. We've snipped it out.