[kerberos-discuss] thoughts/issues making MIT krb code fit for drop-in to Solaris

[Nicolas Williams]

On Thu, Sep 18, 2008 at 09:47:30PM -0400, Jeffrey Altman wrote:
> The long term solution to the KFW problem is to develop an API/ABI
> that Microsoft can safely implement as a shim on top of their
> internal implementation.  To make that happen all of the key data
> and other privates must remain hidden from the application.  Adopting
> the Solaris ABI would be a good first step in that direction.

Good to hear.

For the benefit of others...

Keep in mind that the major difference between the two ABIs relates to
krb5_keyblock.

The MIT krb5 API leaves a *lot* to be desired, but if there's any aspect
of it that could be termed 'disastrous' it's the fact that critical
structures are not kept opaque and this has led to developers allocating
instaces of such structures as automatic variables (because they could,
and "everyone knows" that's cheaper than calling a constructor, right?
*sigh*).  Specifically krb5_keyblock.

For those of you who are not aware, Wyllys Ingersoll (at Sun) made two
major changes to krb5_keyblock handling in Solaris.

First he added a derived key cache to krb5_keyblock.  MIT krb5
re-derives keys every time it needs them, which, with key derivation
being a slow operation, slows everything way down, whereas Solaris
derives keys just once.  This is what happens when an API designed with
RFC1510 gets adapted to RFC4120 and RFC3961 -- modern crypto meets
ancient API.  Second, Wyllys retrofitted support for PKCS#11 is
user-land and the Solaris kernel cryptographic API in kernel-land.

The ABI impact is two-fold: krb5_keyblock's size changed (at the time
Solaris did not expose the krb5 API), and now krb5_keyblock must always
be properly initialized or otherwise constructed by the library.

MIT cannot make the same changes without breaking the MIT krb5 ABI.
Keeping a look-aside cache of krb5_keyblock->{derived keys, PKCS#11
sessions, ...}, indexed by krb5_keyblock address would seem like the way
to go.  But because krb5_keyblock instances can be allocated on the
stack the value of a keyblock's keys must always be memcmp()ed at the
very least.

If MIT were to adopt the above look-aside cache approach and the
resulting performance turned out OK then Sun could conceivably adopt
that approach in order to minimize source code differences.

So I suppose we should say that we're willing to consider a scheme that
might not result in a need for a ./configure ABI type selection option.

However, in the short- to medium-term it's quite clear that the only
simple way for Sun to make progress towards having MIT krb5 be a drop-in
replacements in OpenSolaris would be to add such ./configure option.

Nico
--