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

[[e-mail] (J. Bruce Fields)]

On Tue, Aug 08, 2017 at 04:51:59PM -0400, Olga Kornievskaia wrote:
> On Tue, Aug 8, 2017 at 4:31 PM, Benjamin Kaduk <[e-mail]> 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 <[e-mail]> wrote:
> >> >
> >> >
> >> > On 8 August 2017 at 14:58, Benjamin Kaduk <[e-mail]> 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.