our SPNEGO direction
warlord at MIT.EDU
Mon Nov 11 10:50:00 EST 2002
Can you provide a portable plug-in architecture that is absolutely
guaranteed to work on _every_ OS out there?
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
> * 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
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
More information about the krbdev