Re: NFS: Treat NFS4ERR_CLID_INUSE as a fatal error

["J. Bruce Fields" <bfields@fieldses.org>]

On Thu, Aug 09, 2012 at 05:29:47PM -0400, Chuck Lever wrote:
> 
> On Aug 9, 2012, at 5:13 PM, J. Bruce Fields wrote:
> > The server could just compare principal strings (and ignore
> > pseudoflavors) in the gss case.
> 
> Barring a correction about how GSS Kerberos principals work, I think that's the correct approach.

I also don't know if principals produced by other mechanisms are going
to be comparable.  Of course that's a bit academic given that kerberos
is the only mechanism for the forseeable future.

> > If the intention is to ensure that a clientid can't be "hijacked" by
> > someone malicious, then you don't want to allow a krb5 setclientid to
> > blow away a clientid established with krb5i.  (If sending the
> > setclientid with krb5i indicates the client wants protection against
> > attacks which replace the body of the rpc, then a later krb5 setclientid
> > should be rejected, since it could be the product of such an attack.)
> 
> If the client wants to avoid hijacking, it should start out with krb5i, as is recommended in the Security Considerations section of 3530(bis).
> 
> The intention of 3530(bis) is that one client instance uses just one nfs_client_id4.id string.  A client that attempts to change flavors on its SETCLIENTID/RENEW operations in mid-journey, on purpose, seems a little schizophrenic.  I can't think of a good reason it should do this.

You don't know it's the same client any more.  The attack is:

	client sends setclientid with krb5i.

	client later sends some other rpc with krb5.

	attacker intercepts that operation, takes the rpc header, strips
	out the body, and replaces the body by a setclientid operation
	destroying the client's state.

Since krb5 only protects the header, the server can't tell that's what's
happened.

--b.