Re: [nfsv4] Fwd: New Version Notification for draft-haynes-nfsv4-flex-filesv2-00.txt

bfields@fieldses.org (J. Bruce Fields) Mon, 28 August 2017 17:58 UTC

Return-Path: <bfields@fieldses.org>
X-Original-To: nfsv4@ietfa.amsl.com
Delivered-To: nfsv4@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF1AD132195 for <nfsv4@ietfa.amsl.com>; Mon, 28 Aug 2017 10:58:08 -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, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 JLfWOUf1Q9TM for <nfsv4@ietfa.amsl.com>; Mon, 28 Aug 2017 10:58:06 -0700 (PDT)
Received: from fieldses.org (fieldses.org [173.255.197.46]) by ietfa.amsl.com (Postfix) with ESMTP id DF81B13218E for <nfsv4@ietf.org>; Mon, 28 Aug 2017 10:58:06 -0700 (PDT)
Received: by fieldses.org (Postfix, from userid 2815) id EB8F1248F; Mon, 28 Aug 2017 13:58:05 -0400 (EDT)
Date: Mon, 28 Aug 2017 13:58:05 -0400
To: Olga Kornievskaia <aglo@citi.umich.edu>
Cc: Benjamin Kaduk <kaduk@mit.edu>, "nfsv4@ietf.org" <nfsv4@ietf.org>, Thomas Haynes <loghyr@primarydata.com>
Message-ID: <20170828175805.GA3393@fieldses.org>
References: <150215110527.12392.18161698955589691126.idtracker@ietfa.amsl.com> <2CA259E3-BD3A-482B-BFBF-3B90425AD3EA@primarydata.com> <CAN-5tyETNMCPVC5wJ-_77vM5+hVB+-uasd37kn+M=hoCeK6P7w@mail.gmail.com> <CAABAsM6rmrDU4BR6Ho7YFjjYA2amEkwuRGtzN537VXUZ-Eh-hg@mail.gmail.com> <20170808185803.GQ70977@kduck.kaduk.org> <CAABAsM7xOpbopPa3v1YMtfcFZbNZ=Jygap37Bg6qGfDDAvRHhQ@mail.gmail.com> <CAN-5tyHz1cqSWyv1hVMvzaqSr1W0V0_drz3BvzxHWDyM5w+spw@mail.gmail.com> <20170808203145.GS70977@kduck.kaduk.org> <CAN-5tyHR80V1Fi3GZJ5u=FsxQ5va=Ka2qTCmHZ48PikURYjwGw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAN-5tyHR80V1Fi3GZJ5u=FsxQ5va=Ka2qTCmHZ48PikURYjwGw@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
From: bfields@fieldses.org (J. Bruce Fields)
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/-DfMovdhCx9T1I71u0s8k_VJ31g>
Subject: Re: [nfsv4] Fwd: New Version Notification for draft-haynes-nfsv4-flex-filesv2-00.txt
X-BeenThere: nfsv4@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NFSv4 Working Group <nfsv4.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nfsv4>, <mailto:nfsv4-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/nfsv4/>
List-Post: <mailto:nfsv4@ietf.org>
List-Help: <mailto:nfsv4-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nfsv4>, <mailto:nfsv4-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 28 Aug 2017 17:58:09 -0000

On Tue, Aug 08, 2017 at 04:51:59PM -0400, Olga Kornievskaia wrote:
> On Tue, Aug 8, 2017 at 4:31 PM, Benjamin Kaduk <kaduk@mit.edu> wrote:
> > On Tue, Aug 08, 2017 at 04:05:35PM -0400, Olga Kornievskaia wrote:
> >> On Tue, Aug 8, 2017 at 3:37 PM, Trond Myklebust <trondmy@gmail.com> wrote:
> >> >
> >> >
> >> > On 8 August 2017 at 14:58, Benjamin Kaduk <kaduk@mit.edu> wrote:
> >> >>
> >> >> On Tue, Aug 08, 2017 at 02:54:58PM -0400, Trond Myklebust wrote:
> >> >> > Why pass Kerberos tickets around? Is there any reason not to just pass
> >> >> > an
> >> >> > initialised RPCSEC_GSS session handle?
> >> >>
> >> >> There's not a standard serialization of the GSS security context object
> >> >> that it contains, for transfer across the network.
> >> >
> >> >
> >> > I thought rfc1964 provides one, which is pretty much the basis for the user
> >> > library gss_krb5_lucid_context_v1_t typedef. Am I mistaken?
> >>
> >> We have the case of chicken before the egg problem here.
> >>
> >> Client has to send an AP_REQ to the server. He needs a ticket for
> >> that. after the gss dance with the data server gss_krb5_lucid_context
> >> is created.
> >
> > I think the proposal is that the MDS would send the AP_REQ, and generate a lucid
> > context to send to the client.  If the MDS also sends the RPCSEC handle,
> > the data server ought to be able to associate that with the same GSS security
> > context established by the MDS and handle RPCs from the client, even
> > though the peer's network address (as seen by the data server) has changed from
> > being the MDS to being the client.
> 
> Would an unmodified NFS server allow for this? Bruce might have better
> idea. I don't think the server would accept "continued" gss sequence
> on a new connection without going thru the gss dance.

The Linux server's gss processing is done in ignorance of any protocol
below that layer, and I can't think of a reason why we wouldn't accept a
gss context from a different IP address.

The split between kernel and rpc.gssd means that the Linux client always
does context initialization over a different connection from normal data
exchanges, so we can be pretty sure servers deal with that at least.

But I guess that wouldn't prevent other servers from binding the context
to a particular connection or IP address after that.  I don't think the
specs say anything either way.

--b.