GSS/SPNEGO/mechglue/krb5 patches for 1.8

Greg Hudson ghudson at MIT.EDU
Wed Feb 3 13:23:23 EST 2010

Where I am on this:

* I don't want to do what Likewise suggests in #6602 (allow SPNEGO
accept_sec_context to work with non-SPNEGO credentials) because it
commits us to doing something clever when fed invalid inputs to our API,
instead of properly rejecting them.

* I think Sam is correct that gss_set_neg_mechs is important for this
use case; if you simply let SPNEGO work with the full set of mechs and
possibly reject the result, you may fail to negotiate an acceptable mech
that you would have otherwise.

* I'm not wild about implementing a new feature halfway through the 1.8
testing period, but if I can do it in the next week that seems like the
best option.

* The only information I can find on gss_set_neg_mechs is in RFC 4178
(the SPNEGO RFC), which doesn't specify the C bindings.  There is no
Heimdal implementation.  I could look at the Sun implementation, though
I'd sort of rather not since it's not under a BSD-compatible license
(perhaps that's paranoia).  I don't see an OpenSolaris implementation

* I don't quite understand the state transfer in the RFC 4178
specification of gss_set_neg_mechs.  You pass in a cred handle and a
mech set.  A NULL cred handle indicates the default credentials.  If you
pass a NULL cred handle, what is the scope of the mech restrictions?
Any SPNEGO gss_accept_sec_context call with a NULL cred handle?

More information about the krbdev mailing list