RE: [nfsv4] Re: Comments on CCM draft -00

Black_David@emc.com

From: Black_David@emc.com
Message-ID: <277DD60FB639D511AC0400B0D068B71E0564CC20@corpmx14.corp.emc.com>
Subject: RE: [nfsv4] Re: Comments on CCM draft -00
Date: Tue, 13 May 2003 17:49:45 -0400

Nico,

> I grant you that IPsec does not itself use DNS, it's the client
> application that [indirectly] initiates the IPsec SA that uses DNS.
> 
> So, here's a Solaris-specific (somewhat simplified) example:
> 
> Client					    Server
> ------					    ------
> 
> userland->kernel (chdir("/net/server/blah/"))
> kernel->autmountd
> automountd->mount
> mount[*]->DNS (resolve "server")
> mount[*]->server (connect)
> 
> 		[IPsec SA establishment]
> 
> mount[*]->gssd (gss_init_sec_context())
> mount[*]->server (context token)
> 
> 					    server->gssd (accept token)
> 					    server->client 
> (context token)
> ...		[GSS context establishment] ...
> mount->automountd (return)
> automountd->kernel (return)
> kernel->user (return)
> 
> [*] Parts of the mount may happen in the kernel, parts in user-land.
> 
> The one DNS operation above determines the IP address used by the client
> to reference the server, but the IPsec layer has NO WAY to determine if
> that really is what the client wants (the client wants "server", and
> really doesn't care about the IP address - IPsec knows nothing about the
> hostname, just the IP).

I agree, but what IPsec does know is the port on which the client
contacts the NFS server, and it can control traffic at port
granularity level.  Since simple administration is being emphasized
here, one IPsec SPD entry can stop the SA setup to the MITM.  That
entry requires that all traffic to/from the ports used by NFS
be over an SA authenticated to an IPsec identity whose keying
material is only installed on the real NFS servers.  That stops
IPsec SA setup to the MITM because the SPD entry requires an
authentication that the MITM cannot perform.  If one wants to
ensure at the IPsec level that NFS servers can't impersonate
one another, it costs an SPD entry per server to identify
each server's credentials.  To defeat the latter via DNS spoofing,
one has to have an IPsec config tool that is using DNS without
additional verification (not a great idea, but probably happens)
and attack that tool at the crucial moment when it is
being used to configure IPsec.

> If the problem is not clear by now, I don't know how to make it any
> clearer; perhaps Sam can put this more eloquently or in simpler terms
> (Sam Hartman and Tom Yu[**] first pointed out this attack to me at
> Cthon03, more or less concurrently with Dai Peng on the list).

And I hope it's equally clear that IPsec can be configured and
managed to prevent this MITM attack.  I understand that much of the
interest in anonymous IPsec is based on a desire to do as little
IPsec admin as possible (ideally none), and if one does not
administer/configure IPsec in a way that would prevent the MITM
attack, then it obviously becomes possible.  However, I disagree
with any assertion that this MITM attack is inherent in the
use of IPsec underneath NFS.  On that basis, I think all of
the requests for channel bindings come down to wanting to
simplify IPsec administration and/or deal with situations in
which IPsec administration has to be simplified and/or shouldn't
be trusted.  That set of arguments is ok with me, but the MITM
attack is not inherent to the use of IPsec. 

Thanks,
--David
----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
black_david@emc.com        Mobile: +1 (978) 394-7754
----------------------------------------------------
_______________________________________________
nfsv4 mailing list
nfsv4@ietf.org
https://www1.ietf.org/mailman/listinfo/nfsv4