Joy Latten wrote:
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.
Without rehashing the statements made in above discussion threads, it's
probably helpful to have a realistic interoperability expectation for
labeled systems. Defining label formats and security mechanisms in
various networking protocols is important. Consistent label
interpretation and label policy enforcement are also key to labeled
communication. Note the latter is mostly handled outside the protocols
in this discussion. So in reality, only systems that implement same
Mandatory Access Control (MAC) security models are likely to be able to
inter-operate. A possible example is OpenSolaris FMAC and SELinux.
The term "DOI" has been used in traditional MLS system for about two
decades. In the MLS world, when systems use same DOI, it means they
agree to the same label definition and MAC policy, and the systems are
most likely under same administrative control (Note which policy is
agreed upon is handled outside of a networking protocol). The label
format is determined, i.e. it's CIPSO. In the current "Labeled IPsec"
proposal, DOI is a Security Label Format Selector. I really think you
ought to use a different name, calling it what it is and not be confused
with MLS DOI. And use ISAMKP DOI when appropriate to avoid confusion.
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.
David Quigley and I had some offline conversation about this, as he has
the same need for labeled NFSv4 work. The current thinking is to have a
separate draft describing the need to set up an IANA registry and its
content. Each entry consists at least the following fields:
LABEL TYPE: A number to indicate label type, e.g. CIPSO, CALIPSO,
SELinux security contex strings, etc.
SUB FIELD: Used to aid label handling, e.g. SELinux could use it for
policy version numbers; CIPSO could use it for tag type;
LABEL FORMAT: pointers to reference docs on how labels should be parsed.
Both Labeled IPsec and labeled NFSv4 (and any future label protocol
extensions) can refer to this document.
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.
There are more references for MLS labels (FIPS 188, CALIPSO draft, etc.)
as they have a longer history. BTW, I don't think the label format
specification has to be IETF RFCs.
- Jarrett
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
