Crypto Modularity proj proposal
jhutz at cmu.edu
Sun Jun 28 12:02:30 EDT 2009
--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
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.
More information about the krbdev