Common labeled security (comment on CALIPSO, labeled NFSv4)

Common labeled security (comment on CALIPSO, labeled NFSv4)

[Nicolas Williams]

Over at the NFSv4 WG we've been having a discussion of a labeled NFSv4
proposal.  [Note: NFSv4 WG and others cc'ed, Reply-To: set to SAAG.]

An interop issue has arisen that we believe applies equally to CALIPSO
(draft-stjohns-sipso-11.txt)and requires input from the IETF security
area.

The issue is: how do do nodes in a labeled network/application know if
they agree on a common labeled security policy for a given DOI?

Agreeing on a DOI is accomplished easily enough -- that's not an issue.
Agreeing on what a given numeric sensitivity level or compartment bit
means in a given DOI is quite another.  Without a solution to this we're
left with out-of-band agreement, which leaves interop in a lurch.

I think we need a generic MLS and DTE labeled security policy document
format that allows a DOI to define the names and numeric assignments of
sensitivity levels, compartments, etcetera.

We also need a way for nodes to agree that they have the same policy for
a given DOI, or that they agree on a common subset of a DOI's policy.

This last problem can be solved by use of a labeled security policy URI
scheme that includes a version number (+ a requirement that changes be
in the form of additions and obsolescence of old assignments, but not
removals).

To recap: I think we need a) a common MLS and DTE labeled security
policy document format, b) a labeled security policy URI scheme to refer
to such documents by.

Given (a) and (b) NFSv4.x clients and servers would only have to
exchange {DOI #, policy URI} tuples to determine whether they agree on a
common policy.

Note that CALIPSO describes how to encode and compare MLS labels on the
wire, but it does not describe how nodes agree on the meaning of
particular sensitivity levels or compartments.  Therefore CALIPSO is
going to have much the same problem as NFSv4.

Nico
-- 

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [saag] Common labeled security (comment on CALIPSO, labeled NFSv4)

[Nicolas Williams]

On Fri, Apr 03, 2009 at 11:22:38AM -0400, Santosh Chokhani wrote:
> As part of MISSI and DMS, in mid to late 90's we did work on something
> called Security Policy Information File (SPIF).

Oh, very nice!  Thanks for the pointer.  That would be ISO15816.  I've
found the spec, though it's non-free (hadn't they learned the lesson
with ASN.1??  will they ever learn it??).

> At high level SPIF entailed the following:
> 
> 1.  It was ASN.1 based.

Not surprisingly :)  Converting that to XML is probably the correct
first step in order to ensure adoption, sadly.  (Actually, apparently
that has already been done once, though outside the ISO/ITU-T.)

> 2.  It permitted you to convert the machine representation to human
> readable representation.
> 3.  It permitted you to convert the human readable input to machine
> representation.
> 4.  It mapped labels (hierarchical sensitivity levels and
> non-hierarchical categories) from one labeling policy to another (i.e.,
> establish equivalency mapping)
> 5.  It allowed you to constrain labels since for some policies,
> existence of a category may mean some categories, levels, may be
> included and/or excluded.
> 
> Different labeling policies were indicated by different policy OID.
> 
> Some of the concept from that work may be applicable here. 

I think so!  Except for the part about this spec being non-free.  I
think that means: start over in the IETF.

Nico
-- 

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [saag] Common labeled security (comment on CALIPSO, labeled NFSv4)

[Nicolas Williams]

On Fri, Apr 03, 2009 at 01:34:23PM -0400, Santosh Chokhani wrote:
> The work I am mentioning was done for NSA and can be released if NSA is
> ok with it.
> 
> I suspect NSA will be ok with it. 

Great!

But I was referring to the ISO15816 spec -- that does not belong to the
NSA, though the NSA might be able to pull strings to make it a free
spec.  It took so long to make the ASN.1 specs free that I wouldn't hold
my breath.  I may be better for the IETF to start over on a replacement
for SPIF.

Nico
-- 

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [saag] Common labeled security (comment on CALIPSO, labeled NFSv4)

[Nicolas Williams]

On Fri, Apr 03, 2009 at 02:11:27PM -0400, Santosh Chokhani wrote:
> I do not know what the ISO spec has in it and how it relates to SPIF
> work we did. 

