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

[Olga Kornievskaia <[e-mail]>]

> On Aug 8, 2017, at 5:44 PM, Trond Myklebust <[e-mail]> wrote:
> 
> 
> 
>> 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.


But mds has access/copy of the principal database so it knows encryption types for the client server keys