Crypto Modularity proj proposal

[Nicolas Williams]

On Wed, Jun 24, 2009 at 01:40:40PM -0400, Greg Hudson wrote:
> The code organization part has already been discussed and I think is
> mostly uncontroversial.
> 
> The hard part is what we do to allow keyblocks to support:
>   * Caching of derived keys

I think it turns out to be easier than we (Wyllys and I) thought years
ago when Wyllys implemented this for Solaris.  Love argues that there's
no need to change krb5_keyblock, mostly because performance matters most
in the GSS-API mechanism, where we have a great place to stash derived
keys: the mech-specific gss_ctx_id_t.  I agree with that.

If you do this then only GSS apps will get the perf improvement, though
you could also cache derived keys in krb5_auth_context for raw krb5
apps.

>   * Caching of implementation object handles for keys
>   * References to keys stored opaquely in cryptographic modules
> The second and third points are related; I'm just drawing a distinction
> between the performance goal of not having to create an object handle
> for each operation and the functionality goal of being able to support
> opaque, external storage of long-term keys.

Keys stored in HW tokens should be allowed only for long-term keys.  If
you do that then you need only make the token/slot/session available to
the pre-auth plugins (and on the KDC side for using the master DB keys
and, maybe, TGS and kadmin keys).  Again, no need to touch
krb5_keyblock.

Nico
--