It defines the ASN.1 module that you need to code to.

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [saag] Common labeled security (comment on CALIPSO, labeled NFSv4)

[Nicolas Williams]

On Fri, Apr 03, 2009 at 03:51:46PM -0400, Santosh Chokhani wrote:
> NSA document on SPIF also had ASN.1 module for SPIF.

Ah, good!  A link would be great.

> May be you can use the applicable concepts to get a head start on XML. 

If the ASN.1 module can be obtained freely then the XML follows
trivially (and, as I said, has already been done).

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [saag] Common labeled security (comment on CALIPSO, labeled NFSv4)

[Nicolas Williams]

On Sat, Apr 04, 2009 at 09:28:02PM -0400, Sean Turner wrote:
> I usually try to find the corresponding ITU spec because I think ITU 
> gives out all of it's ASN.1 modules freely?  Anyway, here's a link to 
> the ITU-T X.841 Spec:
> http://www.itu.int/ITU-T/asn1/database/itu-t/x/x841/2000/index.html

Thanks.  I'm sure the spec needs to be read too, not just the ASN.1
module (it's mostly self-evident, but some types, like
LabelAndCertValue, require an explanation).

> The one thing that's missing from the module is definitions for security 
> categories.  Some suggested categories were defined in Annex B, but it's 
> an informative annex so there's no ASN.1 freely available (they wouldn't 
> allow them in the normative text/module).  Those categories are based on 
> FIPS 188 (the syntax is not the same).
> 
> Note that some of the syntax for labels has made it's way to some 
> IDs/RFCs notably RFC 2634.

Thanks.  That's very useful.

Nico
-- 

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [saag] Common labeled security (comment on CALIPSO, labeled NFSv4)

[Nicolas Williams]

On Fri, Apr 03, 2009 at 12:44:30PM -0400, Russ Housley wrote:
> I really do not have time to write about all of my 
> concerns.  However, once you get beyond the basic classifications, 
> the SPIF model breaks.  They are markings that are only to be known 
> to people that have the clearance for those markings, this leads to a 
> SPIF distribution nightmare, as a subset of the real SPIF must be 
> given out based on access (or not) to various compartments and 
> such.  It just does not scale.

I'm aware of the fact that labels can themselves be labeled.  But I
don't think that implies that we can't make a SPIF-like solution scale.

Peers that have access to different subsets of the policy should still
be able to interop if care is taken to specify what happens when a node
sees a label that falls outside its policy subset, and provided, of
course, that the peers can agree that they have subsets of the *same*
master policy.  Peers can check whether they do have subsets of the
*same* master policy by exchanging [for each DOI to both] a master
policy URI that includes a version number.

Nico
-- 

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [saag] Common labeled security (comment on CALIPSO, labeled NFSv4)

[Nicolas Williams]

On Mon, Apr 06, 2009 at 07:03:32AM -0400, Santosh Chokhani wrote:
> I view SPIF as performing the following functions: converting machine to
> human representation and vice versa; establishing equivalency between
> two labeling policies, and defining which labels with the lattice are
> valid and which are invalid.

If I understand Russ' comment correctly the difficulty with SPIF lies in
the label equivalency concept.  I think there's a better solution for
dealing with the idea that parts of a policy are classified differently
than others.

Nico
-- 

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [saag] Common labeled security (comment on CALIPSO, labeled NFSv4)

[Nicolas Williams]

On Mon, Apr 06, 2009 at 11:51:38AM -0400, Santosh Chokhani wrote:
> Either you need equivalency or not.
> 
> If you do not, that part of SPIF can be stripped off.
> 
> If you do need one, the complexity, scalability, and interoperability of
> other alternatives should be assessed against SPIF approach.

Indeed.  I think, however, that it will be necessary to support policies
parts of which are classified differently from each other.  It'd be nice
to be able to get rid of such a complication.

But you can see why this is needed.  Remember that during WWII very few
people on the Allied side knew about some of the cryptanalysis efforts
being made, and, IIRC, all such information was classified as "Ultra"
and no one who didn't have Ultra clearance was allowed to know that
Ultra existed (presumably because public knowledge of such a
classification might have caused the enemy to wonder).

Today the names and existence of specific compartments rather than
specific sensitivity level, are likley to be the cause of thie
requirement.

Nico
-- 

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.