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

From: Mike Eisler <[email-masked]>
Date: Mon, 3 Mar 2003 20:53:24 -0800 (PST)

> From [email-masked]  Fri Feb 28 06:44:10 2003

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

Which is appalling, and it makes one wonder why anyone who
deploys IPsec that way thinks they are improving security.

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

So I don't understand why CCM over IPsec is not considered
secure.

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

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

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

But in any case, hijacking is avoidable, which was my point.
The CCM i-d will be updating to point this out.

	-mre