our SPNEGO direction

[Sam Hartman]

>>>>> "Wyllys" == Wyllys Ingersoll <wyllys.ingersoll at sun.com> writes:

    Wyllys> Sam Hartman wrote:

    Wyllys> Thats too bad, IMO.  It would be very nice if the current
    Wyllys> MIT GSSAPI code were not so tightly coupled with the
    Wyllys> underlying mech (krb5).  

Well, that's why I did evaluate the umich patch.  But unless someone
is willing to write code and give it to MIT under a license MIT will
accept, then wanting mechglue is very likely to continue to be a
nothing more than a desire.

If someone has serious time or money to dedicate to this project we'd
be happy to discuss design and some of our portability concerns.  I do
believe it is not particularly difficult to do the mechglue layer; I
simply don't have time and don't ex pect MIT to have time in the
future.


If the community believes that a SPNEGO mechanism available in 1.3
that could be plugged into a mechglue layer when it becomes available
is not useful, then we'd be happy to go work on something else.

    Wyllys> nice (i.e. a truly pluggable GSSAPI architecture).

    Wyllys> SPNEGO is important for interoperating with Microsoft,
    Wyllys> though there are lots of other potential uses, MS seems to
    Wyllys> make heavy use of it.  So, it would be more useful if a
    Wyllys> future SPNEGO mech would be able to negotiate more than
    Wyllys> just Kerberos.

Yes.

    Wyllys> The benefits of a pluggable GSSAPI combined with a SPNEGO
    Wyllys> mech that can negotiate multiple mechanisms are
    Wyllys> significant and the lack thereof is delaying the
    Wyllys> introduction of some very useful security features
    Wyllys> throughout the open source community.


Yes, having a SPNEGO mechanism would be useful to the open source
community.  I do not see why the open source community needs pluggable
GSSAPI to take advantage of SPNEGO.  Apache and Mozilla could add
support for John's draft even if the SPNEGO they use only supports
krb5.

They will not have to change their code if a mechglue layer becomes
available and other mechanisms are plugged in.

It does mean they will not get NTLM supporttoday.  While I understand
that NTLM might be useful to global interoperability goals, it is out
of scope for MIT Kerberos.

Again, it is our intent to work on SPNEGO because we believe the lack
of an open source SPNEGO mechanism is preventing certain Microsoft
protocols from easily being implemented in the open source community.
We do not preclude the use of non-Kerberos mechanisms and are working
to design our SPNEGO support to be easily plugged into a mechglue
layer if that should be a future option.  Since we are working on
Kerberos, we are focusing on Kerberos as the mechanism we care about
negotiating.

If our customers do not believe Kerebros-only SPNEGO would be useful,
we can certainly focus efforts elsewhere.  But we do not have
resources to deal with the mechglue layer.