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

[Will Fiveash]

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. 

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

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

typedef struct _krb5_keyblock {
    krb5_magic magic;
    krb5_enctype enctype;
    unsigned int length;
    krb5_octet *contents;
    krb5_dk_node   *dk_list; /* list of keys derived from this key */
#ifdef _KERNEL
    crypto_mech_type_t     kef_mt;
    crypto_key_t           kef_key;
    crypto_ctx_template_t  key_tmpl;
#else
    CK_OBJECT_HANDLE       hKey; /* PKCS#11 key object handle */
    pid_t	pid; /* fork safety */
#endif /* _KERNEL */
} krb5_keyblock;

    This creates an ABI difference between Solaris and MIT.

- 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.
    For example, in OpenSolaris there is this code in
    usr/src/lib/gss_mechs/mech_krb5/et/chpass_util_strings.c:

const char *
ovku_error_table(long errorno) {

switch (errorno) {
        case 0:
                return (dgettext(TEXT_DOMAIN,
                        "while getting policy info.\n"));
        case 1:
                return (dgettext(TEXT_DOMAIN,
                        "while getting principal info.\n"));
...

    Solaris krb may have some diffs in the message strings. etc...  
    
    Also Solaris calls gettext() to translate various non-error table
    messages.  Anyway, this is an area that we need to research further
    to find a reasonable solution.

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

- Auditing

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

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

- Changes in *.conf files and other parameters?

    - File locations - default krb5.conf, kdc.conf in /etc/krb5
    - Different defaults for some configuration variables

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

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

- No reverse DNS lookup in krb5_sname_to_principal()

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

-- 
Will Fiveash
Sun Microsystems Inc.
http://opensolaris.org/os/project/kerberos/