Re: [saag] Common labeled security (comment on CALIPSO, labeled NFSv4)

"Santosh Chokhani" <> Fri, 03 April 2009 15:21 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7451528C282 for <>; Fri, 3 Apr 2009 08:21:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.436
X-Spam-Status: No, score=-1.436 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id pHw4d6RkPzjo for <>; Fri, 3 Apr 2009 08:21:36 -0700 (PDT)
Received: from ( []) by (Postfix) with SMTP id 79B763A6862 for <>; Fri, 3 Apr 2009 08:21:36 -0700 (PDT)
Received: (qmail 8302 invoked from network); 3 Apr 2009 15:21:32 -0000
Received: from unknown (HELO ( by with SMTP; 3 Apr 2009 15:21:32 -0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5
Date: Fri, 03 Apr 2009 11:22:38 -0400
Message-ID: <>
In-Reply-To: <20090402154402.GM1500@Sun.COM>
Thread-Topic: [saag] Common labeled security (comment on CALIPSO, labeled NFSv4)
Thread-Index: AcmzqyjnktCJdE01TAayDuJGh7ueugAvoXsw
References: <20090402154402.GM1500@Sun.COM>
From: Santosh Chokhani <>
Subject: Re: [saag] Common labeled security (comment on CALIPSO, labeled NFSv4)
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Advisory Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 03 Apr 2009 15:21:37 -0000

As part of MISSI and DMS, in mid to late 90's we did work on something
called Security Policy Information File (SPIF).

At high level SPIF entailed the following:

1.  It was ASN.1 based.
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
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. 

> -----Original Message-----
> From: [] On 
> Behalf Of Nicolas Williams
> Sent: Thursday, April 02, 2009 11:44 AM
> To:
> Cc:;; 
> Subject: [saag] Common labeled security (comment on CALIPSO, 
> labeled NFSv4)
> Over at the NFSv4 WG we've been having a discussion of a 
> labeled NFSv4 proposal.  [Note: NFSv4 WG and others cc'ed, 
> Reply-To: set to SAAG.]
> An interop issue has arisen that we believe applies equally 
> to CALIPSO (draft-stjohns-sipso-11.txt)and requires input 
> from the IETF security area.
> The issue is: how do do nodes in a labeled 
> network/application know if they agree on a common labeled 
> security policy for a given DOI?
> Agreeing on a DOI is accomplished easily enough -- that's not 
> an issue.
> Agreeing on what a given numeric sensitivity level or 
> compartment bit means in a given DOI is quite another.  
> Without a solution to this we're left with out-of-band 
> agreement, which leaves interop in a lurch.
> I think we need a generic MLS and DTE labeled security policy 
> document format that allows a DOI to define the names and 
> numeric assignments of sensitivity levels, compartments, etcetera.
> We also need a way for nodes to agree that they have the same 
> policy for a given DOI, or that they agree on a common subset 
> of a DOI's policy.
> This last problem can be solved by use of a labeled security 
> policy URI scheme that includes a version number (+ a 
> requirement that changes be in the form of additions and 
> obsolescence of old assignments, but not removals).
> To recap: I think we need a) a common MLS and DTE labeled 
> security policy document format, b) a labeled security policy 
> URI scheme to refer to such documents by.
> Given (a) and (b) NFSv4.x clients and servers would only have 
> to exchange {DOI #, policy URI} tuples to determine whether 
> they agree on a common policy.
> Note that CALIPSO describes how to encode and compare MLS 
> labels on the wire, but it does not describe how nodes agree 
> on the meaning of particular sensitivity levels or 
> compartments.  Therefore CALIPSO is going to have much the 
> same problem as NFSv4.
> Nico
> --
> _______________________________________________
> saag mailing list