Return-Path: linux-nfs-owner@vger.kernel.org Received: from mx1.redhat.com ([209.132.183.28]:61899 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755898Ab1KDQZa (ORCPT ); Fri, 4 Nov 2011 12:25:30 -0400 Subject: Re: GSSAPI Proxy initiative From: Simo Sorce To: Nico Williams Cc: "Adamson, Andy" , "Myklebust, Trond" , dhowells , "" , krbdev In-Reply-To: References: <1320269170.7734.585.camel@willson.li.ssimo.org> <1320332310.7734.643.camel@willson.li.ssimo.org> <1320337903.7734.670.camel@willson.li.ssimo.org> <1320352784.18396.109.camel@lade.trondhjem.org> <1320355818.7734.685.camel@willson.li.ssimo.org> <1320356806.18396.149.camel@lade.trondhjem.org> <1320357606.7734.697.camel@willson.li.ssimo.org> <2E1EB2CF9ED1CB4AA966F0EB76EAB4430BFA90EE@SACMVEXC2-PRD.hq.netapp.com> Content-Type: text/plain; charset="UTF-8" Date: Fri, 04 Nov 2011 12:25:25 -0400 Message-ID: <1320423925.7734.732.camel@willson.li.ssimo.org> Mime-Version: 1.0 Sender: linux-nfs-owner@vger.kernel.org List-ID: On Fri, 2011-11-04 at 11:20 -0500, Nico Williams wrote: > On Fri, Nov 4, 2011 at 10:55 AM, Adamson, Andy > 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