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

[Nicolas Williams]

On Fri, Sep 19, 2008 at 03:36:04PM -0400, Tom Yu wrote:
> > - 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.

Indeed.  Solaris' krb5 stack uses PKCS#11 in user-land, so if MIT were
to adopt this then others could potentially plug in FIPS 140-2 compliant
PKCS#11 libraries/tokens.

> >     This creates an ABI difference between Solaris and MIT.
> 
> We could choose to deprecate the old ABI, or make compatibility glue
> to support it.

I see three options:

1)  MIT deprecates the old ABI
2)  MIT adds a configure switch to select ABIs
2a) and MIT adds a look-aside buffer as I described before along with
    PKCS#11 support
3)  (2a) and Solaris switches to using MIT krb5 without crypto mods
    (except for kernel-land)

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

gettext() can be used with non-constant strings expressions, provided
the expression in question ultimately evaluates to string as it appears
in the catalog.

Usually gettext() is used with constant strings because the xgettext(1)
utlity knows to extract those for localization.

For example SunSSH uses GNU xgettext() to extract constant strings from
calls to functions like 'debug()', 'debug2()', 'error()', 'fatal()',
etc...  And those functions, in turn, pass their first argument to
gettext() (i.e., gettext() in SunSSH gets called with non-constant
string expressions most of the time).

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

Good point.  And moving parts of krb5kdc into libkrb5 to make it easier
to build PKU2U would help (but that's a whole 'nother story).

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

Yes, KDC side.  But Solaris Kerberos auditing needs significant
revamping.  For example, it would be quite useful to include hashes of
the Ticket issued and a hash of the Ticket used in PA-TGS-REQ (and
Tickets in additional-tickets, for u2u) in audit messages -- this could
help track individual sessions across multiple hosts/KDCs/realms.
(pam_krb5/login apps should also audit the hash of the TGT and service
Ticket used during authentication, but that's well outside MIT krb5
right now.)

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

I agree.  The single most important additions would be:

 - a way to pass a gss_name_t for the targ_name to the RPCSEC_GSS client
   library, rather than just a string as is the case now;

 - a way to pass in a gss_cred_id_t (if there isn't one already -- I
   forget!)

 - client- and server-side functions for obtaining/releasing references
   to an XPRT's GSS-API context handle(s)

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

I don't think so.  But wasn't there a plan to fold kdc.conf into
krb5.conf?  What's the status of that?

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

Yes!  (See other e-mails in this thread.)

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

I agree.

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

(I won't comment on priorities since I'm not in the Solaris Kerberos
team.)

Nico
--