Hi,

I think it would be very good if IETF/EMU could agree on simpler, more 
automatic, and secure deployment and configuration of TLS-based EAP methods. 
This is severely needed. Both complexity and security are very real problems.

https://threatpost.com/misconfiguration-university-wifi-login-credentials/175157/

RFC 8446, RFC 5216, and draft-ietf-emu-eap-tls13 does not give much guidance on 
this and the security requirement for cerficates are soft.

Any work should likely align with 
https://datatracker.ietf.org/doc/draft-ietf-uta-rfc6125bis/

I have not read draft-dekok-emu-eap-usability-00 yet. Inter-operability issues 
between implementations seems to be an issue, how easy will it be to reach 
consensus between different implementations?

Cheers,
John

From: Emu <[email protected]> on behalf of Alan DeKok 
<[email protected]>
Date: Friday, 16 July 2021 at 21:32
To: Carolin Baumgartner <[email protected]>
Cc: [email protected] <[email protected]>
Subject: Re: [Emu] Version Notification for draft-dekok-emu-eap-usability-00.txt
On Jul 16, 2021, at 6:26 AM, Carolin Baumgartner <[email protected]> 
wrote:
>>   Provided there's some network connection available, everything else can be 
>> automatic.
> ah yes. I guess it might make sense to make that clear towards the beginning 
> of the document :-) I only got a later ....

  I'll definitely fix that.

> I finished the document now and really like it. I just think the normative 
> part comes quite late in the document. Maybe it should also be referenced in 
> earlier sections. To make it stronger, you could even use SHOULD instead of 
> RECOMMENDED (in section 8.2), I guess

  SHOULD and RECOMMENDED are synonyms for this purpose.

  I left the normative bits to the end because I wanted to explain the problem, 
and then give examples of the solution first.  Once those are clear, they then 
motivate the normative text.

  I found that if I put the normative text earlier, then people would ask "why 
these decisions?", only to have them answered later in the document.

  Alan DeKok.

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

Reply via email to