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

From: [email-masked]
Date: Mon, 12 May 2003 15:23:14 -0400

Sam,

>     Nicolas> On Wed, May 07, 2003 at 09:04:26AM -0700, Nicolas
>     Nicolas> Williams wrote:
>     >>  1) CCM is dangerous without mandating the use of channel
>     >> bindings.
> 
>     Nicolas> So, I'd like to clarify this.  I think there needs to be
>     Nicolas> an option for channel bindings.  Around the time of this
>     Nicolas> past Connectathon I offered three options: negotiate no
>     Nicolas> bindings, negotiate network address channel bindings and
>     Nicolas> negotiate the use IPsec/... bindings.
> 
>     Nicolas> Negotiating no bindings and no session crypto can be
>     Nicolas> useful in some environments.
> 
> 
> I'd love to push for mandating the use of channel bindings.  I suspect
> I'd be alone in that desire.
> 
> What I do think is reasonable to require is that implementations must
> implement some real channel bindings.  If you want to turn it off, say
> because you have some box that you want to tap your traffic on, that's
> fine.
> 
> But I as a user want to have a guarantee that if I buy two CCM-capable
> devices that both support IPSEC, I can configure both devices to talk
> to each other using channel bindings.  To get this I need mandatory to
> implement channel bindings even if they are not mandatory to use.

Could you run through that last paragraph in a little more detail?
If one configures the IPsec on those two devices correctly and (more
importantly) only installs the IPsec keying material for the NFS/CCM
sessions on those two devices, then they can only set up IPsec SAs
for NFS/CCM to each other (in practice, IPsec will recognize NFS
via port usage, so this'll be NFS as opposed to NFS/CCM).  What
portion of this approach requires the higher assurance that channel
bindings provide?  The answer may involve scenarios with more
than two devices.

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 14:38:55 -0700

> bindings provide?  The answer may involve scenarios with more

"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?  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), then the attacker might be able to act
as a man-in-the-middle (MITM) between the client and the server who gets
all the plaintext and even gets to modify it (remember, one CCM notion
is to not use GSS-API MICs to secure the RPCSEC_GSS header, the part
that references the context handle).  Both, the client and the server
would see that IPsec is in use between them, but they would each see a
different ID for its IPsec peer.  Channel bindings are used to prove
that the client and server each see the same two peer names at the lower
(in this case, IPsec) layer, and therefore there is no MITM.

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.

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

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.

Cheers,

Nico
--

---

From: Sam Hartman <[email-masked]>
Date: Mon, 12 May 2003 17:47:58 -0400

>>>>> "Black" == Black David <[email-masked]> writes:

    Black> Could you run through that last paragraph in a little more
    Black> detail?  If one configures the IPsec on those two devices
    Black> correctly and (more importantly) only installs the IPsec
    Black> keying material for the NFS/CCM sessions on those two

But remember that you also have to configure GSSAPI correctly and set
up GSSAPI's keying even with IPSEC.  IETf protocols should only
require me to set up one keying infrastructure to get security.  I
think that ease of configuration is an important consideration in
whether a protocol will actually be secure as used.

If I mandate implementation of channel bindings, then I can make my
product easier to configure by only requiring that GSSAPI be set up
and then being lax in what I accept at the IPSEC level.

If I do not implement channel bindings then I force my users to
configure both IPSEC and GSSAPI correctly to get a secure configuration.

I've worked in enough organizations and managing to get one key
infrastructure deployed is hard enough.  If we can make a technology
choice--mandating channel bindings be implemented---that means I'm
still depending on only one key infrastructure for security, while
getting the performance advantages of hardware accelerated IPSEC, then
we should do that.