[Labeled-nfs] Current status

[James Morris]

On Wed, 25 Jul 2007, Joe Nall wrote:

> Looks good. I'm a little concerned about the potential complexity of the DOI
> negotiation and mapping. It is not clear to me that the complexity is
> warranted by real world requirements.

What we intend to do is to at least identify where DOI needs to be 
considered, to ensure that it is part of the underlying design and not 
something which has to be added later as an afterthought.

Also, from a practical point of view, we will need to ensure that systems 
know whether and/or how they can understand each other, especially when 
you have e.g. an organization-wide network connecting to a fileserver, 
where manual configuration of the relationships cannot scale.

> > - "dumb" server, which is not itself MAC enabled, entirely trusts
> >   clients, and simply stores and retrieves MAC labels with the data
> 
> I'm having a hard time envisioning how you would sell this to an
> accreditor/evaluator since server users and processes would not be bound by
> MAC. Maybe if there are no local users (appliance?) and the server meets CAPP.

As Karl mentioned, this would likely not be accreditable, but potentially 
a practical measure for generalized use.  We still need to more closely 
analyze the benefits vs. drawbacks of such a scheme.

> > - Orthogonal security services, not using RPCSEC_GSS e.g. physically
> >   secure networks; labeled networking (CIPSO, labeled IPsec); bump in the
> >   wire security etc.
> 
> Orthogonal - but still using the same DOI?

I'm not sure what you mean here.

The DOI would likely indicate attributes such as policy format version, 
policy type (strict, mls, enforcing etc) and perhaps a DNS namespace (e.g. 
intranet.somewhere).

Security attributes, while needing to be bound to the messaging, would 
likely be negotiated separately.

> We have labeled IPSec networks and test resources if we can help.

Thanks.

-- 
James Morris 
<jmorris at namei.org>