On Fri, Nov 4, 2011 at 10:55 AM, Adamson, Andy
<William.Adamson@xxxxxxxxxx> 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.
Nico
--
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
