Subject: Re: [nfsv4] FW: Minorversion2 - inter-server copy security concern

From: "Haynes, Tom" <[email-masked]>
Date: Tue, 27 Dec 2011 16:26:07 +0000

I've applied these changes such that they will appear in the next draft version.

On Nov 25, 2011, at 7:45 PM, <[email-masked]>
 <[email-masked]> wrote:

> Fixing a typo that got away ...
> 
> Thanks,
> --David
> 
> 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
>                    ^
> a ------------------/
> 
>   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
> ----------------------------------------------------
> _______________________________________________
> nfsv4 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nfsv4
> 
> _______________________________________________
> nfsv4 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nfsv4