On Mon, 2009-12-07 at 16:37 -0500, Paul Moore wrote:
> On Monday 07 December 2009 11:10:15 am Joy Latten wrote:
> > On Fri, 2009-12-04 at 12:46 -0600, Nicolas Williams wrote:
> > > On Fri, Dec 04, 2009 at 01:39:46PM -0500, Dan McDonald wrote:
> > > > The bigger point being missed by this thread, I think, is that it
> > > > seems that any work in multi-level security needs to deal with
> > > > successful interoperability.  If it doesn't, there's little point in
> > > > documenting a single-platform solution as part of a working group's
> > > > output.
> > >
> > > +1.
> > >
> > > The proposed work item is, at first glance anyways, too SELinux-
> > > specific.
> > >
> > > Note that SMACK encodes its labels as CIPSO labels, so a scheme that
> > > uses CIPSO can possibly be used in SMACK and non-SMACK environments, and
> > > possibly even be mixed.
> > 
> > Yes, I agree.
> > 
> > Actually, we hoped the method we introduced was generic enough to
> > accommodate both CIPSO and SMACK and any other MAC besides SELinux.
> > We had hoped to do this by treating the security context as an opaque
> > blob and introducing a DOI.
> > 
> > I've actually discussed and collaborated about the "DOI" concept with
> > Linux's CIPSO developer, and labeled nfs' developer. SMACK developer
> > was included, but I do not recall if he said anything. We hoped that
> > this "DOI" would not only be used by labeled IPsec, but CIPSO and others
> > that use labels on the network. In a way, the "DOI" would help
> > to identify the "mapping", thus perhaps allowing  different MACs to talk
> > to each other. Interoperability was and is a chief concern. However,
> > I am sure the drafts most definitely can be improved upon.
> 
> At the SELinux Developer's Summit a few months ago there was a bit of a 
> general discussion about DOIs and label representation between myself (Linux 
> labeled networking), Dave Quigley (labeled NFS, added to CC) and Casey 
> Schaufler (SMACK, added to CC) as well as a few others.  As could be 
> expected, 
> there still seems to be quite a bit of confusion around the best way to 
> interoperate two different labeled security mechanisms.  While I believe 
> everyone agrees that tagging network security labels with a DOI is important, 
> there seems to be little consensus beyond that (at least at the summit 
> discussion).  Since Dave has an immediate need, he is working on a solution 
> for labeled NFS which uses three values: a format token, a DOI token, a 
> variable length label blob.  Arguably the format and DOI tokens could be 
> combined but I understand the desire to keep things flexible at this point.  
> It is my understanding that Dave plans to first support a CALIPSO-like format 
> simply because it is well defined and the level/compartment-bitmap format 
> seems to be easiest to internalize across the different labeled security 
> mechanisms.
> 
> I've mentioned all of this before, but my main fundamental concern with the 
> proposed labeled IPsec spec is that not everyone who wants labeled networking 
> wants IPsec.  Look at the CALIPSO effort as an example, it was created 
> because 
> users needed a way to communicate security labels over the network but did 
> not 
> want or need IPsec (they already had security mechanisms in place and IPsec 
> was seen as an unnecessary burden, especially for the smaller devices). 

Yes, I have seen threads debating whether IPv6 should continue to
mandate IPsec for the reasons you have stated. 

>  What 
> I would really like to see is a spec providing for a general security label 
> to 
> be assigned per-packet, similar to CALIPSO but without the reliance on MLS 
> (imagine the FIPS-188 freeform tag).  This way users who only need to 
> labeling 
> support are not required to go through the IPsec end node processing while 
> those users who do not already have a fully trusted network can run IPsec on 
> the untrusted links to secure the packet, the label and their binding.
> 
Yes, I agree that not everyone wants to use IPsec and thus CIPSO would
be a better option for them. 

Perhaps I am incorrect, but it seem possible that as MAC becomes more
mainstream, the desire to communicate beyond the trusted
network/environment will grow. Thus the need to use IPsec to protect the
bindings. It just seem advantageous to me then that IPsec include a
mechanism. 

Either way, as MAC goes more mainstream, I do think a standard solution
addressing interoperability is needed.

regards,
Joy

_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec

Reply via email to