On Mon, 2009-12-07 at 15:02 -0600, Nicolas Williams wrote: > On Mon, Dec 07, 2009 at 10:10:15AM -0600, Joy Latten wrote: > > > 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. > > See the long threads on related topics on the SAAG and NFSv4 lists with > subjects: > > - Common labeled security (comment on CALIPSO, labeled NFSv4) > - Why the IETF should care about labeled?ne tworking (was:CIPSO > implementations) > - Secdir Review of draft-stjohns-sipso-05
Thanks for pointing this out. I was not aware of the threads and am finding them very interesting and informative. > > I'm not sure what the best way forward is, but here are some thoughts: > > - A notification indicating what DOI(s) are supported by the sender > might help. > Yes. The drafts suggest that by specifying the DOI as part of the SPD entry, that would identify the DOI to support for this traffic stream. > Not that I expect that any system will participate in multiple DOIs, > but then, IIRC SMACK supports mappings of SMACK labels (which hijack > a level in CIPSO) to non-SMACK CIPSO labels for interop, for example. > This idea is probably not too farfetched. > > - A label type in addition to DOI. > Ok. I originally perceived this as part of the DOI description, but I could understand wanting to separate for perhaps flexibility. > Not that I expect a single DOI to use multiple label types, but at > least one can then parse the label payload according to the stated > type rather than having to find the right type for the given DOI. > > - Text on the encodings of specific label types' labels. > > Particularly I think you need to have normative references to the > relevant RFCs and other work for the 'core' label types. > Yes, I agree, although I am unaware of any RFCs dealing with that yet. regards, Joy _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
