[17391] in Kerberos_V5_Development
Re: GSSAPI Proxy initiative
daemon@ATHENA.MIT.EDU (Adamson, Andy)
Fri Nov 4 14:03:16 2011
From: "Adamson, Andy" <William.Adamson@netapp.com>
To: Nico Williams <nico@cryptonector.com>
Date: Fri, 4 Nov 2011 16:30:13 +0000
Message-ID: <4110733A-4C73-481B-96D5-D6C3BDBB16CD@netapp.com>
In-Reply-To: <CAK3OfOgdgPEe85z152Hi06E8GwpZZJ9ch-Vq1GneMCW6nBZ6pw@mail.gmail.com>
Content-Language: en-US
Content-ID: <CCA37A1C8444404381DC27CC9FF70053@tahoe.netapp.com>
MIME-Version: 1.0
Cc: dhowells <dhowells@redhat.com>,
"<linux-nfs@vger.kernel.org>" <linux-nfs@vger.kernel.org>,
"Adamson, Andy" <william.adamson@netapp.com>,
Simo Sorce <simo@redhat.com>,
"Myklebust,
Trond" <trond.myklebust@netapp.com>,
krbdev <krbdev@mit.edu>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krbdev-bounces@mit.edu
On Nov 4, 2011, at 12:20 PM, Nico Williams wrote:
> On Fri, Nov 4, 2011 at 10:55 AM, Adamson, Andy
> <William.Adamson@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).
Well, don't all GSS mechanisms have credentials? We use the UID to map between the RPCSEC_GSS context and the credential, so we don't need to store the credential along side of the context.
That said, I agree that a light-weight method of re-establishing a context is very appealing.
-->Andy
>
> 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@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
