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

[Benjamin Kaduk <[e-mail]>]

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'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.  The reply is already authenticated as
> the parent, the problem again is authenticating as the child, so I think
> it should be calculating a mic using the child context (maybe over the
> header data again, as in section 2.3?).

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

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

Thank you for saying it :)

-Ben