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

Proposed MLS section - "5.4 bis"

Hello!

The following proposed text consolidates and clarifies Multi-Level
Secure (MLS)-specific text for the IP Security Architecture document.
It is the output of a small team which met here at Sun on 10/16/97.

Contrary to popular belief, MLS systems have significant deployment in
the commercial sector (including Banking and Health Care).  Members of
this team include IPsec and MLS OS implementors from various commercial
firms and the US DoD.  The members of the team reached smooth consensus
on the following text, which is designed to be a standalone section in
the IP Security Architecture document.  The text is based on section 5.4
of RFC 1825, hence the name "5.4 bis".  It is intended to show IPsec's
extensibility into MLS domains, without constraining the work that will
be needed to fully integrate IPsec into an MLS environment.  None of the
following text applies to non-MLS systems, so anyone who is NOT doing an
MLS implementation does not have to concern {him,her}self with the points
raised below.

Thanks!  (NOTE:  All names are in first-name alphabetical order.)

THE TEAM (* == co-authors at the 10/16 meeting)
===============================================
C. S. Lin (csl@cup.hp.com)
* Dan McDonald (danmcd@eng.sun.com)
* David Kemp (dpkemp@missi.ncsc.mil)
Doug Hosking (???@cup.hp.com)
* Gary Winiger (gww@ebay.sun.com)
Gary Lowell (glowell@engr.sgi.com)
* Mohan Parthasarathy (mohanp@eng.sun.com)
* Matt Thomas (matt.thomas@altavista-software.com)
* Ran Atkinson (rja@inet.org)

p.s. Please send replies to the list and/or to all of the authors.  I ask
     this because I will be virtually incommunicado for the next week.

===================== (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
   (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 ordinary users 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 sensitivity levels, categories, and/or
   releasability information.

   The Authentication Header can be used to provide strong authentication
   among hosts in a single-level network.  The Authentication Header can also
   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 is 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 it is not trustworthy because 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 very useful and desirable even when all of the hosts
   are within a protected environment.  The Internet-standard encryption
   algorithm could be used, in conjunction with appropriate key
   management, to provide strong Discretionary Access Controls (DAC) in
   conjunction with either implicit or explicit sensitivity information
   (such as IPSO provides for IPv4 [Ken91]). Some environments might
   consider the Internet-standard encryption algorithm sufficiently
   strong to provide Mandatory Access Controls (MAC).  Full encryption
   SHOULD be used for all communications between multi-level computers
   or compartmented mode workstations even when the computing
   environment is considered to be protected.

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.  In this case each SA (or
   SA bundle) MUST be 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 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 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.

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
   perhaps the whole originating network has 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.