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 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. 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. 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. - Text on implicit labeling. Strictly speaking this is not necessary, since implicit labeling is a purely local matter. - Perhaps a notification indicating the label/label-range/set assigned by the sender to a given child SA. This would be useful for diagnostic purposes in all cases, particularly implicit labeling cases, but it should be strictly optional. Label ranges/sets would be used only for unnarrowed SAs, obviously. Narrowed SAs should have a single label. - Similarly, a notification indicating whether the sender understood the DOI asserted by the peer. - A separate I-D for adding labeling information to certificates. Nico -- _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
