Subject: Re: [secdir] draft-ietf-nfsv4-federated-fs-reqts-03

From: James Lentini <[email-masked]>
Date: Wed, 30 Sep 2009 18:17:31 -0400 (EDT)

Nico,

Thank you for your feedback. We will update the document to include 
the improvements you have suggested both to the security 
considerations (noting the authorization separation inherent in the 
design, the resource consumption considerations for NSDB objects, and 
the implications regarding NSDB authentication) and general 
description (regarding the absence of junctions in the NSDB and the 
benefits of using fixed size FSNs).

On Wed, 30 Sep 2009, Nicolas Williams wrote:

> I have reviewed this document as part of the security directorate's                                                                 
> ongoing effort to review all IETF documents being processed by the                                                                  
> IESG.  These comments were written primarily for the benefit of the                                                                 
> security area directors.  Document editors and WG chairs should treat                                                               
> these comments just like any other last call comments.                                                                              
> 
> This document describes the notion of "federated filesystem namespace"
> and requirements for specifications of an actual set of federated
> filesystem namespace components and even some requirements of actual
> implementations.
> 
> A federated namespace is one where multiple filesystems (or, rather,
> "filesets") are put together into a larger filesystem-like namespace,
> but where the various filesystems involved can be owned and administered
> by widely varying entities.
> 
> Authorization issues arise when filesystems migrate, and these are
> neatly resolved in the federated namespace concept by separating the
> location of references to filesystems from the location of fileset
> location information.  References to filesets ("junctions") live in
> actual filesystem (think of a magic symlink or "shortcut").  Fileset
> location information lives in a directory whose name is part of the
> fileset's name as referenced by any junction that refers to it.
> 
> Authorization of junction administration is a matter local to the
> filesystems where the junctions live.  Authorization of fileset location
> administration is a matter local to the directory where the fileset
> location information is published.
> 
> There is one more level of separation as well, to allow for filesets
> with replicas owned and administered by different entities.  "Fileset
> names" (FSNs) refer to directory objects which in turn refer to "fileset
> location" objects (FSLs); both, FSNs and FSLs include the name of the
> containing directory in their canonical name forms.
> 
> The document does not describe the authorization separation involved.
> And though it isn't strictly necessary, I believe that it would be
> beneficial to have such a description.
> 
> The document also does not clearly explain that junctions are not
> published in any directory, which confused me greatly at first, as in my
> opinion publishing FSN and FSL objects does not make the directories in
> which they are published "namespace databases" (NSDBs).  This is not a
> security concern, of course.
> 
> The document also does not explain that FSNs are intended to be small,
> even fixed sized, or with highly compressible variable size portions[*].
> But a moment's thought about filesystem designs quickly reveals that
> such a requirement is important.  In my opinion such a requirement
> should be documented.  This too is not a security concern.
> 
> The Security Considerations section is a bit skimpy.  Its claims are
> correct in my opinion.  I would, however, add to it the following:
> 
>  - A note that the federated namespace concept helps distribute
>    responsibility for authorization (a very good thing).
> 
>  - A note that orphaned FSNs and FSLs cannot be easily distinguished
>    from ones referenced by junctions and FSNs, respectively.  Therefore
>    objects will tend to pile up.  This is a resource consumption
>    consideration.  Resource control issues are, IMO, a security
>    consideration.
> 
> Finally, I'm not sure if it's worth saying anything about the fact that
> with the NSDB choice being up to the FSN and FSL publishers, there can
> be a plethora of NSDBs in a federation, which brings scalability of
> distributed authentication and trust into the picture.  For example,
> consider an NSDB that uses TLS and a self-signed server certificate to
> authenticate itself, then a fingerprint of the certificate will have to
> be part and parcel of the FSN/FSL names stored by junctions/FSNs
> (respectively).  A PKI would help, of course, but in a sufficiently
> large federation it may be necessary to have multiple trust anchors,
> rather than a single PKI root, which brings TA administration issues
> into the picture.  This is really nothing new, and so perhaps not worth
> noting, but the potential for having to store, and the consequences
> thereof, FSN NSDB authentication information in junctions, and FSL NSDB
> authentication information in FSNs, does seem to me to be worth noting.
> 
> [*] For example, assuming many FSNs but relatively few NSDBs, filesystem
>     implementors could choose store FSNs as {reference to NSDB name, FSN
>     object name relative to NSDB}.  If the second item of the tuple is
>     itself fixed-sized then the whole tuple can be fixed sized.  A table
>     of {NSDB name, reference} would be needed too, but it may be
>     critical to keep "inodes" fixed-sized, with little wastage, in which
>     case "interning" NSDB names as described above is a sufficient
>     compression technique.
> 
>     In fact, draft-ietf-nfsv4-federated-fs-protocol-03 does use UUIDs
>     for naming FSNs and FSLs, so that the above technique is certainly a
>     feasible way to keep inodes fixed-sized in spite of the fact that
>     FSNs are actually variable sized (the NSDB name where the FSN
>     resides is part of the FSN's name).
> 
> Nico
> -- 
>