thoughts/issues making MIT krb code fit for drop-in to Solaris

[Tom Yu]

Will, thank you for your efforts in assembling this summary.  It is
valuable input toward updating development priorities for the Kerberos
Consortium's development efforts.

Will Fiveash <William.Fiveash at Sun.COM> writes:

> One goal Sun has in regards to it's association with the MIT Kerberos
> Consortium is to eventually have the Consortium's Kerberos source code
> made suitable to use as is in Solaris (drop-in).  This would save Sun
> time and effort in that resync'ing the Consortium's source code with the
> Solaris Kerberos source code could be avoided.
>
> One approach suggested by Nico Williams is to do this by modifying one
> MITKC component at a time to keep each project smaller in scope.  The
> following components would be updated in an order like:
>
>  - Raw Kerberos components
>                           
>     - libkrb5             
>     - libkadm5*
>     - utilities (kinit, kdestroy, klist, ktutil, kvno)
>     - krb5kdc, kadmind, kadmin, kadmin.local, kdb5_util, ...
>     - KDB plugins
>     - CCAPI              
>
>  - GSS-API Kerberos V mechanism related components
>                                                   
>     - mech_krb5 (and implied libgss, mech_dh changes)
>     - mech_spnego (and implied libgss, mech_dh changes)
>     - libgss (and mech_dh changes)                     
>
>  - misc
>        
>     - RPCSEC_GSS API diffs (which impact libkadm5* and kadmin* somewhat)
>
> So initially (and most importantly) the libkrb5 code would be modified
> and once that project is done, other components could be modified as
> additional projects. 

I agree with the strategy of pursuing the updates incrementally.

> To help understand what this entails, the following is a list of various
> differences between the MITKC and Solaris mech_krb5/libkrb5 source code.

Are these in priority order?  I suspect that I would choose a
different priority ordering based on information I currently have from
sponsors and other interested parties, but I am open to additional
suggestions.

> - Crypto Framework
>
>     Solaris Kerberos uses the native Solaris Encryption Framework
>     interfaces for it's crypto needs in both user and kernel space.
>     This mainly involves changes to files under src/lib/crypto. Note
>     that the _krb5_keyblock has also been modified:

I think that improvement of the crypto framework abstraction can be
helpful for many reasons.  I suspect that some vendors may want to be
able to more easily use a FIPS 140-2 compliant crypto library.

>     This creates an ABI difference between Solaris and MIT.

We could choose to deprecate the old ABI, or make compatibility glue
to support it.

> - I18N, error tables and messages in general.
>
>     MIT dynamically generates their error tables, Solaris uses a static
>     switch statement in various C files based on the MIT error tables.

Can gettext() be run on the static strings returned by the com_err
library, if we manage to feed the strings from the com_err string
tables to the localization software?

> - User space and kernel space krb mechs
>
>     Solaris provides a krb mech that is comparable in function to the
>     MIT krb mech in user space and in addition Solaris has a krb mech as
>     a kernel module.  This provides a subset of the user space krb mech
>     function to basically support NFS security needs.  One implication
>     of this is that not all library functions used by the user space krb
>     mech are available in the kernel.

There are multiple reasons that we might want to be able to compile
subsets of various GSS or krb5 library functionality. Among those is
the ability to make a lean client-only library, which is useful for
some scenarios, and which we have already done some work on.

> - Auditing
>
>     There are 74 calls in the Solaris code base to Basic Security Module
>     auditing routines.

Are these primarily on the KDC side, or are there application server
things as well?

> - rpcsec_gss(3NSL) API differences
>
>     There may be rpcsec_gss(3NSL) API differences too (for kadmin
>     support of use of kadmin/changepw instead of kadmin/host.FQDN
>     service princs -- the Solaris API comes up short).

This means that we should probably collaborate on evolving the RPCSEC
APIs to converge.

> - Changes in *.conf files and other parameters?
>
>     - File locations - default krb5.conf, kdc.conf in /etc/krb5
>     - Different defaults for some configuration variables

For the file locaitons, are there necessary changes beyond specifying
special options to the configure script?

> - Some diffs due to KDB LDAP plugin port
>
>     The diffs can be seen by doing
>     grep -i 'solaris kerb' *.[ch]
>     in these paths in the OpenSolaris source gate
>     usr/src/cmd/krb5/ldap_util
>     usr/src/lib/krb5/plugins/kdb/ldap
>
> - lint clean mech (Wyllys announced this 01/13/2003)
>
>     To comply with Solaris kernel code policy, the code that comprises
>     the kernel krb mech has been made lint clean.  I believe at least
>     that part of the code will need to stay lint clean as a pre-req for
>     Solaris drop-in purposes.
>     
>     For code that is only in user space, gcc -wall clean would be
>     acceptable unless the Sun Studio lint pointed out something really
>     egregious.

Quite a few of the warnings we get from gcc are from
signed-vs-unsigned comparisons or conversions.  (It's an extra warning
we turn on, but it can catch some subtle bugs.)  At the moment, many
of them look like false positives due to some quirks with the way
krb5_data is defined.  We can probably eliminate many of them by
changing krb5_data in a way that is ABI-compatible on most platforms.

There may be similar high-leverage changes that can eliminate large
numbers of warnings.

> - Zero Conf realm lookup changes
>
>     Support of a fall back default realm based on the host's domain name
>     if the default realm is not specified in the krb5.conf.

This seems like a good idea.  I haven't extensively examined Mark
Phalan's patch (in ticket #6031) yet, but I have glanced at it.

> - No reverse DNS lookup in krb5_sname_to_principal()

I think reducing or eliminating dependencies on DNS rank fairly high
among the desires of Kerberos users.  I think we can go further to
eliminate dependencies on DNS, including:

  * principal alias support
  * improved referrals support

> - Misc bug and performance diffs
>
>     This would take some work to go through our bugtracking DB/code. 
>
> Thoughts as to whether this goal is achievable and on an approach if so?

I think it is a good goal to make MIT krb5 suitable for drop-in use in
Solaris.  I think we can best accomplish this by taking as many of the
Solaris changes as are suitable and making them useful on a
cross-platform basis, and collaborate on making the code converge in
places where we need to resolve significant differences.  This can
also help other vendors of MIT krb5 if we are careful, so that many
people can benefit.

Having a prioritized list of the desired changes would be helpful, and
knowing any relevant time constraints would also be useful.  I expect
to evaluate Sun's suggestions in more detail in the near future,
probably in separate message threads on this mailing list.

-- 
Tom Yu
Development Manager
MIT Kerberos Consortium