RE: draft-eisler-nfsv4-ccm-00.txt

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

From: Black_David@emc.com
Date: 02/28/03-08:42:18 AM Z


From: Black_David@emc.com
Message-Id: <277DD60FB639D511AC0400B0D068B71E0564C977@corpmx14.us.dg.com>
Subject: RE: draft-eisler-nfsv4-ccm-00.txt
Date: Fri, 28 Feb 2003 09:42:18 -0500

Mike,

> > 1. Lack of authentication in CCM context initialization
> > 
> > According to Section 4, the way the CCM context initialization works
over
> > RPCSEC_GSS, it is not too difficult for a malicious user to cheat the
server
> > into establishing a new CCM context with him. All he has to do is to get
an
> > IPSec association with the server and fake a handle (opaque bytes with
no
> > cryptographic protection) to a previously established authentication
> > context.
> 
> If a TCP connection is protected with IPsec, I don't see how
> the malicious user can do anything bad. he can't hijack the
> TCP connection (that's what IPsec is for). Without hijacking the TCP
> connection, he'll be unable to use a CCM handle.

That's not as ironclad as it might appear.  The problem is that group
pre-shared keys are a rather common IPsec (IKE actually) authentication
methodology.  This involves every node in the group having the same
IPsec authentication key, so IPsec authentication only confirms
group membership, leaving distinguishing of individual access
privileges within the group to higher level protocols like NFS.
This and concerns about IPsec deployment/usage are why iSCSI has
inband authentication mechanisms in addition to requiring IPsec.

In this scenario, the enrollment controls (who can join the group,
and hence obtain the key) may not be wonderful, and whether a group
member can hijack another's TCP connection depends on some IPsec
implementation details.  In principle, hijacking can be prevented,
but this depends on exactly how the IPsec policy is configured in
the implementations (specifically the relationship between the IPsec
SAD and SPD entries - see Section 4.4 of RFC 2401 if you really
want to know more).

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


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:11 AM Z CST