Subject: [nfsv4] NFSv4 discussions in Berlin (or not)

From: "Noveck, David" <[email-masked]>
Date: Sun, 5 May 2013 10:39:08 -0400

It seems to me that we should be discussing  what we want to talk about at IETF87.  I know that it is strange to be working on this so far in advance, but it appears to me that if we don't have that discussion pretty soon, there will be no nfsv4 meeting at IETF87.  My feeling is that most of the members of the working group would not find that a very good outcome but I'm prepared for people to tell me that they are happy/OK with this result.

Later I'll get back to some of the lead-time issues that lead me to my conclusion above. There may be some confusion about how and when we will decide on this.  In fact I know that there is some confusion about this, since I know I'm confused about it.  Maybe others are as well.

If I recall correctly,  some of this confusion arose when Spencer announced (on behalf of him and Beepy) that the working group co-chairs would monitor the working group list and then on the basis of list activity decided, on a basis never made clear , whether we would meet in Berlin.

I then raised the issue of when this decision would be made.  I was concerned about airline booking and corporate travel approval lead times.  Given that each of these might well be a month, I figured we would  need a decision about two months before the travel date.  That would mean a decision by 5/27.  While not committing to any particular time frame, Spencer assured me that my concerns would be addressed.  Although we haven't heard from Beepy on the matter, I presumed that he agreed with that.

Then a number of people raised the question of the role of working group consensus on a decision of this sort.  For example, Marc Eshel wrote:

> I think that it should be something that is decided by consensus, like every thing else that this
> group does. Maybe when the time comes the agenda can be posted and the group can agree
> if we need a meeting or not.

This left open a number of questions regarding the process by which  the agenda proposal that the group would decide about would be arrived at.  In the circumstances, the length of that process is a concern.  Without getting into the detail, let me just say that assuming an agenda can be arrived at instantaneously seems unduly optimistic :-).   Since the working group was not prepared to tackle those process issues at the time, I mentally just put whole matter aside for a while, thinking that those issues might somehow be addressed in the future.   So far they haven't been.

As it is now just about three weeks from the presumed decision  point, I think it is time for the working group to talk about the substantive issue (i.e. "What do we want to talk about?") ASAP.   I think we are best off if we avoid discussing procedural/process issues as I'm fearful  that might get us into U.S.-Senate-mode. After all, the nfsv4 working group is also a "continuing body" with rules of procedure not structured to encourage quick decisions.  Sigh :-(

So I'm asking everybody to tell us what they would like discussed at an nfsv4 working group meeting at IETF87.  Also, I'd like people who would be prepared to present something or lead a short discussion at IETF87 to identify themselves and specify the proposed subject.  Let's have that discussion on the working group list in the next week or so and see if there is a rough match between the discussions people want to lead and those they want to participate in and listen to, but if not, let's find that out now.  I expect this to be an interactive process.

I'll be sending my own contribution to this proposed discussion in the next few days.

---

From: Spencer Shepler <[email-masked]>
Date: Sun, 5 May 2013 15:26:42 +0000

To the question of what the working group has to discuss, there are 4 active working group documents.
They all need review and issues brought to the working group alias so that the authors can address the issues and make updates.
They are listed below.

The most critical one is the RPCSEC GSSv3 work.  It is imperative that this move forward in support of the NFSv4.2 work.

-          Remote Procedure Call (RPC) Security Version 3   (draft-ietf-nfsv4-rpcsec-gssv3-04.txt)

-          NFSv4 migration: Implementation experience and spec issues to resolve (draft-ietf-nfsv4-migration-issues-03)

-          NFSv4.0 migration: Specification Update (draft-ietf-nfsv4-rfc3530-migration-update-01)

-          NFSv4 Multi-Domain FedFS Requirements (draft-adamson-nfsv4-multi-domain-federated-fs-reqs-02)

Then we have a couple of personal I-Ds that are that need comment and review as well.

-          pNFS Metadata Striping (draft-mbenjamin-nfsv4-pnfs-metastripe-00)

-          Parallel NFS (pNFS) Lustre Layout Operations (draft-faibish-nfsv4-pnfs-lustre-layout-04)

Finally, Chuck has posted a couple of questions about FedFS security concerns.  There has been very little feedback on his proposals/findings. Anyone else have comments?

Spencer

---

From: "Noveck, David" <[email-masked]>
Date: Sun, 5 May 2013 13:16:54 -0400

