RE: [nfsv4] Comments on CCM draft -00

New Message Reply About this list Date view Thread view Subject view Author view Attachment view

From: Black_David@emc.com
Date: 05/09/03-04:59:30 PM Z


From: Black_David@emc.com
Message-ID: <277DD60FB639D511AC0400B0D068B71E0564CBFC@corpmx14.corp.emc.com>
Subject: RE: [nfsv4] Comments on CCM draft -00
Date: Fri, 9 May 2003 17:59:30 -0400

Folks,

> Telling those among us who can't change the IP stack "tough luck"
> is going to beg the rebuttal "how can iSCSI get by without channel
bindings?"
> (which as far as I can tell, aren't even optional ... at least the current
> i-d for CCM acknowledges their possibility).

Some of this reminds me of the tunnel mode vs. transport mode debate for
iSCSI and the other IPS protocols, which also got wrapped around the
end-to-end axle.  The eventual conclusion in that situation was that
end-to-end scope of a security association is primarily determined by
security policy, specifically which nodes have which credentials

In other words, to be specific about the iSCSI case, forcing the use
of transport mode to try to avoid introduction of intermediate security
gateways is the wrong way to approach this sort of design concern - if
one ensures that the possible intermediate gateways do not have the
credentials required to participate in the IPsec SAs involved, it's
not going to be possible for such an intermediate gateway to interfere
with the security of those SAs, even if every packet is forwarded
through the gateway.  OTOH, if the gateway has the credentials, use
of transport mode provides no additional security, as the gateway could
function as a transport-mode forwarding proxy.

I think the difference here is that iSCSI relies on appropriate and
correct configuration of the IPsec Security Policy Databases, and
appropriately controlled distribution/installation of IPsec security
credentials, in accordance with relevant security policy.  Channel
bindings appear to be intended to deal with an attacker who can
gain access to the IPsec keying material, but not NFSv4's - it
might be useful to phrase further discussion in terms of the level
of risk/threat posed by such attackers.

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


New Message Reply About this list Date view Thread view Subject view Author view Attachment view

This archive was generated by hypermail 2.1.2 : 03/04/05-02:12:22 AM Z CST