From: Black_David@emc.com
Date: 03/04/03-09:33:13 AM Z
From: Black_David@emc.com Message-Id: <277DD60FB639D511AC0400B0D068B71E0564C995@corpmx14.us.dg.com> Subject: RE: draft-eisler-nfsv4-ccm-00.txt Date: Tue, 4 Mar 2003 10:33:13 -0500 Mike, > > > > 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. The "fake a handle" part above is scary. As long as a CCM handle can't be faked and exploited over a TCP connection other than the one for which it was created, there's not much of a problem here. > > 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 > > Which is appalling, and it makes one wonder why anyone who > deploys IPsec that way thinks they are improving security. Consider a site-to-site VPN where one is concerned mostly about authenticating the gateways (machines), rather than remote access, where one is concerned about user authentication. Appalling or not, it is done in practice. > One could certainly deploy Kerberos V5 or PKI the same way ... just > give each service and user the same key pair. By that argument > kerberized NFS and ftp are no secure, even if every message in > the ULP traffic is protected with GSS_GetMIC(). This is more about user authentication than machine authentication. In practice Kerberos is not deployed that way for user authentication - everyone gets their own credentials. PKI is a different story - the most common uses of certificates don't issue a certificate per user due to the administrative overhead involved, leading to the sort of two level structure that many web users are familiar with: - Server uses a certificate to set up SSL and authenticate itself. No client certificate is used. - Client authenticates via username/password over the resulting secure connection. > So I don't understand why CCM over IPsec is not considered > secure. I didn't say "not considered secure" - what I said was that it would be wrong to assume that IPsec has solved all authentication problems, and hence concerns about CCM credential binding to the underlying connection and reuse on a different connection cannot be dismissed. > > 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. > > Inband authentication mechanisms on each iSCSI message? > I wasn't aware there were any, at least, any that were mandatory. > I skimmed through the ips-security i-d and didn't see any. No, iSCSI has one-time inband authentication on connection setup - it's the first phase of login. That plus suitable (clueful) usage of IPsec provides the necessary services and properties. iSCSI's equivalent of credentials can't be hijacked or transferred across connections because every new connection has to go through the security phase of login where in-band authentication occurs (if it's configured), and the resulting "credential" association is implicit rather than explicit. > > 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 > > And also whether the attacker is observing the traffic before the > session keys are generated. Shouldn't be relevant if IPsec is configured to secure everything, as the session keys are generated before any NFS traffic flows. > > 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). > > I didn't see the part that recommended that multiple hosts > shared a key, but it is quite possible that such a recommendation > is there amid all the jargon. Section 4.7 mentions that multiple > senders to a multicast group should use the same > SA to traffic to the group. There's no "recommendation", but what's there clearly allows this in a number of ways - this involves the details of how SAD entries are constructed from SPD entries. > But in any case, hijacking is avoidable, which was my point. > The CCM i-d will be updating to point this out. That update should do the job. Please also make sure that a CCM credential cannot be hijacked or otherwise used by an unauthorized user in the absence of hijacking the TCP connection. 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 ----------------------------------------------------
This archive was generated by hypermail 2.1.2 : 03/04/05-02:12:13 AM Z CST