GSSAPI Proxy initiative

[Simo Sorce]

On Fri, 2011-11-04 at 11:20 -0500, Nico Williams wrote:
> On Fri, Nov 4, 2011 at 10:55 AM, Adamson, Andy
> <William.Adamson at netapp.com> wrote:
> > On Nov 4, 2011, at 11:13 AM, Nico Williams wrote:
> >> Ideally we could store in each RPCSEC_GSS context (not GSS context)
> >> enough state on the client side to recover quickly when the server
> >> reboots.
> >
> > You mean not to use the user Kerberos credential to re-establish the GSS context with the server?
> 
> Kerberos has tickets.  Other GSS mechanisms don't.  The GSS-API
> completely abstracts this, so there's no way to extract a service
> ticket and store it alongside the context (RPCSEC_GSS, in this case)
> where you might need it in the future.  Storing all of a GSS-API
> credential (think of a whole ccache) in kernel memory is not an option
> either (ccaches have unbounded size).
> 
> Moreover, if we do this in a light-weight enough fashion we might be
> able to handle all of the recovery path in kernel-mode, with no
> dependence on upcalls.  But if we didn't by somehow extracting the
> service ticket and storing it in the RPCSEC_GSS context we'd probably
> still need to upcall to make use of it.
> 
> >> How would we do this?  Suppose the server gives the client a
> >> "ticket", and a key much like the Kerberos ticket session key is
> >> agreed upon or sent by the server -- that could be stored in the
> >> RPCSEC_GSS context and could be used to recover it quickly for
> >> recovery from server reboot.  I'm eliding a lot of details here, but I
> >> believe this is fundamentally workable.
> >
> > So re-establish the RPCSEC_GSS session lost at the server on server reboot by storing enough additional info on the client?
> 
> Yes.  And not just server reboot.  The server is free to lose
> RPCSEC_GSS contexts any time it wants to.
> 
> Basically, we need a fast re-authentication facility that is easy to
> code entirely in kernel-mode.  Thinking of it this way I would not
> reuse any Kerberos tech for this.  The server would return a ticket in
> RPCSEC_GSS context establishment, but the ticket would consist of
> {secret key index, encrypted octet string} and the server and client
> would both compute a "session key" (for proving ticket possession)
> with GSS_Pseudo_random() (this way we can make this work even when the
> GSS mech only does MICs and not wrap tokens).  To re-authenticate the
> client would send the ticket and an authenticator just like in
> Kerberos, but simpler.

I agree this would be a very nice feature for fast reconnects in NFSv4,
but it looks more and more out of topic.
Time to move this sub-thread to the NFSv4 WG ?

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York