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

From: Mike Eisler <[email-masked]>
Date: Thu, 27 Feb 2003 16:05:41 -0800 (PST)

Thanks for feedback. I'll incorporate it into the next version
of the i-d.

Some responses to your comments.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Thursday, February 27, 2003 12:02 PM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: RE: draft-eisler-nfsv4-ccm-00.txt
> 
> 
> Here are some thoughts of mine from a rather high level.
> 
> 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.

> The problem here is the lack of binding between the 
> authentication context
> established through traditional GSS mechanisms and the secure 
> transport
> channel used in CCM.
> 
> In order to provide this binding, we must integrity protect 
> the application
> context handle among other things passed in the rpc_gss_init_arg. For
> example, we could generate a checksum over the application 
> context handle,
> among other things if the handle does not have enough bytes, using the
> session key found in the soon-to-be-replaced authentication 
> context, and
> pass the whole thing as the opaque token in rpc_gss_init_arg. In the
> response, the server has to do the same with the CCM status.

I don't see how that solves the problem. Once you
have a established the CCM context, what prevents your malicious
user from using the CCM handle for its own requests? The only
thing that protects one from this sort of attack is
trsuting the integrity of the underlying TCP connection, and
IPsec is doing that.

> 2. Implementation caveats
> 
> A new mechanism that leverages IPSec to provide user-based 
> authentication
> does provide comparable security to that of the traditional 
> GSS mechanisms.
> Yet there are some caveats unique to this new mechanism that should be
> avoided when it comes to implementation.
> 
> a. The new mechanism does away with compute intensive cryptographic
> operation needed for authentication using a traditional GSS mechanism.
> However, it would be wrong to think authentication is totally 
> obsoleted. I'd
> like to think authentication takes a different form now - ensuring the
> binding between the CCM context and the secure transport 
> channel is legit
> for each incoming request. In other words, the CCM context 
> referenced in the
> request has been established using the same secure transport 
> channel as the
> request.

Ye, that is my intent, but I guess it didn't come across in the
i-d. I'll try better. :-)

> b. When the same secure transport channel is multiplexed on 
> the client side
> for multiple users, the client has to ensure the CCM context is only
> accessible to the user that has established it in the first place. One
> possible way to ensure that is by placing CCM contexts in the 
> privileged
> address space offering only controlled indexed access. 
> Imagine a user level
> process faking a CCM context handle (established by a legit 
> user locally)
> through a shared secure transport channel without having to 
> break into local
> privilege boundary and no cryptographics involved. It is much 
> harder to do
> the same using for example Kerberos since that requires local 
> privilege to
> access other user's ticket cache.

Fair enough, this can documented.

> 3. Security consideration
> 
> Properly implemented CCM can offer comparable security.
> 
> a. CCM does not unnecessarily inflate the scope of the trust 
> domain, as does
> for example AUTH_SYS over IPSec. By requiring the 
> authentication in the CCM
> context initialization (using a previously established 
> context), the trust
> domain does not extend to the client.

Agreed.

> b. Both the traditional mechanisms and CCM rely on the security of the
> client to protect locally logged on users. Compromise of the 
> client impact
> all users on the same client. CCM does not make the problem worse.

Agreed.

> c. For CCM, users on the same client may share the same 
> secure transport
> channel, meaning all traffic is protected with the same 
> session key at a
> given time. However, IMHO, it does not make cryptoanalysis of 
> the traffic
> easier compared to say Kerberos. Assuming reasonable NFS 

I disagree.

> usage and typical
> ticket lifetime of several hours, the attacker would have 
> gathered a lot of

Ticket lifetimes can be configured. Servers can delete
gss contexts at will.

> traffic anyways. On the other hand, the secure transport may 
> provide added
> benefits of automatic key exchange (AKE) management. For example, the
> lifetime of an IPSec session key can be adjusted based on the 
> traffic. This
> can be made shorter than the CCM context lifetime if necessary.

Evenif Kerberos does shared the advsntages of the
system you describe above, one could certainly implement a GSS
mechanism that does exactly waht you say. So at that point
we've got a comparison between the ciphetext being generated at the
IPsec level, versus the ciphertext generated at the RPCSEC_GSS
level by zillions of users.

There's a related issue, which is that if the system administrator
is careless in the management of the pair of IPsec
secret keys between a client and server, wherease if the user is
careful in the management of his own keys, then the user is at risk
due to negligence.

	-mre