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

[Trond Myklebust <[e-mail]>]

On 8 August 2017 at 17:27, Olga Kornievskaia <[e-mail]> wrote:

> On Tue, Aug 8, 2017 at 5:12 PM, Trond Myklebust <[e-mail]> wrote:
> >
> >
> > 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.
> >
>
> Since MDS = KDC then it would know which encryption scheme to use.
>

The client will usually authenticate to the MDS using the corporate KDC.
The KDC on the MDS itself is not required to be the same.