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

Black_David@emc.com

From: Black_David@emc.com
Message-ID: <277DD60FB639D511AC0400B0D068B71E0564CC1B@corpmx14.corp.emc.com>
Subject: RE: [nfsv4] Re: Comments on CCM draft -00
Date: Mon, 12 May 2003 18:44:16 -0400

Nico (and Sam),

> "What portion of this approach requires the higher assurance that
>  channel bindings provide?"
> 
> First, MITM attack avoidance.  Second, the ability to use 
> "anon IPsec."
> 
> 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.

> The answer is to use channel bindings, which, conceptually, are an
> exchange, at the NFS/GSS layer, of signatures of the principal names
> or session ID/keys involved at the IPsec layer.
> 
> Consider an attacker who can cause your client's IPsec stack to
> establish an SA with the attacker, instead of the server intended by the
> NFS layer, suppose further that the attacker can fool the client's IPsec
> layer without also fooling its NFS/RPCSEC_GSS layer, and suppose that
> the attacker's host is in your IPsec infrastructure (perhaps the
> attacker broke into that host)

This assumes that the client's IPsec configuration has been compromised.
Why is that easier to compromise than the NFS/RPSEC_GSS configuration?

[ ... rest of paragraph snipped, as I agree that channel bindings
	are helpful given that assumption, and question the assumption ...]

> Such an attack against RPCSEC_GSS w/ CCM w/o channel bindings sure
> seems, on the face of it, difficult to pull off, but is less farfetched
> than it seems.  DNS spoofing is the simplest attack vector for such an
> attack.

If DNS spoofing works, there are some serious security policy and/or
admin problems:
- If the contents of the IPsec SPD depend on DNS, and DNSSEC is not
	in use, get a real security administrator ...
- If DNS spoofing is used to change the IP address of the NFS mount
	point, and the risk to NFS was of sufficient concern, the IPsec
	SPD [Security Policy Database] should have specified the
	security credentials for the set of NFS servers or for each
	NFS server individually.  Those credentials will not be on
	the attacker's box if the security administration is done
	right, and hence IPsec SA setup with the attacker's box will
	fail.

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.

> But even conceding that such an attack is infeasible, there is still a
> wonderful use for channel bindings, namely that with channel bindings
> one could use anonymous IPsec and avoid the effort of distributing
> certs.  There is not such thing as "anonymous IPsec" - but the effect
> can be obtained by using self-signed certificates (credit for this:
> Radia Perlman).

In essence, that's a decision to accept any CA's signature whatsoever
(if Al Qaeda or the Taliban signs their own certificate, "anonymous
IPsec" will accept it).  The result is to neuter all IPsec
authentication (the result is *much* weaker than the group pre-shared
key authentication discussed previously on the list - about all that
one can conclude is that there's an operational IKE implementation on
the other end of the connection), at which point channel bindings are
necessary in order to bind the unauthenticated IPsec SA to the higher
level authentication, as Nico explains: 

> NFS w/ RPCSEC_GSS + channel bindings to anon IPsec is worth doing
> because it sacrifices none of the security normally afforded by
> RPCSEC_GSS while reducing the number of GSS-API contexts that 
> have to be established between clients and servers to one per
> {client, user, transport connection, server} tuple, and the
> number of GSS-API contexts that have to be used for MICs and wraps
> to zero.  And anon IPsec is cheap to setup since no PKI infrastructure
> is needed for it.
> 
> So, GSS-API authentication + CCM w/ channel bindings to IPsec +
> anonymous IPsec == pushing authentication up from the IPsec 
> layer to NFS and session crypto down from NFS to IPsec.

"anonymous IPsec" is also the essential point in Sam's response.

I'm not strictly opposed to channel bindings, but wanted to clarify
the problems they address.  There appear to be two such problems:
- Lack of trust that IPsec configuration is correct or immune
	from tampering by a hacker.  If NFS security is of particular
	concern, a correct IPsec SPD configuration will specify NFS
	security policy explicitly.
- A desire to simplify IPsec management by disabling IPsec authentication
	and binding to NFS's GSSAPI authentication (which will be there
	and have to be configured anyway) instead.

I'm skeptical of the first problem, as I think the distinction between
being unwilling to trust the correctness and integrity of IPsec
configuration, but having complete trust in the correctness and
integrity of the NFS RPSEC_GSS configuration is overwrought.  I've
also seen the PKI "red flag" waved - nothing described here requires
a PKI, as it can all be done via pre-shared keys or self-signed
certificates in combination with IPsec SPD configuration for which
keys or certs will be accepted for what purposes (in contrast to
"anonymous IPsec" which accepts all certificates for all purposes,
and hence has a considerably simpler SPD).

The second one ("anonymous IPsec") is a functionality request - if
one wants to do this, then channel bindings are necessary.  Discussion
of this might be better phrased in terms of the importance of
"anonymous IPsec" to NFS, rather than assertions that NFS
over IPsec is inherently insecure without channel bindings.
Such assertions are oversimplified to the point of being wrong.

Since "anonymous IPsec" completely neuters IPsec authentication, it
may not get a wonderful reception in the security community.  The
somewhat related concept of "opportunistic IPsec" which distributes
identity verification material via DNS (one had better use DNSSEC
if one wants to trust anything) has received a mixed reception -
see draft-richardson-ipsec-opportunistic-11.txt for details.

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