As far as the IETF 87 meeting discussion, I'd like everyone to look at Spencer's list, and make sure to mention the documents for which you think that a face-to-face discussion would be helpful.    It isn't necessary to mention all the documents you don't want to discuss.  Also, if you are intending to submit an individual draft on some subject before the IETF87 deadline, please describe the expected document.

From: [email-masked] [mailto:[email-masked]] On Behalf Of Spencer Shepler
Sent: Sunday, May 05, 2013 11:27 AM
To: nfsv4 list ([email-masked])
Cc: [email-masked]
Subject: Re: [nfsv4] NFSv4 discussions in Berlin (or not)

Spencer

---

From: "Touretsky, Gregory" <[email-masked]>
Date: Sun, 5 May 2013 19:03:31 +0000

We're working now on RPCSEC GSS adoption in the NFSv3 production environment - this has multiple challenges, which I assume will be similar with NFSv4/KRB implementation:

*         Ticket management for cron jobs / faceleless accounts - we're developing secure keytab management service for this purpose

*         Samba integration with NFS/KRB mounts

*         Ticket handling in the pam configuration

*         Ticket transfer with our batch scheduling system

*         Co-existence of AUTH_SYS and RPCSEC_GSS mounts in the environment - we have to preserve for some mounts legacy 16GIDs/user limits, and allow >16 GIDs for KRB mounts

*         And more

I wonder if an overview of these challenges and solutions would be interesting for this forum?
Gregory Touretsky
Engineering Computing - Strategic Architecture and Planning
Solutions Architect
gregory.touretsky AT intel.com
(+) 972-4-865-6377, Fax: 04-865-5999
iNET: 465-6377

From: [email-masked] [mailto:[email-masked]] On Behalf Of Spencer Shepler
Sent: Sunday, May 05, 2013 18:27
To: nfsv4 list ([email-masked])
Cc: [email-masked]
Subject: Re: [nfsv4] NFSv4 discussions in Berlin (or not)

Spencer
---------------------------------------------------------------------
Intel Israel (74) Limited

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

---

From: Benjamin Kaduk <[email-masked]>
Date: Sun, 5 May 2013 15:54:38 -0400 (EDT)

On Sun, 5 May 2013, Touretsky, Gregory wrote:

> We're working now on RPCSEC GSS adoption in the NFSv3 production 
> environment - this has multiple challenges, which I assume will be 
> similar with NFSv4/KRB implementation:
>

MIT krb5 1.11 brings the concept of a default initiator (client) keytab 
location [1], which is subject to parameter expansion in krb5.conf [2].
This allows a per-user keytab to be placed in a user-owned directory, and 
is intended to support cron jobs and long-running processes.  Whereas 
'kinit -k' uses the default system keytab (i.e., /etc/krb5.conf), 'kinit 
-k -i' will use the client keytab, which could be configured as (say) 
/var/cache/kerberos/${USER}/krb5.keytab .  Of course, in a cluster 
environment things will be more complicated, but perhaps this would be a 
useful building block.

-Ben Kaduk

[1] 
http://web.mit.edu/kerberos/krb5-latest/doc/admin/conf_files/krb5_conf.html#libdefaults 
the "default_client_keytab_name" entry
[2] 
http://web.mit.edu/kerberos/krb5-latest/doc/admin/conf_files/krb5_conf.html#parameter-expansion

---

From: "Erasani, Pranoop" <[email-masked]>
Date: Sun, 5 May 2013 20:07:57 +0000

Gregory,

Yes, the challenges in this space would definitely be interesting to explore. I would be more than happy to participate in any conference call related to this.

-        Pranoop

---
Pranoop Erasani | Technical Director, NFS | NetApp | W: 408-822-3282 | C:  408-306-2928

From: [email-masked] [mailto:[email-masked]] On Behalf Of Touretsky, Gregory
Sent: Sunday, May 05, 2013 12:04 PM
To: Spencer Shepler; nfsv4 list ([email-masked])
Cc: Touretsky, Gregory; Pawlowski, Brian
Subject: Re: [nfsv4] NFSv4 discussions in Berlin (or not)

*         And more

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Spencer Shepler
Sent: Sunday, May 05, 2013 18:27
To: nfsv4 list ([email-masked]<mailto:[email-masked]>)
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [nfsv4] NFSv4 discussions in Berlin (or not)

Spencer

---

From: Nico Williams <[email-masked]>
Date: Sun, 5 May 2013 23:43:41 -0500

