GSS/SPNEGO/mechglue/krb5 patches for 1.8
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
* 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