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

From: [email-masked]
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
[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: Mon, 12 May 2003 16:10:46 -0700

> 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 assumes that the client's IPsec configuration has been compromised.

It does not.  The client need not be compromised if all you're trying to
do is spoof DNS server replies to it.

> Why is that easier to compromise than the NFS/RPSEC_GSS configuration?

N/A.

> 	in use, get a real security administrator ...

Granted, but DNSSEC is not yet is widespread use.

> 	right, and hence IPsec SA setup with the attacker's box will

I did write "... suppose further that the attacker can fool the client's
IPsec layer without also fooling its NFS/RPCSEC_GSS layer..."  Whether
or not that is possible depends on how DNS lookups are done by the
client (if the client funnels all lookups through the same local cache
then this can't happen - or can it?  it can, but the attacker is forced
to try the spoofing only around the time of cache entry expiration ang
must get the timing right).

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

> level authentication, as Nico explains: 

Right, except that one would restrict the use of anonymous IPsec to
those services (i.e., ports) that can bind authentication at higher
layers to IPsec.

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

Yes, but I think the MITM point also holds.

We cannot make the use of a channel binding mechanism and channel
bindings to IPsec mandatory for NFSv4.x (because the extension model
forbids new mandatory features).  There's nothing wrong with specifying
this and highly recommending the use of channel bindings to IPsec when
CCM is used.

> 	security policy explicitly.

Again, it's not the IPsec configuration that is at issue, but the
possibility that an attacker could interpose itself at the IPsec layer
[through DNS spoofing or some similar vector] and not at the NFS layer.

> 	and have to be configured anyway) instead.

Yes.

> and hence has a considerably simpler SPD).

Pre-shared keys are a non-starter, I think, probably for most users.

> Such assertions are oversimplified to the point of being wrong.

Regardless of the anon IPsec feature I insist that channel bindings to
IPsec should be specified and recommended; I don't think that security
at this layer (NFS) should rely on getting anything other than the
GSS-API mechanisms' infrastructure working (yes, some Kerberos V
implementations today depend on DNS - this may change soon enough).

> may not get a wonderful reception in the security community.  The

Without channel bindings, yes.  With channel bindings there's no
problem.  I grant you that only a small section of the security
community has looked at this proposal, but certainly: a) the GSS-API
envisions this and the problem was considered, albeit more abstractly,
earlier by the security community and channel bindings were thought a
solution, b) CCM w/o the possibility of channel bindings is certainly a
bad thing.

> see draft-richardson-ipsec-opportunistic-11.txt for details.

That relies on the security of DNS, hence it's problematic.

Cheers,

Nico
--