Re: [nfsv4] comments on draft-welch-pnfs-ops-00.txt

welch@panasas.com

Message-Id: <200411160312.iAG3CCF22123@medlicott.panasas.com>
Subject: Re: [nfsv4] comments on draft-welch-pnfs-ops-00.txt 
From: Brent Welch <welch@panasas.com>
Date: Mon, 15 Nov 2004 19:12:12 -0800

Let me try some simple logic.

My kitten has green eyes.  Therefore all kittens have green eyes.

Block storage protocols are insecure, 
therefore all storage protocols are insecure.

I would like to table all discussion of block protocol security
as being out of scope.  I think it clouds the issue and gets in
the way of working out an acceptable pNFS extension.

I am trying to communicate three points:

1. pNFS can use NFSv4 as the storage protocol, and should be just
as secure as NFSv4.  I think REQUIREing that NFSv4 be implemented
by all clients as one of their possible storage protocols is OK,
and makes perfect sense.

2. pNFS should allow different storage protocols.  These are OPTIONAL
storage protocols.  This is important to me because my preferred
storage protocol is object storage (iSCSI/OSD).  And, there are others
for whom other storage protocols are important (legacy NFS servers,
PVFS implementations, block storage on a SAN).  Harking back to the
alice in wonderland logic above, it should be OK to allow other
storage protocols w/out compromising pNFS when used with NFSv4 
or some other secure storage protocol.  Please don't misinterpret this.
OF COURSE if a customer chooses to use an insecure storage protocol
they are taking a risk.  But, that doesn't mean all customers are
taking the same risk because they don't have to use or provide those
insecure storage protocols in their environment.

3. Object storage has a secure protocol, but it does place a
demand on the pNFS client to NFSv4 server communication.
This is worth debating. It requires that capabilities and signing
keys be returned to the client over a secure channel so they cannot
be snooped.

>>>Nicolas Williams said:
 > On Thu, Nov 11, 2004 at 04:35:00PM -0800, Brent Welch wrote:
 > [...]
 > > But, we really do not want to preclude
 > > other storage protocols.  The people discussing this protocol for
 > > the past year come from companies that do NFS servers, scientists that
 > > use non-kernel filesystems like PVFS, companies that do object storage,
 > > and companies that do SAN filesystems.   By keeping these other
 > > storage protocols in mind when we design the extension, and putting
 > > in the appropriate type fields to all for them, we think we are adding
 > > more value to the extension.  We are not requiring (i.e., REQUIRED) 
that
 > > all possible storage protocols be implemented.  But, we would really
 > > like to allow them.
 > > 
 > > About security.  I know you all have worked hard to get good security
 > > into NFSv4, and I think that's great.  We have no intention of watering
 > > down the security of NFSv4.  I think Dave Noveck said the right thing,
 > > that the requirement is that the data servers honor the ACL stored
 > > on the metadata server.  That can be done by pushing ACLs out to
 > > the data servers (in a fault tolerant way) or by having the data 
servers
 > > pull ACL information and cache it. Currently, the protocol used
 > > between the metadata server and the storage servers is out of scope
 > > of the pNFS extension.  (We're calling this the 
 > > "Storage Management Protocol", although that is probably an overloaded 
ter
     m)
 > 
 > If you rely on a pNFS-server-to-storage protocol to obtain NFSv4
 > security semantics then you will have to specify that protocol.
 > Yesterday you were quite clear that you thought that that piece ought to
 > remain unspecified and a field for proprietary innovation.  See below.
 > 
 > > In contrast to what Nico said,
 > > we've never stated that the client must interpret and enforce ACLs.
 > 
 > I wrote: "[...] not if the client is made to be responsible for
 > enforcing ACLs as you (the presenters) admitted yesterday [...]"
 > 
 > I did not say "interpret."  Below you write "[...] and, yes, some trust
 > of the client code."  I think this is consistent with "enforce" --
 > though that may not have been the best choice of words; I think it
 > serves my point, which is that the security properties of your preferred
 > (?) approach to pNFS differ markedly from NFSv4's.
 > 
 > > Instead, what we said is that some storage protocols (e.g., used with
 > > SAN filesystems) rely on physical security, protection zones in the
 > > storage network, and, yes, some trust of the client code.  However,
 > > please keep in mind that if someone wants to use an insecure data
 > > storage protocol in conjunction with pNFS, it is not REQUIRED that
 > > anyone else use it, nor should their use of it in any way affect
 > > the security of pNFS used, e.g., with NFSv4 as the storage protocol.
 > 
 > It seems feasible to get NFSv4 security semantics in pNFS by using a
 > storage protocol which does not deal in volume blocks but in file blocks
 > and/or by some out-of-band ACL-and-layout communication between the
 > metadata servers and the storage servers.  Yes.  But your slides, as I
 > recall, did not actually say this, did not mention the block-oriented-
 > storage-protocols-break-NFSv4-security-semantics-or-oob-protocols-are-
 > required matter and actually termed the security of pNFS "comparable" to
 > NFSv4's.
 > 
 > Now, that could well be a slip, a compression error if you wish
 > (slideshows make us do that), which we could ignore.  BUT, you must at
 > least specify a required, implementable and deployable configuration
 > which has security properties which are truly comparable to NFSv4's.
 > 
 > > About the object security model.  First, yes, this is different.  It
 > > comes from Howard Gobioff's thesis work.  It is designed to be 
something
 > > that is cryptographically strong yet simple to enforce at the storage
 > > device.  The pNFS extension is not mandating that a new security model
 > > be used by NFSv4.  But, ideally, the pNFS extension would support the
 > > use of this security model when OSD/iSCSI is used as the storage 
protocol.
 > > 
 > > The basic ideas are: the metadata server and the object storage devices
 > > share a secret key. Key provisioning is part of the storage management
 > > protocol and is out of scope of pNFS.  Next, when the metadata server
 > > returns a capability to a client, it also returns a signing key to
 > > the client.  When the client presents operations to the OSD (object
 > > storage device) it signs those commands with the signing key.  Plus,
 > > a timestamp nonce is included in the command to prevent replay attacks.
 > > Where this affects pNFS is that the signing key needs to be returned
 > > from the metadata server to the client through a secure channel. We
 > > can use the GSS infrastructure for this, but I think it places a new
 > > demand on the return path.
 > 
 > This is clearly not feasible with currently available off-the-shelf
 > iSCSI implementations, yet it is the existence of the such, it seems to
 > me, that spurs you to propose the use of iSCSI as the client<->storage
 > protocol for pNFS.
 > 
 > Cheers,
 > 
 > Nico
 > -- 
 > 

--
Brent Welch
Software Architect, Panasas Inc
Delivering the premier storage system for scalable Linux clusters

www.panasas.com
welch@panasas.com

_______________________________________________
nfsv4 mailing list
nfsv4@ietf.org
https://www1.ietf.org/mailman/listinfo/nfsv4