Crypto Modularity proj proposal

[Jeffrey Hutzelman]

--On Saturday, June 27, 2009 06:02:52 PM -0500 Nicolas Williams 
<Nicolas.Williams at sun.com> wrote:

> I'm saying that caching derived keys is performance critical in only a
> few places, and that those are mostly (only?) the ones where we happen
> to have an apaque context handle in which to hold the derived keys (the
> GSS mechanism's security context handles, and the krb5_auth_context)...
>
> ... therefore: cache derived keys in those handles and leave
> krb5_keyblock and all existing references to it alone.

That seems a reasonable approach.


> This may mean _adding_ new APIs that take derived keys (for implementing
> the GSS-API mechanism's per-token message functions, and for the
> krb5_mk/rd_priv/safe/cred() functions.

... and for external users that might benefit from such caching.



>> For (b), the last case is one of the primary cases where someone might
>> want to use an external reference.  Possibly the second-to-last case as
>> well; a client might want to push the session key into a cryptographic
>> token at AS-REQ time.  So those would be problem cases.
>
> I don't think anyone will want session keys in tokens.

Application session keys, no.  TGT session keys, maybe.  Or at least, in 
something that presents the same interface as a token: you tell it the key 
once, and never get it back, but it does crypto operations for you.


>   As for deriving
> keys from non-extractable key material stored in tokens, that is
> problematic.

That depends on the derivation in use.  The key derivations used in RFC3961 
and RFC3962 all depend on either using the source key as an encryption key 
or (for single-DES) are the identity mapping.  Both forms can be 
implemented with a non-extractable source key stored in a token, provided 
the token is willing to do encryption operations with that key.

-- Jeff