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.
I concur with Paul. IPsec is an expensive mechanism that requires an extensive support infrastructure. Yes, it's general. But if all you want is to pass MAC information about local processes as happens on embedded systems IPsec is a bad choice. This is an old discussion. Back in the late 1980's the choices were CIPSO and DNSIX. I don't think that anyone who was involved with the B1/CMW systems of that bygone era would argue that DNSIX was worth the costs. I really dislike unnecessary complexity and I believe that security is probably the last place that complexity should be tolerated. I understand the arguments for DNSIX/IPsec and just can't buy the cost/value proposition. > 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). 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. > > _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
