> I think Luke suggested using the SPNEGO gss_get/set_neg_mechs() > functions for this. I.e., you could treat GSS-EAP as a
I wasn't actually suggesting this, I just noted you could use it to select which GSS EAP enctypes to select, but not the underlying EAP method. Using gss_set_cred_option() would work today (even on an SPNEGO credential, because non-EAP GSS mechanisms will ignore the call). > 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? 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). -- Luke _______________________________________________ abfab mailing list [email protected] https://www.ietf.org/mailman/listinfo/abfab
