On Mon, Dec 07, 2009 at 04:37:50PM -0500, Paul Moore wrote:
> 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 agree that {format, DOI, blob} is a good place to start.
> 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). 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.
But this is not a reason to oppose labelled IPsec. It's a reason to
want an extended IP packet labelling standard. The two should support
much the same semantics where possible, though IPsec can provide more
functionality (e.g., derive labels from authentication elements).
Nico
--
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
