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

[Olga Kornievskaia <[e-mail]>]

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.