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

[Russ Housley <[e-mail]>]

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.

Russ

At 11:22 AM 4/3/2009, 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).
>
>At high level SPIF entailed the following:
>
>1.  It was ASN.1 based.
>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.
>
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]] On
> > Behalf Of Nicolas Williams
> > Sent: Thursday, April 02, 2009 11:44 AM
> > To: [e-mail]
> > Cc: [e-mail]; [e-mail];
> > [e-mail]; [e-mail]
> > Subject: [saag] Common labeled security (comment on CALIPSO,
> > labeled NFSv4)
> >
> > 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
> > --
> > _______________________________________________
> > saag mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/saag
> >
>_______________________________________________
>saag mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/saag