Crypto Modularity proj proposal

[Nicolas Williams]

On Wed, Jun 24, 2009 at 05:04:43PM -0400, Jeffrey Hutzelman wrote:
> --On Wednesday, June 24, 2009 12:50:43 PM -0500 Nicolas Williams 
> <Nicolas.Williams at sun.com> wrote:
> >[...]
> 
> The problem with this theory is that it massively breaks modularity. 

Not really: you can always introduce a new version of krb5_keyblock that
does the Right Thing (tm) and use that in the GSS and auth contexts.

(Also, though we didn't have an ABI to break, it's very likely that
diverging from the MIT krb5 ABI will cause us headaches down the road.
Now I'm having buyer's remorse.)

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

My list was clearly not exhaustive (in that I failed to make it so :).
But also, I did say "only for long-term keys", which includes the keys
servers store.

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

Almost a correct characterization.  I'm not advocating changing
_everything_ to use new interfaces.  I'm advocating changing those
components where the perf boost of caching derived keys is most sorely
needed, and that would be the GSS-API mechanism.

Nico
--