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

From: [email-masked]
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
[email-masked]        Mobile: +1 (978) 394-7754
----------------------------------------------------
_______________________________________________
nfsv4 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nfsv4

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 13 May 2003 15:43:24 -0700

> being used to configure IPsec.

If you have 100 NFS servers w/ IPsec, then an attacker that breaks
into one could use DNS spoofing to try to use that broken host as an
MITM for clients talking to the other 99 servers.  And you have
distribute all these policies where with GSS-API channel bindings you
don't.  You know, the DNS spoofing problem can go away if we go back to
distributing /etc/hosts ;)

> attack is not inherent to the use of IPsec. 

It's clear that what you propose does not scale and so is not an
acceptable solution.

My position is that CCM MUST offer the option to negotiate the use of
GSS-API channel bindings [to IPsec]; I don't believe we can mandate
support for the use of such bindings in NFSv4 so I won't insist on it.

I think that's reasonable - it's just an option.

Cheers,

Nico
--