Crypto Modularity proj proposal

[Jeffrey Hutzelman]

--On Wednesday, June 24, 2009 12:50:43 PM -0500 Nicolas Williams 
<Nicolas.Williams at sun.com> wrote:

> 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.

The problem with this theory is that it massively breaks modularity. 
Neither the GSS-API mechanism nor the auth-context-level operations need 
access to the underlying crypto primitives.  Anything that's going to 
benefit caching, hardware assist, etc is below the 3961 abstraction.  Most 
especially, notably, key derivation happens below the 3961 abstraction.

Also, we know there are things coming along which use the 3961 interface 
directly, including various GSS-API mechanism proposals, a new security 
class for AFS, and I think something else I've forgotten about.  These 
things should also get the performance benefits.


>>   * 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.

Unless there is fancy preauth in use, I need my long-term key to decrpyt an 
AS_REP.  Services need their long-term keys to decrypt AP_REQ's.  Again, I 
think there's another case I'm forgetting.

You seem to be arguing for leaving the current abstractions as-is and 
inventing a complete new set of interfaces, then changing everything to use 
the new interfaces.  I suppose that's an option, but it's a pretty invasive 
one.

-- Jeff