Crypto Modularity proj proposal

[Greg Hudson]

On Wed, 2009-06-24 at 17:04 -0400, Jeffrey Hutzelman wrote:
> 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.

Nico is effectively proposing a variation on the "rev every part of the
API which deals with keyblocks" option, where we only rev the crypto API
itself and not the krb5.h structures which currently reference
keyblocks.  In this proposal, a krb5_keyblock continues to hold only a
cryptographic key (no other state) and some other structure would be
created to hold cached information derived from a key or references to
keys.

The basic question here is: when keyblocks are used in other krb5.h
structures, (a) when would it be very convenient to store cached
information alongside them, and (b) when could it make sense to store an
external reference instead of a key?  Here are the structure references:

  * krb5_enc_tkt_part: session key contained within ticket
  * krb5_authenticator: AP-REQ subkey
  * krb5_enc_kdc_rep_part: session key sent from KDC to client
  * krb5_ap_rep_enc_part: AP-REP subkey.
  * krb5_cred_info: session key in ticket forwarding message
  * krb5_creds (by value): ticket session key stored by client
  * krb5_keytab_entry (by value): secret key of keytab entry

For (a), I don't think any of these keys are used to perform repeated
encryptions with the same key usage; as Nico points out, that would be
done with keys stored in krb5_auth_context or krb5_gss_ctx_id_t
structures, which are private.

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.