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

Black_David@emc.com

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

Replying to my own post ...

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

I found the fly in the ointment - per RFC 2401, the port selector
support in the IPsec SPD that's needed to do this is optional (MAY
be supported), so there's no guarantee that an IPsec implementation
will be able to do this, although the mechanisms are specified to
do so.  If this support is not present, and the MITM attack is
a risk, then channel bindings are needed to counter it.  It may
be possible to make this port selector support mandatory when
CCM is used with IPsec.

Sorry/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
----------------------------------------------------

> -----Original Message-----
> From: Black_David@emc.com [mailto:Black_David@emc.com]
> Sent: Tuesday, May 13, 2003 5:50 PM
> To: Nicolas.Williams@sun.com
> Cc: nfsv4@ietf.org
> Subject: RE: [nfsv4] Re: Comments on CCM draft -00
> 
> 
> 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
> 
_______________________________________________
nfsv4 mailing list
nfsv4@ietf.org
https://www1.ietf.org/mailman/listinfo/nfsv4