On Fri, Oct 28, 2011 at 5:17 PM, Luke Howard <[email protected]> wrote: >> Section 4 - does/should the application get any control ovret the set of >> allowable EAP methods to be used or is that purely a fucntion of your >> GSS-API library > > That's a good question. The application can select which GSS EAP variants > (i.e. encryption type) using GSS_Set_neg_mechs (RFC 4178). But I'm not sure > how the application might select EAP methods. Sounds like something we could > make a settable attribute on either the credential or context object.
Oh, two-level negotiation. I've wondered before about this. We in the SASL/GSS community have grown to dislike two-level negotiations very much. The primary issue relates to cryptographic strength. I expect GSS-EAP to not imply a two-level negotiation for per-msg token enctypes. But a two-level negotiation for authentication would not exactly be great. IHow about an option of OID per EAP method, and an OID for the variant that will negotiate any EAP method? Nico -- _______________________________________________ abfab mailing list [email protected] https://www.ietf.org/mailman/listinfo/abfab
