On Aug 9, 2012, at 5:38 PM, J. Bruce Fields wrote: > 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. Agreed, I would expect this to work only for pseudoflavors that share the same type of principal. Let me be sure I understand... I think the text of RFC 3530bis allows this implementation choice, but you are suggesting below that such an implementation may allow an attack. Does this concern warrant a change to RFC 3530bis or 5661? Should we bring this up on nfsv4@xxxxxxxx? > >>> 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. -- Chuck Lever chuck[dot]lever[at]oracle[dot]com -- 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
