>>>>> "Nico" == Nico Williams <[email protected]> writes:
Nico> 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.
Nico> Oh, two-level negotiation. I've wondered before about this.
Nico> We in the SASL/GSS community have grown to dislike two-level
Nico> negotiations very much. The primary issue relates to
Nico> cryptographic strength. I expect GSS-EAP to not imply a
Nico> two-level negotiation for per-msg token enctypes. But a
Nico> two-level negotiation for authentication would not exactly be
Nico> great.
Please see the discussion in section 4.
I thought we already had consensus on this approach even though it was a
Nico> two-level approach.
If we do I am not in favor of opening it again.
Nico> IHow about an option of OID per EAP method, and an OID for the
Nico> variant that will negotiate any EAP method?
The main problem with this is that the acceptor does not choose or
influence the EAP method. The EAP method is a factor of what identity
is chosen. IT's like proposing an OID for kerberos plus a particular
preauth type.
--Sam
_______________________________________________
abfab mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/abfab
