On Sun, Oct 30, 2011 at 6:38 PM, Luke Howard <[email protected]> wrote: >> mechanism-negotiation mechanism, sort of. Of course, the way these >> functions work we'll need something better in the case of SPNEGO being >> used to negotiate GSS-EAP. We really need a notion of credentials >> acquired with credentials, so that we can first acquire a credential >> handle for GSS-EAP, set what methods it will negotiate, then pass >> *that* credential handle to another function for acquiring a larger >> credential set. In other words, we need a new credential set model >> for GSS, and the best thing to do for now is to punt. > > Could you use gss_add_cred() for this?
Sadly, no. You'd think, by its name, but it would need *two* input credential handles to do what we need it to. I.e., we need a GSS_Add_cred_to_cred_set() that takes one credential handle that is to be an element of the other. We'd then need not GSS_Set_neg_mechs() but GSS_Set_net_creds(). I.e., we want credential handles as sets of credential handles, with credentials for mechanism-negotiation mechanisms themselves acting as sets (nested sets). > Myself, I find gss_acquire_cred() + gss_set_cred_option(EAP_METHODS) easier > to understand, particularly if this kind of application-level configurability > is an edge case (I really want applications not to have to worry about this; > rather, they use SPNEGO, and the mechanism and/or its credential manager > sorts things out for you). GSS_Add_cred() was a mistake :( We may need a wrapper around all this to make GSS dead simple for most apps. Nico -- _______________________________________________ abfab mailing list [email protected] https://www.ietf.org/mailman/listinfo/abfab
