[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Sensitivity Labels
>
> > From: Ran Atkinson <rja@cisco.com>
> > % C) Sensitivity Labels are ill-defined.
> >
> > Hardly. See RFC-1108.
> >
> I re-read RFC-1108, just to make sure my memory wasn't utterly failing,
> and I found this statement at the very top, in the title:
>
> U.S. Department of Defense
> Security Options for the Internet Protocol
>
> How does that apply to commercial implementations?
>
> How does that apply to international implementations?
>
> ----
Check out the newly emerging security label standards - NIST's
"Standard Security Label" (SSL) and the DoD version "Common Security
Label" (CSL) [MIL-STD-2045-48501]. These were adapted/extended from
the IPSO (RFC-1108) and the Common IPSO (CIPSO). The SSL and the CSL
were carefully harmonized - in other words, they say the same things.
So, here we have what will be a security label standard applicable to
the civil/commercial world as well as the military community.
>
> Moreover, these are examples of facilities for "explicit" labels, rather
> than "implicit" labels (indicated per SPI) used for IP Security.
>
But why should "explict" labels be precluded? There are times when
they are explicitly needed (see below).
> I find that the application of these labels are used for
> particular objectives (from RFC-1108 page 2):
>
> This option is used by end systems and intermediate systems of an
> internet to:
>
> a. Transmit from source to destination in a network standard
> representation the common security labels required by computer
> security models,
>
> b. Validate the datagram as appropriate for transmission from
> the source and delivery to the destination,
>
> c. Ensure that the route taken by the datagram is protected to
> the level required by all protection authorities indicated on
> the datagram. In order to provide this facility in a general
> Internet environment, interior and exterior gateway protocols
> must be augmented to include security label information in
> support of routing control.
>
> What Internet routing protocols support this routing control?
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
None deployed, but have you heard of "policy-based" routing?
Besides, policy routing is only one issue. Nothing precludes the use
of IP security option labels that could be checked by a packet's
receipient to determine whether the packet is within an acceptable
classification range. This is a *very* useful feature when multiple
sensitivity systems are connected together via firewalls or other high
assurance guards. For example, presume a multilevel system containing
both proprietary and non-proprietary data. Only non-proprietary data
may cross the boundary of the firewall/guard and flow out. The MLS
system could employ sensitivity labels to provide a basis on which the
firewall/guard can easily permit/deny datagrams flowing across its
boundary. Many cludges have been put together because of a lack of
systems that can support sensitivity labels.
> How exactly are the proposed IP Security Sensitivity Labels used in
> "network layer" routing without this routing control?
The routing controls are only one piece of the puzzle. What precludes
anyone from using this in the future (e.g., with policy-based
routing)? There is at least one large site that I've been involved
with that could have effectively used sensitivity labels on connections if
their installed routers could have dealt with the labels without a
major performance penalty (which seemed to be a problem with the
particular vendor rather than the technical issue of filtering based
on security label - other vendors claimed to have no such performance
penalties in using IPSO).
> See also RFC-1457, which complains that there is no standard network
> label format, discusses translation problems, and examines the current
> status of labels in the protocol stack (including IEEE and ISO).
But this will be overcome by the SSL/CSL
>
> Indeed, RFC-1457 recommendations appear to indicate that implicit labels
> are best applied at the link and transport layers, not the network layer.
The age-old problem with network layer labels (e.g., IPSO) is that
they could not be protected if the network layer itself was not
protected (i.e., not encrypted). As long as there is a means to provide
label integrity, the label could be at any layer.
>
> Again, the RFC-1825 Sensitivity Label recommendations were misguided and
> ill-defined, and implementation experience has shown that we have no
> need of them.
Talk to the Compartmented Workstation (CMW) vendors and the Trusted
Systems Interoperability Group (TSIG). From TSIG documentation:
" In order for two MLS systems to communicate securely, two
kinds of information must be exchanged:
* Information, such as user identities, that users
themsevles can establish thorugh something that they
are, know or posess; and
* Information, such as sensitivity labels, which users
themselves cannot establish but which trusted
systems must establish for them."
Obviously, there is at least one group of communicating systems that
*do* have a need for sensitivity labels!
> I urge the WG to clearly indicate that they should be removed.
I urge that they remain.
>
> Bill.Simpson@um.cc.umich.edu
> Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2
>
Howard Weiss
________________________________________________________________________
| |
| Howard Weiss phone (410) 381-9400 x201 |
| SPARTA, Inc. (301) 621-8145 x201 (DC)|
| 9861 Broken Land Parkway, suite 300 fax: (410) 381-5559 |
| Columbia, MD 21046 email: hsw@columbia.sparta.com|
|________________________________________________________________________|
Follow-Ups:
References: