Re: [kitten] [nfsv4] draft-ietf-nfsv4-rpcsec-gssv3: request for review

["Adamson, Andy" <[e-mail]>]

On Jul 31, 2014, at 7:10 PM, Benjamin Kaduk <[e-mail]> wrote:

> On Wed, 30 Jul 2014, J. Bruce Fields wrote:
> 
>> On Wed, Jul 30, 2014 at 02:47:44PM +0000, Adamson, Andy wrote:
>>> Hello
>>> 
>>> I spoke with Shawn Emery (the Kitten WG Chair) last week at IETF 90, and he agreed that I should cross-post the RPCSEC_GSSv3 draft to the Kitten WG as well as to the NFSv4 WG to solicit reviews.  Please review the draft which adds two new RPCSEC GSS operations and is a normative reference to draft-ietf-nfsv4-minorversion2.
>>> 
>>> As we are working to finish draft-ietf-nfsv4-minorversion2 , please submit your reviews by Aug 31, 2014.
>>> 
>>> https://datatracker.ietf.org/doc/draft-ietf-nfsv4-rpcsec-gssv3
>> 
>> I'm confused by multi-principal authentication:
> 
> Ah, good, it's not just me.
> Sorry I didn't catch this before sending my giant pile of comments.
> 
>> The RPCSEC_GSS_CREATE request should demonstrate that the caller knows
>> both parent and child's credentials.  That's easy for the parent since
>> an RPCSEC_GSS_CREATE request is also just an ordinary RPCSEC_GSS request
>> sent as the parent.
>> 
>> For the child the caller has to calculate the mic of a nonce using the
>> child context, but as far as I can tell the choice of nonce is entirely
>> up to the caller.
>> 
>> Couldn't it then just choose as the nonce some data that it had
>> previously seen a mic for?  If so, would it work to remove the nonce and
>> instead calculate, say, a mic of the rpc header (as we do when
>> calculating the verifier?).
> 
> Certainly it would help to include (something with) the sequence number, as a proof of "liveness".  We may have to brainstorm a bit.

I have always thought of Multi-principal authentication in terms of it’s use in NFSv4.2 Inter server to server copy, where all of the RPCSEC_GSS_CREATE messages MUST use rpc_gss_svc_privacy’…. Good catch Bruce.

So for this attack to occur the rgmp_nonce must be re-used by the same rgmp_handle (same user-principal). 
Insisting on using a random number generator to create nounce could be by-passed by a bad implementation...

Bruces suggestion of using the new reply verifier data (rpc-header) should do the trick. Any objections to this approach?

> 
>> I'm not sure about the reply either:
>> 
>> 	On a successful reply, the rgss3_gss_mp_auth field in the
>> 	rgss3_create_res reply uses the parent RPCSEC_GSSv3 context as
>> 	the rgmp_handle, the same rgmp_nounce as was sent in the call
>> 	data with the rgmp_nounce_mic created using the GSS-API security
>> 	context associate with the parent handle.  Verification of the
>> 	rbg_nounce_mic by the initiator demonstrates that the target
>> 	agrees to the multi-principal authentication.
>> 
>> "The target" here is ambiguous.  

Well, this is RPCSECGSS speak. There is only one target, and one initiator.  For NFS, the initiator is the client and the target is the server.

>> The reply is already authenticated as
>> the parent, the problem again is authenticating as the child

You must mean the Multi-principal “inner” handle.

There is no “child’ as the child handle is the result of the successful RPCSEC_GSS_CREATE call, and we are defining how success is determined.


>> , so I think
>> it should be calculating a mic using the child context (maybe over the
>> header data again, as in section 2.3?).

The child handle is varified on the target (server) by a successful GSS_VerifyMIC using the user-principal GSS context and the nounce. This exchange is the target 
> 
> In some sense at least, the server "owns" all the resources on it.  It could choose to hand out a user's data to the whole world if it felt like it, but we have to trust that it will not.  

Yes, true with any server at any level of security.

> In particular, the server could decline to validate the nonce-MIC at all, and grant access to anyone who claimed to be the user; we must trust that it does the verification properly.  (A proper verification confirms that the server does have a valid context handle for the inner context.)  

Correct, and that verification is noted in the sentence prior to the quote above - this obviously could be clearer. I could separate the two verifications into two paragraphs.

   The target verifies the multi-principal authentication by verifying
   the rgmp_nouce_mic.  

I can see that the following can be re-worded, and updated with a better nounce (just as Bruce suggested).

  On a successful reply, the rgss3_gss_mp_auth
   field in the rgss3_create_res reply uses the parent RPCSEC_GSSv3
   context as the rgmp_handle, the same rgmp_nounce as was sent in the
   call data with the rgmp_nounce_mic created using the GSS-API security
   context associate with the parent handle.  Verification of the
   rbg_nounce_mic by the initiator demonstrates that the target agrees
   to the multi-principal authentication.



> In that sense, this reply is just serving as a confirmation that the server accepts the multi-authentication claim, and a simple boolean would have the same effect, so long as it is authenticated.

Yes

> 
> Labels and MAC make this more interesting than the oversimplified picture I just painted, of course, and I agree that this exchange has room for improvement.
> 
>> (Also, note the draft uses at least "nonce", "nounc", and "nounce", a
>> spellcheck would help here.)

Yikes - a simple spell check is certainly not asking too much - I wlll fix this :)

—>Andy
> 
> Thank you for saying it :)
> 
> -Ben