our SPNEGO direction

[Derek Atkins]

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

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord at MIT.EDU                        PGP key available