Re: multi-mechanism gssapi

[Luke Howard <lukeh@PADL.COM>]

Making some progress. Status so far:

  o fixed Sun mechglue to use Heimdal APIs where possible

  o various code cleanups to harmonize with Heimdal code
    (eg dynamic loading API)

  o fixed a bunch of bugs/limitations in the Sun code (eg.
    handling of exported names, zeroing out invalid context
    handles, etc)

  o added the following fields to the glue dispatch table:
    gss_get_mic, gss_wrap, gss_unwrap, gss_canonicalize_name,
    gss_export_name, gss_wrap_ex, gss_unwrap_ex,
    gss_complete_auth_token, gss_set_neg_mechs, 
    gss_get_neg_mechs, gss_inquire_sec_context_by_oid,
    gss_inquire_cred_by_oid, gss_set_sec_context_option
 
  o added gss_copy_oid, gss_duplicate_oid,
    gss_encapsulate_token, gss_decapsulate_token GNU
    extensions

  o added gss_create_empty_buffer_set, gss_add_buffer_set_member,
    gss_release_buffer_set, gss_inquire_sec_context_by_oid,
    gss_inquire_cred_by_oid, gss_set_sec_context_option GGF
    extensions

  o separated SPNEGO, Kerberos mechanisms into separate
    directories (Kerberos is still in lib/gssapi; SPNEGO
    is in lib/spnego; glue is in lib/mechglue)

  o mech-specific extensions (eg. gss_krb5_get_tkt_flags)
    are implemented on top of the GGF extension API, so 
    that they can be used with glue contexts

SPNEGO and Kerberos are working. SPNEGO will advertise and
negotiate amongst all glued mechs, including dynamically
loaded ones.

I'll work with Love to get the code merged once it is stable
and we have had a chance to interop test the RFC2478bis
(interoperable and protected SPNEGO) support with Larry.

-- Luke

--