On Sun, Oct 30, 2011 at 6:20 PM, Sam Hartman <[email protected]> wrote: >>>>>> "Jim" == Jim Schaad <[email protected]> writes: > Jim> Section 4 - does/should the application get any control ovret > Jim> the set of allowable EAP methods to be used or is that purely a > Jim> fucntion of your GSS-API library > > Currently no mechanism is provided for an application to enfluence this. > A mechanism probably should have system-level policy configuration. > A mechanism could expose a credential option on the initiator. > If we ever need to standardize a credential option we can, but I don't > see a need for that now.
I think Luke suggested using the SPNEGO gss_get/set_neg_mechs() functions for this. I.e., you could treat GSS-EAP as a 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. I don't see configuration as being satisfactory for this in the long-term. Nico -- _______________________________________________ abfab mailing list [email protected] https://www.ietf.org/mailman/listinfo/abfab
