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
