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

[Trond Myklebust <[e-mail]>]

On 8 August 2017 at 15:49, Benjamin Kaduk <[e-mail]> wrote:

> On Tue, Aug 08, 2017 at 03:37:41PM -0400, Trond Myklebust 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?
>
> I only see formats for security context establishment (negotiation) tokens,
> which are exchanged so that the peers can establish a complete security
> context -- I think you're mistaken.
>
> AIUI the gss_krb5 lucid contexts came about due to the need to establish
> a GSS security context in userspace and then export the keying material
> into the kernel for per-message processing (for NFS).  I'm only about 95%
> sure, but the information from a lucid context ought to be enough to
> send from MDS to client and let the client use RPCSEC_GSSv3.  The
> lucid context is a per-implementation extension, though, and we can't
> use it in our standard without standardizing the lucid context first.
>

Right, but there are some issues with just passing back a KRB5 service
ticket too.

For one thing, how does the MDS choose which encryption scheme to use? It
knows what encryption the client is using for the RPCSEC_GSS session, but
presumably it has no idea what kind of ticket was used to negotiate that
session.