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

From: [email-masked]
Date: Fri, 28 Feb 2003 10:42:25 -0500

> -----Original Message-----
> From: Mike Eisler [mailto:[email-masked]]
> Sent: Thursday, February 27, 2003 7:06 PM
> To: [email-masked]
> Subject: RE: draft-eisler-nfsv4-ccm-00.txt
> 
> 
> 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.
> 

IPSec provides end-to-end security; but what is desired in NFSv4 is
user-to-user. Many hosts in the network can be configured to have the same
end-to-end security. But not all users that have access to those hosts might
be allowed to access NFSv4 server. Thus, the user that initiates the CCM
context has to prove to the server, once and for all during the lifetime of
the CCM context, that he has established the Kerberos v5 context, perhaps by
using a keyed MAC with the session key.

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

This is prevented by ensuring the binding between the CCM context and the
secure channel is legit, as outlined in 2a. Additional crypto is not needed
here to achieve authentication because of IPSec.

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

Agreed there are differences between the two mechanisms, but it is not clear
to me that Kerberos is that much better. IMHO, a detailed comparison of the
two will help with understanding and therefore adoption.

The example above. Assuming strong authentication is used for IPSec (such as
certificates, not group-shared key), then compromising IPSec secret would
usually mean the hacker has gained privileged access to the local system. If
this is the case, all users on that system using Kerberos will be impacted
as well.

> 	-mre