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

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

On Jul 31, 2014, at 7:31 PM, J. Bruce Fields <[e-mail]> wrote:

> On Thu, Jul 31, 2014 at 07:10:18PM -0400, Benjamin Kaduk 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.
> 
> Maybe I'm forgetting some part of the motivation here:
> 
> 	http://tools.ietf.org/html/draft-ietf-nfsv4-minorversion2-26#section-4.10.1.1
> 
> There might be something in the complete COPY protocol that makes this
> work.  Though I don't see it yet.

Yes, the use of privacy on the RPCSEC_GSS_CREATE calls due to the shared secrete being passed in the Structured Privilege assertions. 
> 
> At a minimum we could use some more explanation in this draft.

I agree we need to make Multi-principal authentication assertions secure all by itself - and not require privacy.

—>Andy
> 
> --b.