our SPNEGO direction

[Kevin Coffman]

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


We should talk more about what we currently have, and what
you'd like to see in order for it to be accepted back.  My
current priority is to get the RPC code into an acceptable
state, but the mechglue code is important to us as well.


> 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.
> _______________________________________________
> krbdev mailing list             krbdev at mit.edu
> http://mailman.mit.edu/mailman/listinfo/krbdev
>