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. -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
