[30774] in Kerberos
Re: FIPS certification
daemon@ATHENA.MIT.EDU (Nicolas Williams)
Sat Feb 28 16:34:26 2009
Date: Sat, 28 Feb 2009 15:23:47 -0600
From: Nicolas Williams <Nicolas.Williams@sun.com>
To: Ken Raeburn <raeburn@mit.edu>
Message-ID: <20090228212346.GJ9992@Sun.COM>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20090228195621.GD9992@Sun.COM>
Cc: Kerberos mailing list <kerberos@mit.edu>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: kerberos-bounces@mit.edu
On Sat, Feb 28, 2009 at 01:56:22PM -0600, Nicolas Williams wrote:
> On Sat, Feb 28, 2009 at 01:07:50PM -0500, Ken Raeburn wrote:
> > We'd also still need to handle the krb5_keyblock structure embedded in
> > krb5_creds; in that instance it wouldn't be extensible.
>
> I suspect we can handle that by having a new krb5_keyblock for all
> non-krb5_creds uses of it, and krb5_keyblock_old for krb5_creds. It's
> only the auth_context and the GSS mech where we need to be able to cache
> derived keys and what not (crypto library handles).
There is another way...
If we only care about performance in the GSS mechanism then there's no
need to change krb5_keyblock. That means crypto in the raw krb5 API
apps will not be as good, mostly because of the lack of derived key
caching and because of the lack of caching of crypto library handles
(including key schedules). But MIT krb5 already suffers from this
anyways.
Nico
--
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
