> -----Original Message----- > From: Nico Williams [mailto:[email protected]] > Sent: Friday, October 28, 2011 4:02 PM > To: Luke Howard > Cc: Jim Schaad; [email protected]; [email protected] > Subject: Re: [abfab] Review on gss-eap-03 > > 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.
I don't think that is an issue for this. I would assume that the EAP method is going to be required to generate enough bytes for the selected GSS-API key derivation function. > > 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
