Subject: [nfsv4] Soliciting next steps for RPCSEC_GSSv3

From: Spencer Shepler <[email-masked]>
Date: Wed, 15 May 2013 05:37:07 +0000

My copy-paste from another email thread is mildly inappropriate but I thought it best to continue this discussion under a separate topic to ensure that everyone has had a chance to comment (see thread content in question below).

The topic is completing the NFSv4.2 work and by association the RPCSEC_GSSv3 I-D.

As my original email noted, the NFSv4.2 I-D has a normative reference on the RPCSEC_GSSv3 I-D.

At this point, we have no editor for the RPCSEC I-D.

So the first order of business is that I am soliciting an editor for
http://tools.ietf.org/id/draft-williams-rpcsecgssv3-02.txt

You will note the I-D expired 18 months ago.

Second order of business is to decide whether to keep the dependency and if not, what can or should be done about it.

Bruce suggested three choices (enumerated below).

I am soliciting discussion on those choices (and if there are more).

Opinions?

Spencer

On Fri, May 10, 2013 at 08:37:28PM -0400, David Quigley wrote:

> On 05/09/2013 15:56, J. Bruce Fields wrote:

> >On Thu, May 09, 2013 at 07:30:59PM +0000, Spencer Shepler wrote:

> >>I will, again, take the opportunity to note that there is a

> >>normative reference in NFSv4.2 on this:

> >>[5]   Haynes, T. and N. Williams, "Remote Procedure Call (RPC)

> >>         Security Version 3", draft-williams-rpcsecgssv3 (work in

> >>         progress), 2011.

> >>If there is a desire to see NFSv4.2 move ahead to a published RFC,

> >>then either this dependency needs to be removed or it needs to move

> >>forward with NFSv4.2.

> >As far as I know, the rpcsecgssv3 draft isn't ready, and there's no

> >one working on implementation.  If that's accurate, I think we should

> >remove the dependency.

> >I'd be delighted to be corrected on either point.

> >--b.

> That no one is working on it is only partly true. The guys in

> singapore who were helping me with rebasing the LNFS patches for Linux

> before Steve Dickson took over were tasked with figuring out the

> RPCSEC_GSSv3 patches that I gave them. If anyone wants to spend time

> on those patches I'm glad to hand them over and have them work on

> them.

I can't volunteer for the development effort, but I'd like to take a quick look, thanks.

> They are against an older kernel and Linux userspace library and

> deamon but the ideas are probably still sound.

> For the initial implementation we have for Linux RPCSEC_GSSv3 isn't

> necessary. However I'm not sure what changes need to be made to the

> NFSv4.2 to say that process label transport will be handled later in a

> future RFC.

I think we just say process labels are future work.  I don't think removing references to RPCSEC_GSSv3 would be a big job.

Server-to-server looks harder; I guess we'd either:

                a) Give up for now on some of the requirements in the

                "Requirements for Secure inter-Server Copy" section.

                Specifically, "The specification MUST provide guidance for using

                NFSv4.x as a copy protocol", and "The specification MUST NOT

                mandate a trust relationship between the source and destination

                server."  Which leaves us having to tell the servers how to

                authenticate to each other.

                b) Specify only intra-server copy, leave inter-server for 4.3.

                c) Leave all of server-to-server copy for 4.3.

---

From: "Haynes, Tom" <[email-masked]>
Date: Wed, 15 May 2013 16:13:46 +0000

The issue with the RPCSEC I-D is that we do not know what is remaining to be done.

I do not like option c.

I do not like option b, in my mind that opens us up for the same type of issues we saw with migration.

We have existing implementations of server side copy that do not use RPCSEC_GSSv3. Whether the
mechanism is proprietary or NFSv4.x should not matter. So I do not like all of option a.

What I would like to see is that we keep enough in place such that when RPCSEC_GSSv3 is
delivered, we can produced a smaller document specific to all NFSv4.2+ implementations
that will allow it to be incorporated.

On May 14, 2013, at 10:37 PM, Spencer Shepler <[email-masked]<mailto:[email-masked]>> wrote:

_______________________________________________
nfsv4 mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/nfsv4

---

From: "J. Bruce Fields" <[email-masked]>
Date: Wed, 15 May 2013 15:39:56 -0400

> of issues we saw with migration.

Could you elaborate?

> We have existing implementations of server side copy that do not use
> RPCSEC_GSSv3.

Which implementations exactly are you referring to?

> Whether the mechanism is proprietary or NFSv4.x should not matter. So
> I do not like all of option a.

> What I would like to see is that we keep enough in place such that
> when RPCSEC_GSSv3 is delivered, we can produced a smaller document
> specific to all NFSv4.2+ implementations that will allow it to be
> incorporated.

So I think you're choosing some variant of option a), but I think the
details here are tricky.

--b.

> [email-masked]

---

From: "Haynes, Tom" <[email-masked]>
Date: Wed, 15 May 2013 20:58:03 +0000

>> of issues we saw with migration.

Just a rough feeling that if we leave out inter-server, by the time we get
back to it, we will find issues as implementations diverge from the spec.

> So I think you're choosing some variant of option a), but I think the

Yes, a variant of A.

And yes, tricky, but Spencer did ask for opinions.

I want us to deliver something that people can use and that can grow
to meet future security needs.

---

From: "J. Bruce Fields" <[email-masked]>
Date: Wed, 15 May 2013 17:08:23 -0400

> back to it, we will find issues as implementations diverge from the spec.

OK, so you're referring to the issues discussed e.g. in
http://tools.ietf.org/html/draft-noveck-nfsv4-migration-issues-00.

I still don't understand what you mean by "opens us up for the same type
of issues".

--b.