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

["Santosh Chokhani" <[e-mail]>]

Russ,

I was thinking along the same lines.  More specifically,

1.  They can use he feature that helps covert machine representation to
human readable representation and vice versa.

2.  I suspect the distribution nightmare you mentioned and Kurt seconded
relates to label names being sensitive or aggregation of labels' names
being sensitive.  I hope this is not a problem in the environments they
mention in the sense that SPIF can be classified such that all users can
access it.

3.  They probably do not need the excluded and required features (i.e.,
they do not need to worry about some labels in the lattice being
semantically permitted).  This will simplify SPIF a lot.

4.  I am torn on the issue of mapping you mentioned.  At a minimum SPIF
can let them label the data for different labeling policies and do away
with the mapping as you suggest.  This may mean that subject may need
authorizations spelled out in multiple policy domains.  This approach
will get rid of one of your key concerns about complexity of SPIF.
Item 2 above hopefully addresses the other.

> -----Original Message-----
> From: Russ Housley [mailto:[e-mail]] 
> Sent: Saturday, April 04, 2009 2:39 PM
> To: Santosh Chokhani; [e-mail]
> Cc: [e-mail]; [e-mail]; 
> [e-mail]
> Subject: RE: [saag] Common labeled security (comment on 
> CALIPSO, labeled NFSv4)
> 
> Santosh:
> 
> There may be things that can be kept for this environment, 
> especially if all of the clients of a particular file system 
> are probably operating under a single security policy.  If 
> you can eliminate policy mapping and markings that must be 
> hidden from some clients, then a subset of the SPIF may be useful.
> 
> Russ
> 
> At 01:36 PM 4/3/2009, Santosh Chokhani wrote:
> >Russ,
> >
> >My thinking was that the features of SPIF that are not 
> needed could be 
> >discarded.
> >
> >I was hoping that we could help the group save the baby and 
> throw out 
> >the bath water.
> >
> > > -----Original Message-----
> > > From: Russ Housley [mailto:[e-mail]]
> > > Sent: Friday, April 03, 2009 12:45 PM
> > > To: Santosh Chokhani; [e-mail]
> > > Cc: [e-mail]; [e-mail]; 
> > > [e-mail]; [e-mail]
> > > Subject: Re: [saag] Common labeled security (comment on CALIPSO, 
> > > labeled NFSv4)
> > >
> > > 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
> > >
> > >
> 
>