our SPNEGO direction

[Wyllys Ingersoll]

No, and I don't see where that is even remotely relevant.
Kerberos as it stands today does not support *EVERY*
OS out there.  It does work quite well on almost all of
the "major" OS's  - most flavors of Unix, Windows, Mac,
VMS, ... Forgive me if I don't name every single
OS in existence.

The primary requirement for making this a pluggable
is the ability to dynamically load a library at run time.
Can you name a major OS that does not support
this feature and lacks any sort of "workaround" for
the lack thereof?  Im sure you can probably name a
couple, but how relevant are they and is it a fixed
requirement that everything released must support that
OS?)

I'm not bashing the work thats been done, my suggestion
was just that a pluggable GSS architecture is vastly more
useful than one that is hard coded to support only a fixed
and precompiled set of mechanisms.   The whole point
of SPNEGO is to be able to support multiple mechanisms
transparently, I think this concept goes hand-in-hand
with the idea of a pluggable architecture.
As long as this is still in the design stages, I thought I'd
bring it up as something to consider.

-Wyllys


Derek Atkins wrote:
> Can you provide a portable plug-in architecture that is absolutely
> guaranteed to work on _every_ OS out there?
> 
> -derek
> 
> Wyllys Ingersoll <wyllys.ingersoll at sun.com> writes:
> 
> 
>>Sam Hartman wrote:
>>
>>>Here are some implementation notes I've written up on where we're
>>>going with SPNEGO.  So far, the basic design has been reviewed by Tom
>>>Yu and myself.  I evaluated the umich mechglue patch in hopes of
>>>actually writing a multi-mechanism spnego implementation.  However I
>>>don't think the code is ready to be integrated and the author of the
>>>patch indicated he wanted to rethink it, so we're not going that
>>>route.
>>>
>>
>>Thats too bad, IMO.   It would be very nice if the current MIT GSSAPI
>>code were not so tightly coupled with the underlying mech (krb5).
>>Introducing a new SPNEGO mech that is further tied together
>>with the current gss_krb5 stuff seems to be of limited value.
>>A GSS architecture that would allow for new mechanisms to be
>>added without having to mess with the main GSS-API itself
>>would be very nice (i.e. a truly pluggable GSSAPI architecture).
>>
>>SPNEGO is important for interoperating with Microsoft,
>>though there are lots of other potential uses, MS seems to make
>>heavy use of it.   So, it would be more useful if a future SPNEGO
>>mech would be able to negotiate more than just Kerberos.
>>
>>The benefits of a pluggable GSSAPI combined with a SPNEGO
>>mech that can negotiate multiple mechanisms are significant
>>and the lack thereof is delaying the introduction of some
>>very useful security features throughout the open source
>>community.
>>
>>* Mozilla project could take advantage of a truly pluggable SPNEGO/GSSAPI
>>    architecture to implement the HTTP  Auth-Negotiate
>>    method (John Brezak's draft for http auth).
>>* Apache folks could then use SPNEGO to add support on the server side
>>    for the same draft, thus giving open source community the ability
>>    to authenticate with same security as IE+IIS users.
>>
>>
>>-Wyllys Ingersoll
>>
>>
>>>		 Implementation Notes for MIT Spnego
>>>Currently the SPNEGO mechanism is closely associated with the krb5
>>>mechanism.  By default if no OID is passed into the desired_mech
>>>parameter of gss_init_sec_context then the krb5 mechanism is used.  If
>>>the SPNEGO OID is passed in the SPNEGO is used.  By default
>>>gss_accept_sec_context allows either mechanism but if an explicit OID
>>>is passed in then that OID must be used.
>>>Since both SPNEGO with a krb5 mech and krb5 use the same credentials,
>>>you cannot control which mechanism is used at the credential level.
>>>The SPNEGO code is split into four driver functions:
>>>* gssint_spnego_initbefore
>>>* gssint_spnego_initafter
>>>* gssint_spnego_acceptbefore
>>>* gssint_spnego_acceptafter
>>>The _before functions  will unwrap   and decode a SPNEGO token
>>>returning any mechanism token within the  spnego token.  The calling
>>>sequence and control flow characteristics of the _before
>>>functions is similar to that of gss_init_sec_context and
>>>gss_accept_sec_context .  They can output both a mechanism token and a
>>>response token, although at most one of these outputs will be
>>>used. The functions can return  in the following manners:
>>>* GSS_S_COMPLETE with no output tokens: caller should return
>>>  GSS_S_COMPLETE and context is set up.  If mechanism level routines
>>>  have not yet returned GSS_S_COMPLETE, then caller should treat this
>>>  as an error.
>>>* GSS_S_CONTINUE_NEEDED with a response token:  Caller should return
>>>  GSS_S_CONTINUE_NEEDED with the response token provided and not
>>>  update the context state.  This happens for example if
>>>  gssint_spnego_initbefore notes that the target does not
>>>  support optimistic negotiation and the mechanism token must be
>>>  resent.  * GSS_S_CONTINUE_NEEDED with a mechanism token: caller
>>>should process
>>>  mechanism token .
>>>* An error, possibly with a response token: Caller should return
>>>error
>>>and response token.
>>>Note that neither of the before functions deals with the peer
>>>selecting a non-default mechanism at all.  That's just not currently
>>>supported.
>>>The _after functions have significantly less complex control flow.
>>>They will return one of:
>>>* GSS_S_COMPLETE   possibly with a response token--no additional
>>>calls
>>>  expected
>>>* GSS_S_CONTINUE_NEEDED with a response token
>>>* Some error possibly with a response token
>>>Note that even if the inputs to gssint_spnego_*_after indicate that
>>>GSS_S_COMPLETE will be returned, the *_after may decide that
>>>GSS_S_CONTINUE_NEEDED should be returned.  This means that another
>>>SPNEGO token is expected even though no mechanism tokens are expected.
>>>In this case, the next call to the appropriate _before function should
>>>be expected to return GSS_S_COMPLETE.
>>>		     Expanding to multi-mechanism
>>>Here are changes that may need to be rolled back to expand to a
>>>multi-mechanism usage.
>>>* Calls to spnego functions have been integrated into
>>>  krb5_gss_init_sec_context and krb5_gss_accept_sec_context.
>>>* Credential management functions  know about the SPNEGO mechanism
>>>In addition, support in the _before functions to deal with changing
>>>mechanism types is needed.  In particular
>>>gssint_spnego_initbefore needs to delete the existing
>>>mechanism context if the target chooses a mechanism different than the
>>>optimal one.
>>>_______________________________________________
>>>krbdev mailing list             krbdev at mit.edu
>>>http://mailman.mit.edu/mailman/listinfo/krbdev
>>
>>
>>_______________________________________________
>>krbdev mailing list             krbdev at mit.edu
>>http://mailman.mit.edu/mailman/listinfo/krbdev
> 
>