Crypto Modularity proj proposal

[Nicolas Williams]

On Fri, Jun 26, 2009 at 12:55:50PM -0400, Greg Hudson wrote:
> 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.

I don't quite understand your characterization of my proposal, so I'll
just say that's not it ;)

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.

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.  But that would not be a
wholesale revving of "every part of the API which deals with keyblocks".

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

Right.

> 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.  As for deriving
keys from non-extractable key material stored in tokens, that is
problematic.

Nico
--