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

From: "Halevy, Benny" <[email-masked]>
Date: Thu, 11 Nov 2004 04:51:16 -0500

Mike Eisler wrote:
> 
> William A.(Andy) Adamson wrote:
> 
> >> My comments are around the security area.
> >> 
> >> It isn't clear why new authentication systems are being invented
> >> here, when we alread have one: ONC RPC authentication flavors, and
> >> specifically, RPCSEC_GSS. The i-d needs to justify its direction.
> > 
> > i don't get what you mean. new authentication systems are 
> not being invented. 
> 
> Capabilities are new to NFSv4, so new systems are being invented.

Capabilities are mentioned in the context of object storage.
For pNFS over files it is mentioned as "One alternative that was briefly
discussed was the introduction of special file handles that essentially
have the properties of capabilities"

> 
> > the intent is to use and existing storage protocol security 
> features, 
> > including rpcsec_gss when present (not block layout, not 
> OSD layout, only file 
> > layout).
> 
> I didn't see a statement in the i-d that file layout would use
> RPCSEC_GSS (no mention of RPCSEC_GSS at all).

I understand that requirement for NFSv4 based data servers but
I can easily imagine someone wanting to cut the cost of the
data servers and run NFSv3 on them rather than NFSv4.

> 
> 
> >> Requiring IPsec to protect the capabilities strikes me as
> >> overkill.
> >> 
> >> Why doesn't the protocol assign each user a session key
> >> known to metadata server and OSD, and then use the session
> >> key to compute an HMAC on some or all of the messages?
> >> GSS-API would be the ideal way to wrap an HMAC.
> > 
> > ok - but using an HMAC is a change to the storage protocol, 
> the use of ipsec 
> > is not.
> 
> IPsec authenticates coarse grained entities, ONC RPC authenticates
> fine grained entities.
> 
> That the storage protocol apparently cannot authenticate fine 
> grained entities
> is not an excuse for accepting weaker security in NFSv4. We 
> spent many years
> in the NFSv4 working group establishing that fine grained 
> authentication
> was the way we would go, and now we are being presented with 
> arguments that
> because other protocols can't do fine grained, NFS security should be
> watered down.
> 
> >> >   One alternative that was briefly discussed was the introduction
> >> >   of special file handles that essentially have the properties of
> >> >   capabilities so they can be generated by the metadata 
> servers and
> >> >   checked by the data servers.  (Peter Corbett described 
> "one shot"
> >> >   file handles.)  To be effective, these need all the 
> properties of a
> >> >   capability so the data server can efficiently and 
> securely enforce
> >> >   the access control decisions made by the metadata manager.
> > 
> > i don't see a need for special file handles, or to discuss 
> capabilities in the 
> > file layout case.
> 
> Well you co-authored this i-d, and it is mentioned. :-)
> 
> >> Here I can accept that RPCSEC_GSS-like system 
> authenticating a blocks protocol
> >> isn't going to happen, mostly because blocks protocols have no
> >> provision for real authentication. That said, at the 
> recent NAS conference,
> >> when the issue was raised, I thought I'd understood Brent Welch
> >> to say that capabilities could be added to the blocks protocol.
> >> If so, couldn't a capability, mutually signed by the 
> metadata server and the NFS
> >> server, could be used?
> >> 
> > 
> > we can certainly influence storage protocols so that they 
> play better with pNFS 
>  > security, but at the end of the day, we take what we get 
> which in the current
> > block world is nothing. adding a capabilty to the block 
> protocol is outside the 
>  > scope of pnfs. running the block protocol over ipsec is 
> once again a consideration.
> 
> First, this is inconsistent with what Brent W stated at the 
> NAS conference.
> Second, IETF owns the iSCSI storage protocol, and it is 
> certainly within IETF's
> power to re-define (in a backwards compatible manner) iSCSI 
> so that we get more
> than nothing. If you were thinking Fibre Channel, yes, 
> there's probably
> nothing we can do there (but we once thought we couldn't do 
> ONC RPC over RDMA
> with RPCSEC_GSS and we were proven wrong), but by the same 
> token, if pNFS is to be a standards
> track protocol, its relationship with FC is also absolutely 
> nothing. Implementors
> of pNFS who want to support FC can do so, but such 
> implementations have
> nothing to do with the pNFS standard.

I'm all for improving the security mechanisms possible with
pNFS and have the infrastructure in the protocol to allow
such extensions in the future, if possible without revising
the protocol, but rather with versioning the storage protocol
variants.  I'd be careful not to raise the bar too high initially
though.  It is a big win if we can have pNFS working with standard
protocols available today.

> 
> So I think the pNFS work needs to include in its charter the 
> necessary extensions
> to the blocks protocols IETF owns in order to maintain 
> NFSv4's current authentication
> model. 

Agreed.

> Otherwise, we might as well specify AUTH_SYS as 
> mandatory to implement, since
> for all intents in purposes, that's the strength of 
> authentication the current
> pNFS i-d is offering.
> 
> 
> _______________________________________________
> nfsv4 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/nfsv4
> 

_______________________________________________
nfsv4 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nfsv4

---

From: Mike Eisler <[email-masked]>
Date: Thu, 11 Nov 2004 05:34:21 -0800

> have the properties of capabilities"

Which WG is standardizing object storage? Where can one examine the
protocol specifications?

> data servers and run NFSv3 on them rather than NFSv4.

RPCSEC_GSS runs on NFSv[234]. I've kind of given up repeating this
fact outside the WG, since Kerberos V5 is never associated with
NFSv3 among NFS users, but I still have hope the working group
members will understand this someday. :-)

Anyway, the i-d starts off as:

  "The pNFS extension to NFSv4 takes the form of new operations that
   return data location information called a "layout"."

The i-d specifies a bunch of new operations. How are these
operations going to be added to NFSv3? New procedures? What
if someone else decides they want to add new procedures with
the same numbers?

---

From: Julian Satran <[email-masked]>
Date: Thu, 11 Nov 2004 20:02:06 -0500

Object Storage is standardized by T10 (the SCSI working group). The 
technical work is being done in the SNIA Object Storage technical working 
group.
The first version is already out and public (according to the rules you 
have to buy a hardcopy from a publishing compnay appearing on the 
organization website.
You can also find "drafts" that are close to the spec (up to the date and 
number :)) at http://www.t10.org

Julo

Mike Eisler <[email-masked]> 
Sent by: [email-masked]
11/11/04 08:34

To
"Halevy, Benny" <[email-masked]>
cc
"William A.\(Andy\) Adamson" <[email-masked]>, [email-masked]
Subject
Re: [nfsv4] comments on draft-welch-pnfs-ops-00.txt

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 11 Nov 2004 22:53:36 -0600

> data servers and run NFSv3 on them rather than NFSv4.

NFSv3 supports RPCSEC_GSS.

[...]
> protocols available today.

I think the IETF and IESG ought to have some policy with respect to
this sort of thing.  I'm not sure if or that there is one. Perhaps an AD
can explain this to us.

Nico
--