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

["J. Bruce Fields" <[e-mail]>]

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:

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

Apologies if the question's already answered somewhere.

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

(Also, note the draft uses at least "nonce", "nounc", and "nounce", a
spellcheck would help here.)

--b.