On May 7, 2021, at 4:09 PM, Jorge Vergara <[email protected]> wrote:
> The Windows implementation is using draft-13 exporters; it is not possible to 
> change at this point unless a critical technical issue that prevents 
> functionality or impacts security were to be discovered. I don't think this 
> is such an issue. The preference to keep draft-13 exporters was discussed at 
> IETF 110 and I do not recall any objection. The draft-15 exporter is 
> problematic for Windows at this point.

  The interop report involved Microsoft, FreeRADIUS, and hostap.  All have 
implemented the -13 exporters, and the 0x00 Commitment message.  
Interoperablity has been demonstrated to the satisfaction of all participants.

  Pretty much everyone else with supplicant and/or RADIUS server 
implementations is out of the loop.  They're either unaware of this work, or 
have no opinions on it.

  From the Open Source side, it's easy to change code.  But I will not ship a 
product which fails to interoperate with the dominant supplicant platform.

  I see no major security issues with the -13 exporters.  It's "nicer" to use 
separate labels, but it's not critically important for the security of the 
protocol.

> I have fewer opinions on the less-technical areas of the draft. One of my 
> flaws as an implementor of several EAP methods is that I can parse the 
> current draft and assume enough intent to complete my implementation. I do 
> call out questions I have - but I sometimes make assumptions without 
> realizing due to prior experience in the area. This may be true of several 
> others in the working group as well. Non-implementors don't have the luxury 
> of this experience and I think it is extremely difficult to create a secure 
> and robust EAP method implementation from scratch. The more guidance toward 
> this goal that can be included in the document the better, in my opinion.

  I agree.

  I have expressed strong opinions that the document gives insufficient 
guidance to implementors.  For me, "rough consensus and running code" means I 
should be able to say the following, and be taken seriously:

  "Hi, as someone with running code, I believe that it is critical for the 
specification to say X, in order to address implementation and interoperability 
issues".

  It's surprising when the response to such a comment is "No".

  Alan DeKok.

_______________________________________________
Emu mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/emu

Reply via email to