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

Nicolas Williams <Nicolas.Williams@sun.com> Mon, 06 April 2009 18:49 UTC

Return-Path: <Nicolas.Williams@sun.com>
X-Original-To: saag@core3.amsl.com
Delivered-To: saag@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 74D9F3A67A7; Mon, 6 Apr 2009 11:49:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.805
X-Spam-Level:
X-Spam-Status: No, score=-5.805 tagged_above=-999 required=5 tests=[AWL=0.241, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8wnAavvQYN-x; Mon, 6 Apr 2009 11:49:17 -0700 (PDT)
Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by core3.amsl.com (Postfix) with ESMTP id 95DF828C2D7; Mon, 6 Apr 2009 11:49:17 -0700 (PDT)
Received: from dm-central-02.central.sun.com ([129.147.62.5]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n36IoJZQ022450; Mon, 6 Apr 2009 18:50:19 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n36IoJXL050781; Mon, 6 Apr 2009 12:50:19 -0600 (MDT)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n36IArHa004772; Mon, 6 Apr 2009 13:10:53 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n36IAra4004771; Mon, 6 Apr 2009 13:10:53 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f
Date: Mon, 06 Apr 2009 13:10:53 -0500
From: Nicolas Williams <Nicolas.Williams@sun.com>
To: Russ Housley <housley@vigilsec.com>
Message-ID: <20090406181052.GF1500@Sun.COM>
References: <20090402154402.GM1500@Sun.COM> <FAD1CF17F2A45B43ADE04E140BA83D48A9FF82@scygexch1.cygnacom.com> <20090403164522.DEA9A9A4739@odin.smetech.net> <9C2457A4-328A-4A68-A9D2-6E4B5544078D@Isode.com> <FAD1CF17F2A45B43ADE04E140BA83D48A9FFE0@scygexch1.cygnacom.com> <B8FB99E8-17AA-4D4B-A309-8AF79838A304@Isode.com> <FAD1CF17F2A45B43ADE04E140BA83D48A9FFE9@scygexch1.cygnacom.com> <20090406151606.GQ1500@Sun.COM> <20090406180424.BA7AC9A4749@odin.smetech.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <20090406180424.BA7AC9A4749@odin.smetech.net>
User-Agent: Mutt/1.5.7i
Cc: labeled-nfs@linux-nfs.org, nfsv4@ietf.org, Kurt Zeilenga <Kurt.Zeilenga@Isode.com>, saag@ietf.org, nfs-discuss@opensolaris.org, Santosh Chokhani <SChokhani@cygnacom.com>
Subject: Re: [saag] Common labeled security (comment on CALIPSO, labeled NFSv4)
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Advisory Group <saag.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/saag>, <mailto:saag-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/saag>
List-Post: <mailto:saag@ietf.org>
List-Help: <mailto:saag-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/saag>, <mailto:saag-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 06 Apr 2009 18:49:18 -0000

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
--