Concealing keys (not even in NSS)

[Greg Hudson]

On 09/20/2016 01:42 AM, Rick van Rein wrote:
> This seems to me like a missed opportunity.  Am I mad to think that a
> crypto backend could choose any krb5_keydata representation, and that a
> pkcs11: URI [RFC7512] would be fine?  It looks like the surrounding
> libkrb5 treats the keys as literals and always invoke krb5_k_decrypt()
> and _encrypt() after expanding the key to an opaque krb5_key after
> krb5_k_create_key() and before krb5_k_free_key(), right?
> 
> This does seem to be possible -- but how do others feel about this?

It might be possible for some keys, and we'd like to get there
eventually.  But here are some obstacles to think about:

* Ephemeral keys (ticket session keys, initiator and acceptor subkeys)
are generated randomly by one party and sent to the other inside an
encrypted message.  Do we extend the protocol so that these keys can be
wrapped in parent keys within the encrypted messages, or do we decide
that the problem only applies to long-term keys?  Is it important to
solve the problem for ticket session keys, since they can remain valid
for hours or days?

* Server keys are shared between the KDC and the server keytab.  How can
these be provisioned so that both parties know them?  Is it okay for
these to pass through application memory when they are provisioned, if
they are hidden from application memory after that?

* For traditional password-based AS-REQs, client keys are generated by
string-to-key on the password.  How can this be done without making
either the password or the resulting key visible to kinit?  (For PKINIT,
PKCS #11 can already be used for the certificate private keys.)

* Should the KDC store every long-term key as a reference to a PKCS #11
device?  Should it store wrapped keys in the regular database?  Is it
sufficient for just the master key to be behind a PKCS #11 device, so
that the existing database format can be preserved at the cost of
letting long-term keys pass through KDC application memory?  How does
propagation of keys work across multiple KDCs within a realm?  How does
master key rollover work?

All of those concerns are on top of the historical APIs and data formats
(ccaches, keytabs) which assume that keys are just bit strings.  Changes
to the crypto library would comprise only a tiny part of the solution.