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

"J. Bruce Fields" <bfields@fieldses.org> Thu, 31 July 2014 23:31 UTC

Return-Path: <bfields@fieldses.org>
X-Original-To: kitten@ietfa.amsl.com
Delivered-To: kitten@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DED11A02E6; Thu, 31 Jul 2014 16:31:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cCjQ6tm2S49C; Thu, 31 Jul 2014 16:31:27 -0700 (PDT)
Received: from fieldses.org (fieldses.org [174.143.236.118]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72B381A02EB; Thu, 31 Jul 2014 16:31:20 -0700 (PDT)
Received: from bfields by fieldses.org with local (Exim 4.76) (envelope-from <bfields@fieldses.org>) id 1XCzoa-0006HH-Om; Thu, 31 Jul 2014 19:31:16 -0400
Date: Thu, 31 Jul 2014 19:31:16 -0400
From: "J. Bruce Fields" <bfields@fieldses.org>
To: Benjamin Kaduk <kaduk@MIT.EDU>
Message-ID: <20140731233116.GA24040@fieldses.org>
References: <DC941FEB-725A-49E1-8C38-FF765454827C@netapp.com> <20140730163006.GG26316@fieldses.org> <alpine.GSO.1.10.1407311902230.21571@multics.mit.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <alpine.GSO.1.10.1407311902230.21571@multics.mit.edu>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/--PqMXlVqRz7BNtqjQV-X2y4iEk
X-Mailman-Approved-At: Thu, 31 Jul 2014 23:22:46 -0700
Cc: "kitten@ietf.org" <kitten@ietf.org>, "Adamson, Andy" <William.Adamson@netapp.com>, NFSv4 <nfsv4@ietf.org>
Subject: Re: [kitten] [nfsv4] draft-ietf-nfsv4-rpcsec-gssv3: request for review
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/kitten>, <mailto:kitten-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/kitten/>
List-Post: <mailto:kitten@ietf.org>
List-Help: <mailto:kitten-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 31 Jul 2014 23:31:31 -0000

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.

At a minimum we could use some more explanation in this draft.

--b.