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

Nicolas Williams <Nicolas.Williams@sun.com> Thu, 02 April 2009 15:52 UTC

Return-Path: <Nicolas.Williams@sun.com>
X-Original-To: saag@core3.amsl.com
Delivered-To: saag@core3.amsl.com
Received: from localhost (localhost []) by core3.amsl.com (Postfix) with ESMTP id 8025F3A6DE7; Thu, 2 Apr 2009 08:52:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.767
X-Spam-Status: No, score=-5.767 tagged_above=-999 required=5 tests=[AWL=0.279, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id ioKOpZ6bxFti; Thu, 2 Apr 2009 08:52:18 -0700 (PDT)
Received: from sca-ea-mail-4.sun.com (sca-ea-mail-4.Sun.COM []) by core3.amsl.com (Postfix) with ESMTP id B9A493A6DAE; Thu, 2 Apr 2009 08:52:18 -0700 (PDT)
Received: from dm-central-01.central.sun.com ([]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n32FrKAh006706; Thu, 2 Apr 2009 15:53:20 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM []) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n32FrJVd011156; Thu, 2 Apr 2009 09:53:20 -0600 (MDT)
Received: from binky.Central.Sun.COM (localhost []) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n32Fi2Ge001972; Thu, 2 Apr 2009 10:44:02 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n32Fi2Tt001971; Thu, 2 Apr 2009 10:44:02 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f
Date: Thu, 02 Apr 2009 10:44:02 -0500
From: Nicolas Williams <Nicolas.Williams@sun.com>
To: saag@ietf.org
Message-ID: <20090402154402.GM1500@Sun.COM>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
User-Agent: Mutt/1.5.7i
Cc: labeled-nfs@linux-nfs.org, selinux@tycho.nsa.gov, nfsv4@ietf.org, nfs-discuss@opensolaris.org
Subject: [saag] Common labeled security (comment on CALIPSO, labeled NFSv4)
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: saag@ietf.org
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: Thu, 02 Apr 2009 15:52:19 -0000

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

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

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.