[nfs-discuss] [saag] Common labeled security (comment on CALIPSO, labeled NFSv4)
On Mon, Apr 06, 2009 at 01:50:32PM -0400, Russ Housley wrote: > >On Mon, Apr 06, 2009 at 07:03:32AM -0400, Santosh Chokhani wrote: > >> I view SPIF as performing the following functions: converting machine to > >> human representation and vice versa; establishing equivalency between > >> two labeling policies, and defining which labels with the lattice are > >> valid and which are invalid. > > > >If I understand Russ' comment correctly the difficulty with SPIF lies in > >the label equivalency concept. I think there's a better solution for > >dealing with the idea that parts of a policy are classified differently > >than others. > > No. They are two separate concerns. > > Mapping labels between two different policies. Hopefully this can be > avoided altogether in the NFS context. There should be no impact from this on NFS. If a server is able to map some labels between multiple distinct DOIs, so much the better for it, but that would be an implementation detail. Making it possible to express label equivalencies is not an implementation detail. But it's also not a detail we should care about in the context of NFSv4, whereas security policy agreement _is_ something that we should care about in the context of NFSv4. > Some label values are not releasable to clients that do not have > access to data associated with that label. This one is a real-world > problem, and it leads to different clients having different subsets > of the SPIF if this community that is being supported has this > requirement in their policy. Right, that's what I meant, but I had misunderstood "label equivalency" as being related (d'oh). This is a problem that we must deal with to the extent that it impacts how a client and server determine that they agree on a common security policy. Nico --
[nfs-discuss] [saag] Common labeled security (comment on CALIPSO, labeled NFSv4)
On Mon, Apr 06, 2009 at 11:51:38AM -0400, Santosh Chokhani wrote: > Either you need equivalency or not. > > If you do not, that part of SPIF can be stripped off. > > If you do need one, the complexity, scalability, and interoperability of > other alternatives should be assessed against SPIF approach. Indeed. I think, however, that it will be necessary to support policies parts of which are classified differently from each other. It'd be nice to be able to get rid of such a complication. But you can see why this is needed. Remember that during WWII very few people on the Allied side knew about some of the cryptanalysis efforts being made, and, IIRC, all such information was classified as "Ultra" and no one who didn't have Ultra clearance was allowed to know that Ultra existed (presumably because public knowledge of such a classification might have caused the enemy to wonder). Today the names and existence of specific compartments rather than specific sensitivity level, are likley to be the cause of thie requirement. Nico --
[nfs-discuss] [saag] Common labeled security (comment on CALIPSO, labeled NFSv4)
On Mon, Apr 06, 2009 at 07:03:32AM -0400, Santosh Chokhani wrote: > I view SPIF as performing the following functions: converting machine to > human representation and vice versa; establishing equivalency between > two labeling policies, and defining which labels with the lattice are > valid and which are invalid. If I understand Russ' comment correctly the difficulty with SPIF lies in the label equivalency concept. I think there's a better solution for dealing with the idea that parts of a policy are classified differently than others. Nico --
[nfs-discuss] [saag] Common labeled security (comment on CALIPSO, labeled NFSv4)
On Sat, Apr 04, 2009 at 09:28:02PM -0400, Sean Turner wrote: > I usually try to find the corresponding ITU spec because I think ITU > gives out all of it's ASN.1 modules freely? Anyway, here's a link to > the ITU-T X.841 Spec: > http://www.itu.int/ITU-T/asn1/database/itu-t/x/x841/2000/index.html Thanks. I'm sure the spec needs to be read too, not just the ASN.1 module (it's mostly self-evident, but some types, like LabelAndCertValue, require an explanation). > The one thing that's missing from the module is definitions for security > categories. Some suggested categories were defined in Annex B, but it's > an informative annex so there's no ASN.1 freely available (they wouldn't > allow them in the normative text/module). Those categories are based on > FIPS 188 (the syntax is not the same). > > Note that some of the syntax for labels has made it's way to some > IDs/RFCs notably RFC 2634. Thanks. That's very useful. Nico --
[nfs-discuss] [saag] Common labeled security (comment on CALIPSO, labeled NFSv4)
On Fri, Apr 03, 2009 at 03:51:46PM -0400, Santosh Chokhani wrote: > NSA document on SPIF also had ASN.1 module for SPIF. Ah, good! A link would be great. > May be you can use the applicable concepts to get a head start on XML. If the ASN.1 module can be obtained freely then the XML follows trivially (and, as I said, has already been done).
[nfs-discuss] [saag] Common labeled security (comment on CALIPSO, labeled NFSv4)
On Fri, Apr 03, 2009 at 02:11:27PM -0400, Santosh Chokhani wrote: > I do not know what the ISO spec has in it and how it relates to SPIF > work we did. It defines the ASN.1 module that you need to code to.
[nfs-discuss] [saag] Common labeled security (comment on CALIPSO, labeled NFSv4)
On Fri, Apr 03, 2009 at 01:34:23PM -0400, Santosh Chokhani wrote: > The work I am mentioning was done for NSA and can be released if NSA is > ok with it. > > I suspect NSA will be ok with it. Great! But I was referring to the ISO15816 spec -- that does not belong to the NSA, though the NSA might be able to pull strings to make it a free spec. It took so long to make the ASN.1 specs free that I wouldn't hold my breath. I may be better for the IETF to start over on a replacement for SPIF. Nico --
[nfs-discuss] [saag] Common labeled security (comment on CALIPSO, labeled NFSv4)
On Fri, Apr 03, 2009 at 12:44:30PM -0400, Russ Housley wrote: > I really do not have time to write about all of my > concerns. However, once you get beyond the basic classifications, > the SPIF model breaks. They are markings that are only to be known > to people that have the clearance for those markings, this leads to a > SPIF distribution nightmare, as a subset of the real SPIF must be > given out based on access (or not) to various compartments and > such. It just does not scale. I'm aware of the fact that labels can themselves be labeled. But I don't think that implies that we can't make a SPIF-like solution scale. Peers that have access to different subsets of the policy should still be able to interop if care is taken to specify what happens when a node sees a label that falls outside its policy subset, and provided, of course, that the peers can agree that they have subsets of the *same* master policy. Peers can check whether they do have subsets of the *same* master policy by exchanging [for each DOI to both] a master policy URI that includes a version number. Nico --
[nfs-discuss] [saag] Common labeled security (comment on CALIPSO, labeled NFSv4)
On Fri, Apr 03, 2009 at 11:22:38AM -0400, Santosh Chokhani wrote: > As part of MISSI and DMS, in mid to late 90's we did work on something > called Security Policy Information File (SPIF). Oh, very nice! Thanks for the pointer. That would be ISO15816. I've found the spec, though it's non-free (hadn't they learned the lesson with ASN.1?? will they ever learn it??). > At high level SPIF entailed the following: > > 1. It was ASN.1 based. Not surprisingly :) Converting that to XML is probably the correct first step in order to ensure adoption, sadly. (Actually, apparently that has already been done once, though outside the ISO/ITU-T.) > 2. It permitted you to convert the machine representation to human > readable representation. > 3. It permitted you to convert the human readable input to machine > representation. > 4. It mapped labels (hierarchical sensitivity levels and > non-hierarchical categories) from one labeling policy to another (i.e., > establish equivalency mapping) > 5. It allowed you to constrain labels since for some policies, > existence of a category may mean some categories, levels, may be > included and/or excluded. > > Different labeling policies were indicated by different policy OID. > > Some of the concept from that work may be applicable here. I think so! Except for the part about this spec being non-free. I think that means: start over in the IETF. Nico --