On Sun, May 5, 2013 at 2:03 PM, Touretsky, Gregory
<[email-masked]> wrote:
> We’re working now on RPCSEC GSS adoption in the NFSv3 production environment
> – this has multiple challenges, which I assume will be similar with
> NFSv4/KRB implementation:
>
> ·         Ticket management for cron jobs / faceleless accounts – we’re
> developing secure keytab management service for this purpose

Every shop does this.  In fact, there are several open source tools
you can use to avoid re-inventing this wheel:

 - Roland Dowdeswell's krb5_admin and krb5_keytab
(https://github.com/elric1?tab=repositories)
 - Russ Allbery's wallet (http://www.eyrie.org/~eagle/software/)

> ·         Co-existence of AUTH_SYS and RPCSEC_GSS mounts in the environment
> – we have to preserve for some mounts legacy 16GIDs/user limits, and allow
>>16 GIDs for KRB mounts

RPCSEC_GSSv3 handles this.  This is very important for, for example,
diskless clients using NFSv4 for / and any other filesystems that the
client might "own": in these cases the client absolutely must be able
to specify "filesystem-level credentials" in detail, and in a way that
is compatible with the way NFSv4 deals with user and group names in
ACLs.

RPCSEC_GSSv3 has three motivations:

 - diskless clients and least privilege
 - labeling
 - compound authentication (to protect the client from its users and
to provide extra privileges to users in filesystems owned by the
client when the client says the users have extra privs)

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Sun, 5 May 2013 23:45:57 -0500

On Sun, May 5, 2013 at 10:26 AM, Spencer Shepler <[email-masked]> wrote:
> The most critical one is the RPCSEC GSSv3 work.  It is imperative that this
> move forward in support of the NFSv4.2 work.

Agreed.  Are there implementations?  Deployments?

Nico
--

---

From: Spencer Shepler <[email-masked]>
Date: Mon, 6 May 2013 04:51:07 +0000

Excellent questions, Nico.  What has been the implementation experience?  I know there was input from EMC work early on.  Any others or an update from the EMC experiences would be helpful.  What do we have left for the document, Tom (or others)?

Spencer

-----Original Message-----
From: Nico Williams [mailto:[email-masked]] 
Sent: Sunday, May 5, 2013 9:46 PM
To: Spencer Shepler
Cc: nfsv4 list ([email-masked]); [email-masked]
Subject: Re: [nfsv4] NFSv4 discussions in Berlin (or not)

On Sun, May 5, 2013 at 10:26 AM, Spencer Shepler <[email-masked]> wrote:
> The most critical one is the RPCSEC GSSv3 work.  It is imperative that 
> this move forward in support of the NFSv4.2 work.

Nico
--

---

From: "Touretsky, Gregory" <[email-masked]>
Date: Mon, 6 May 2013 16:22:59 +0000

We've decided to leverage our existing AD infrastructure, and not introduce an extra KDC infrastructure.
As far as I remember, this makes both tools  you're referring to not applicable. We're developing something similar - to support integration with AD

As for the groups - for various reasons, we're staying with NFSv3 right now. To allow mix of SYS and KRB mounts and address the group limits, we're implementing secondary NIS domain with subset of maps (such as netid.*, etc) - which will be used by our file servers. The idea is to limit users with 16 groups only in the client-facing domain, but open it up in the file server-facing one.
As a result, we'll have to address various issues related to setgroups()/setgid() calls - which make no difference for NFS access with KRB mounts.

-----Original Message-----
From: Nico Williams [mailto:[email-masked]] 
Sent: Monday, May 06, 2013 07:44
To: Touretsky, Gregory
Cc: Spencer Shepler; nfsv4 list ([email-masked]); [email-masked]
Subject: Re: [nfsv4] NFSv4 discussions in Berlin (or not)

On Sun, May 5, 2013 at 2:03 PM, Touretsky, Gregory <[email-masked]> wrote:
> We’re working now on RPCSEC GSS adoption in the NFSv3 production 
> environment – this has multiple challenges, which I assume will be 

Every shop does this.  In fact, there are several open source tools you can use to avoid re-inventing this wheel:

> – we have to preserve for some mounts legacy 16GIDs/user limits, and 

RPCSEC_GSSv3 handles this.  This is very important for, for example, diskless clients using NFSv4 for / and any other filesystems that the client might "own": in these cases the client absolutely must be able to specify "filesystem-level credentials" in detail, and in a way that is compatible with the way NFSv4 deals with user and group names in ACLs.

 - diskless clients and least privilege
 - labeling
 - compound authentication (to protect the client from its users and to provide extra privileges to users in filesystems owned by the client when the client says the users have extra privs)

Nico

---

From: Nico Williams <[email-masked]>
Date: Mon, 6 May 2013 12:20:53 -0500

> As far as I remember, this makes both tools  you're referring to not applicable. We're developing something similar - to support integration with AD

To some degree it does, but not entirely.  You might extend one (or
both) of those tools.

In any case, supplying automation client principals with tickets is
something you could use S4U2Proxy for, in the AD case, and it's
something we should use S4U2Proxy for in all cases.  As for supplying
keytabs... krb5_admin can really help with the cluster update race
conditions.

> As a result, we'll have to address various issues related to setgroups()/setgid() calls - which make no difference for NFS access with KRB mounts.

Hmmm, do we need RPCSEC_GSSv3 to support NFSv3 usage by supporting
numeric UID/GIDs?  But then, it already does: just send stringified
UIDs/GIDs.

So I insist: RPCSEC_GSSv3 is the solution that you're looking for here.

Nico
--

---

From: "Touretsky, Gregory" <[email-masked]>
Date: Tue, 7 May 2013 15:52:32 +0000

I'll be talking about it at http://snia.org/spdecon  on June, 12th

From: Erasani, Pranoop [mailto:[email-masked]]
Sent: Sunday, May 05, 2013 23:08
To: Touretsky, Gregory; Spencer Shepler; nfsv4 list ([email-masked])
Cc: Pawlowski, Brian
Subject: RE: NFSv4 discussions in Berlin (or not)

Gregory,

-       Pranoop

---

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Touretsky, Gregory
Sent: Sunday, May 05, 2013 12:04 PM
To: Spencer Shepler; nfsv4 list ([email-masked]<mailto:[email-masked]>)
Cc: Touretsky, Gregory; Pawlowski, Brian
Subject: Re: [nfsv4] NFSv4 discussions in Berlin (or not)

*         And more

Spencer

---

From: David Quigley <[email-masked]>
Date: Fri, 10 May 2013 20:20:45 -0400

On 05/06/2013 00:45, Nico Williams wrote:
> _______________________________________________
> nfsv4 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nfsv4

The only implementation we have right now is bit rotted and is from the 
guys at Cobham that you have worked with in the past. I've given the 
patches to people to see what they can do. Hopefully someone will get 
them working again.

Dave

---

From: Spencer Shepler <[email-masked]>
Date: Sat, 11 May 2013 00:28:41 +0000

Thanks, Dave.  Do you recall if there were any discrepancies between the implementation and the I-D that existed at that point?

Spencer

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Davidgley
Sent: Friday, May 10, 2013 5:21 PM
To: [email-masked]
Subject: Re: [nfsv4] NFSv4 discussions in Berlin (or not)

On 05/06/2013 00:45, Nico Williams wrote:
>> The most critical one is the RPCSEC GSSv3 work.  It is imperative 
>> that this move forward in support of the NFSv4.2 work.
>

The only implementation we have right now is bit rotted and is from the guys at Cobham that you have worked with in the past. I've given the patches to people to see what they can do. Hopefully someone will get them working again.

Dave

---

From: David Quigley <[email-masked]>
Date: Fri, 10 May 2013 20:42:08 -0400

Unfortunately I do not. It was thrown over the wall to me. It was 
started on contract for me when I was still at the agency and finish 
after I had left. I asked my previous co-workers there to give me the 
patches when they arrived and I got a code dump for it along with an 
email. I can make it available to whomever is willing to put the time 
and effort into updating the patches and working on them. I'd imagine 
they still need the original attribution for inclusion in the respective 
upstream code bases.

Dave

On 05/10/2013 20:28, Spencer Shepler wrote:
> Thanks, Dave.  Do you recall if there were any discrepancies between
> the implementation and the I-D that existed at that point?
>
> Spencer
>
> The only implementation we have right now is bit rotted and is from
> the guys at Cobham that you have worked with in the past. I've given
> the patches to people to see what they can do. Hopefully someone will
> get them working again.
>
> Dave

---

From: Spencer Shepler <[email-masked]>
Date: Sat, 11 May 2013 00:48:49 +0000

Thanks for the history.

Spencer
________________________________
From: David Quigley<mailto:[email-masked]>
Sent: ‎5/‎10/‎2013 5:42 PM
To: Spencer Shepler<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: RE: [nfsv4] NFSv4 discussions in Berlin (or not)

Dave