[17385] in Kerberos_V5_Development
Re: GSSAPI Proxy initiative
daemon@ATHENA.MIT.EDU (Nico Williams)
Fri Nov 4 11:36:16 2011
MIME-Version: 1.0
In-Reply-To: <CAK3OfOjqCjU4O--XwVBpSBE9pwwkyBEU6OiNLN8_dM6wYe5A1w@mail.gmail.com>
Date: Fri, 4 Nov 2011 10:36:11 -0500
Message-ID: <CAK3OfOihQhpzDriUwDQMdWahyOboHRX1vs0aYGTi8kG8ket1dg@mail.gmail.com>
From: Nico Williams <nico@cryptonector.com>
To: "Myklebust, Trond" <Trond.Myklebust@netapp.com>
Cc: dhowells <dhowells@redhat.com>, linux-nfs@vger.kernel.org,
krbdev <krbdev@mit.edu>, Simo Sorce <simo@redhat.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krbdev-bounces@mit.edu
Also, the recovery issue can come up with the server's cache of
RPCSEC_GSS contexts is under pressure.
I really think we want an RPCSEC_GSS-level solution for this. I don't
think we can address this problem entirely in the GSS stack. Since
RPCSEC_GSSv3 isn't done yet, maybe now is the time to work on a
solution there.
I'd build the solution by borrowing tech from Kerberos. The server
would mint a ticket for itself using some local secret key for the
ticket's encrypted part and with authorization data storing all of the
relevant server-side authorization context for the client principal,
then the server sends a KRB-CRED with that ticket and session key with
the KRB-CRED wrapped in a GSS wrap token OR with an encryption key for
the KRB-CRED based on GSS_Pseudo_random() OR it sends the ticket and
the client uses GSS_Pseudo_random() to compute the same session key
that the server did.
Nico
--
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
