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

From: [email-masked]
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
[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 11:45:36 -0700

> 	are used.  IPsec *does not* perform DNS lookups at runtime, period.

But users use names, not IP addresses, so DNS is in the picture.

> 	a host that's not an NFS server?

If the MITM has certs and the client thinks it's talking to the right
server when, in fact, it's talking to the MITM, then you have a problem.

This problem crops up in Kerberos too because some implementations use
DNS to canonicalize host principal names.

MITMs are not defeated just by throwing in mutual authentication bound
to a DH key exchange - if the client can be fooled into talking to the
wrong server by another that has valid certs then there is still a MITM
problem.

> and a good IPsec implementation will allow that black-holing to be

You might as well go back to distributing /etc/hosts then.

> this DNS spoofing attack against IPsec is essentially impossible.

I grant you that IPsec does not itself use IPsec, 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).

Meanwhile, the client uses the correct name ("host/server@<server's realm>)
to talk to the server at the RPCSEC_GSS/GSS-API layer.

So an attacker with control over a host with valid IPsec certs can try
(and maybe succeed) to spoof the DNS response to the client and get the
client to connect to it (the attacker) instead of the server; an IPsec
SA is established between the client and attacker.  Then the attacker
connects to the server and starts forwarding to the server all traffic
sent by the client to the attacker and all traffic sent back to the
attacker by the server back to the client.  The attacker is an MITM;
now, the client thinks "IPsec is taking care of everything, so let's do
no session crypto at the NFS/RPCSEC_GSS layer" and now the MITM can do
whatever he/she wants.

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

[**]  Sam and Tom are definitely experienced members of the security
      community; if they aren't then I don't know who is.  Counting
      myself that makes three members of the security community who've
      now pointed out the MITM problem I describe above [Tom did so
      off-line, not on the list].

> of IPsec applied to NFS w/CCM.  The latter is essentially a circular

When did I argue that it was our desire to support anon IPsec that made
CCM insecure?  See the attack example above.  What I have done is
pointed out that the same solution to the MITM attack described above
also happens to enable use of anon IPsec, a desirable feature.  There
are then two reasons for channel bindings to IPsec: MITM avoidance and
enabling of use of anon IPsec w/ NFS w/ RPCSEC_GSS.

Cheers,

Nico
--