Subject: [nfsv4] I-D Action: draft-ietf-nfsv4-minorversion2-06.txt

From: [email-masked]
Date: Mon, 14 Nov 2011 08:49:07 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network File System Version 4 Working Group of the IETF.

	Title           : NFS Version 4 Minor Version 2
	Author(s)       : Thomas Haynes
	Filename        : draft-ietf-nfsv4-minorversion2-06.txt
	Pages           : 95
	Date            : 2011-11-14

   This Internet-Draft describes NFS version 4 minor version two,
   focusing mainly on the protocol extensions made from NFS version 4
   minor version 0 and NFS version 4 minor version 1.  Major extensions
   introduced in NFS version 4 minor version two include: Server-side
   Copy, Space Reservations, and Support for Sparse Files.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-nfsv4-minorversion2-06.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-nfsv4-minorversion2-06.txt

---

From: <[email-masked]>
Date: Fri, 25 Nov 2011 20:42:46 -0500

I have a lingering issue with security for Inter-Server Copy via ONC RPC, but without
RPCSEC_GSSv3 - Section 2.4.1.3 of draft-ietf-nfsv4-minorversion2-06.txt .

The quick summary of the problem is that the URLs used to read the file out of
the source server is self-authenticating (anyone who knows the URL scan get the data),
and the URL is potentially predictable (anyone who can predict the URLs can get
the data, i.e., it's exposed).

The text change below adds a random number to the URL as a shared secret to address
this shortcoming.

2.4.1.3.  Inter-Server Copy via ONC RPC but without RPCSEC_GSSv3

   ONC RPC security flavors other than RPCSEC_GSSv3 MAY be used with the
   server-side copy offload operations described in this document.  In
   particular, host-based ONC RPC security flavors such as AUTH_NONE and
   AUTH_SYS MAY be used.  If a host-based security flavor is used, a
   minimal level of protection for the server-to-server copy protocol is
   possible.

   In the absence of strong security mechanisms such as RPCSEC_GSSv3,
   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.

OLD

   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 triple:
   <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.

   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 10.11.78.56 with the URLs:

      nfs://10.11.78.18//_COPY/10.11.78.56/_FH/0x12345

      nfs://192.168.33.18//_COPY/10.11.78.56/_FH/0x12345

   The client will then send these URLs to the destination server in the
   COPY operation.  Suppose that the 192.168.33.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.168.33.56 over this network using NFSv4.1, it does the
   following:

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

   The source server will therefore know that these NFSv4.1 operations
   are being issued by the destination server identified in the
   COPY_NOTIFY.

NEW

   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 10.11.78.56 with the URLs:

      nfs://10.11.78.18//_COPY/FvhH1OKbu8VrxvV1erdjvR7N/10.11.78.56/_FH/0x12345

      nfs://192.168.33.18//_COPY/FvhH1OKbu8VrxvV1erdjvR7N/10.11.78.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.168.33.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.168.33.56 over this network using NFSv4.1, it does the
   following:

   COMPOUND  { PUTROOTFH, LOOKUP "_COPY" ; LOOKUP "FvhH1OKbu8VrxvV1erdjvR7N" ;
      LOOKUP "10.11.78.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.1 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 ttacks 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. 

END

Thanks,
--David
----------------------------------------------------
David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
[email-masked]        Mobile: +1 (978) 394-7754
----------------------------------------------------