Subject: [nfsv4] RPCSEC_GSSv3 and NFSv4.2

From: "Haynes, Tom" <[email-masked]>
Date: Sat, 10 Aug 2013 18:55:45 +0000

I want to summarize the WG discussion at Berlin and on the alias:

1) Spencer proposed in Berlin that we remove RPCSEC_GSSv3
as a dependency, which in turn would mean removing those features
in NFSv4.2 which had that dependency.

2) Bruce proposed on the WG alias to remove server-side LNFS
and inter-server SSC.

3) Tom proposed on the WG alias to remove server-side LNFS
and to mark inter-server SSC as experimental. The idea being
that we could ship NFSv4.2 as a protocol and the features later.

4) Mike propose on the WG alias that we remove RPCSEC_GSSv3
from NFSv4.2 and focus on:
3.4.1.3. Inter-Server Copy via ONC RPC but without RPCSEC_GSSv3
for inter-server copy.

5) Bruce strengthened this by proposing we add language to 
secure the URL in COPY_NOTIFT via " RPCSEC_GSS with privacy".

There are two clear consensuses:

1) We do not want to wait for RPCSEC_GSSv3 to be finished.

2) Server-side Labeled NFS can wait until a secure method to deliver
the object label is provided.

It is tough to hum on the WG alias, but I also believe we have seen
sufficient resistance to 1), 2), 3), and 4). I also believe that each
of these proposals is a refinement of the previous.

The proposal in front of us is this text, which replaces Section 3.4.1.2
of draft-ietf-nfsv4-minorversion2-19.txt:

3.4.1.2.  Inter-Server Copy via ONC RPC

   In the absence of a strong security mechanism designed for the
   purpose, the challenge is how the source server and destination
   server identify themselves to each other, especially in the presence
   of multi-homed source and destination servers.  In a multi-homed
   environment, the destination server might not contact the source
   server from the same network address specified by the client in the
   COPY_NOTIFY.  This can be overcome using the procedure described
   below.

   When the client sends the source server the COPY_NOTIFY operation,
   the source server may reply to the client with a list of target
   addresses, names, and/or URLs and assign them to the unique
   quadruple: <random number, source fh, user ID, destination address
   Y>.  If the destination uses one of these target netlocs to contact
   the source server, the source server will be able to uniquely
   identify the destination server, even if the destination server does
   not connect from the address specified by the client in COPY_NOTIFY.
   The level of assurance in this identification depends on the
   unpredictability, strength and secrecy of the random number.

   For example, suppose the network topology is as shown in Figure 3.
   If the source filehandle is 0x12345, the source server may respond to
   a COPY_NOTIFY for destination 203.0.113.56 with the URLs:

      nfs://203.0.113.18//_COPY/FvhH1OKbu8VrxvV1erdjvR7N/203.0.113.56/
      _FH/0x12345

      nfs://192.0.2.18//_COPY/FvhH1OKbu8VrxvV1erdjvR7N/203.0.113.56/_FH/
      0x12345

   The name component after _COPY is 24 characters of base 64, more than
   enough to encode a 128 bit random number.

   The client will then send these URLs to the destination server in the
   COPY operation.  Suppose that the 192.0.2.0/24 network is a high
   speed network and the destination server decides to transfer the file
   over this network.  If the destination contacts the source server
   from 192.0.2.56 over this network using NFSv4.1, it does the
   following:

   COMPOUND  { PUTROOTFH, LOOKUP "_COPY" ; LOOKUP
      "FvhH1OKbu8VrxvV1erdjvR7N" ; LOOKUP "203.0.113.56"; LOOKUP "_FH" ;
      OPEN "0x12345" ; GETFH }

   Provided that the random number is unpredictable and has been kept
   secret by the parties involved, the source server will therefore know
   that these NFSv4.x operations are being issued by the destination
   server identified in the COPY_NOTIFY.  This random number technique
   only provides initial authentication of the destination server, and
   cannot defend against man-in-the-middle attacks after authentication
   or an eavesdropper that observes the random number on the wire.
   Other secure communication techniques (e.g., IPsec) are necessary to
   block these attacks.

   Servers SHOULD reject COPY_NOTIFY requests that do not use RPCSEC_GSS
   with privacy, thus ensuring the URL in the COPY_NOTIFY reply is
   encrypted.  For the same reason, clients SHOULD send COPY requests to
   the destination using RPCSEC_GSS with privacy.

Does anyone object to this text or approach?

---

From: David Quigley <[email-masked]>
Date: Sat, 10 Aug 2013 15:40:29 -0400

Just one minor nit. In #2 under consensus I think you mean subject 
label. We already have the object label support without RPCSEC_GSSv3.

Dave

On 08/10/2013 14:55, Haynes, Tom wrote:
> _______________________________________________
> nfsv4 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nfsv4

---

From: "faibish, sorin" <[email-masked]>
Date: Sat, 10 Aug 2013 15:53:09 -0400

You beat me. I was just writing same email wondering if this means postpone LNFS in 4.2 as object label was already included. If you are correct I'm am happy. Thanks

./Sorin

Sent from my iPad

---

From: "Haynes, Tom" <[email-masked]>
Date: Sun, 11 Aug 2013 16:05:33 +0000

On Aug 10, 2013, at 12:40 PM, David Quigley <[email-masked]> wrote:

> Just one minor nit. In #2 under consensus I think you mean subject label. We already have the object label support without RPCSEC_GSSv3.
> 

client-side Labeled NFS means object label support
server-side Labeled NFS means subject label support

Yes - I was implying Bruce's proposal was to drop subject label support.

---

From: "J. Bruce Fields" <[email-masked]>
Date: Tue, 13 Aug 2013 09:35:58 -0400

> secure the URL in COPY_NOTIFT via " RPCSEC_GSS with privacy".

Actually, that was taken from the last two paragraphs of Mike's mail.

> sufficient resistance to 1), 2), 3), and 4).

I haven't see any objections to #4.  I also haven't seen any responses
other than mine (well, and David Noveck's--but he was just kidding
around.  I think).

So it could use another pair of eyes if possible.

--b.

> I also believe that each