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

Black_David@emc.com

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

> > > MITM avoidance means making sure that the client and server are the
same
> > > at both layers, NFS and IPsec, but since the principal names at the
one
> > > layer can be [nay, are] radically different from the names at the
other,
> > > how can one be certain that there is no MITM at the IPsec layer before
> > > leaving it to IPsec to provide session protection to the NFS layer?
> > 
> > This is distrust in the IPsec configuration and key distribution.  Note
> > that if the MITM doesn't have the keying material for the NFS SAs, SA
> > setup with the MITM will fail because IKE won't authenticate.
> 
> No, this is distrust of DNS.  I don't think security here should rely on
> DNS security, even if DNSSEC were commonplace - that would merely be a
> mitigation.

This "distrust of DNS" characterization appears to be doubly incorrect:

- IPsec security *does not* rely on DNS security.  There are no DNS
	names in the IPsec Security Policy Database (SPD), as IP addresses
	are used.  IPsec *does not* perform DNS lookups at runtime, period.
- For an MITM attack to succeed, the keying material for the IPsec
	SA has to be on the MITM host - that is indicative of a security
	problem elsewhere (e.g., bad policy, bad key distribution, or
	outright breach).  I missed the assumption about how the MITM
	host gets the required keying material - how did DNS spoofing
	cause IPsec keying material for an NFS server to be put onto
	a host that's not an NFS server?

Just to make matters more interesting, if the NFS configuration is static
and locked down by security policy (i.e., all the NFS servers are known,
and it is not legit to add another one without having the security admin
change the IPsec client configs), it is possible to configure the IPsec
SPD so that it will stop a DNS spoofing attack that succeeds at the NFS
level (i.e., NFS is convinced to access the wrong IP address for a mount
point).  In this situation, IPsec can be configured to black-hole the
IP traffic that to that bogus "NFS server" (based on port and IP address),
and a good IPsec implementation will allow that black-holing to be
audited.  

Getting back to DNS, in order for DNS spoofing to affect IPsec, some
IPsec config tool has to be using DNS to obtain the IP addresses for
use in IPsec configuration.  The attacker has to know when IPsec is
being configured, and has that small opportunity to try a DNS spoofing
attack.  After the configuration is done, DNS spoofing does not affect
IPsec.  A good security admin/policy and tools will verify the IP
addresses used to configure IPsec rather than just trusting DNS, and
if IPsec client configs are centrally managed (good practice), created
centrally and installed into clients without change (also good practice)
this DNS spoofing attack against IPsec is essentially impossible.

[ ... large snip, as it appears to me that Nico's discussion of MITM
	is be based on the incorrect assumption that DNS spoofing
	can affect IPsec at runtime ...]

> > OTOH, channel bindings avoid the dependence on whether "security
> > administration is done right", and one could argue that a typical
> > NFS administrator may not have the skills (or patience) required
> > to properly configure and administer IPsec.
> 
> Sam argues, and I agree, that one should not have to deploy an IPsec
> infrastructure (i.e., PKI and host certs) just to be able to reduce the
> number of GSS contexts established and used by NFS clients and servers.

Neither a full PKI nor host certs are needed.  Pre-shared keys get the
job done, and self-signed certificates provide a somewhat better version
of pre-shared keys, but one has to set up the SPD to identify and
restrict acceptance of the self-signed certs.  OTOH, I agree that the
"anonymous IPsec" route simplifies IPsec configuration even by comparison
to this.

[ ... anonymous IPsec description snipped ...]

As I said before, I don't have a problem with a discussion of
anonymous IPsec, but I would prefer to see the discussion be about
level of requirement for its use with NFS, rather than what appeared
to be the use of anonymous IPsec's existence (using it is always a
conscious security policy decision) to argue the general insecurity
of IPsec applied to NFS w/CCM.  The latter is essentially a circular
argument; a security policy decision has been made not to use IPsec
securely, so it should be no surprise that the result is insecure
(when one deliberately points the gun at one's own foot, the
resulting hole should not come as a surprise :-) ).

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