Subject: [Emu] Version Notification for draft-dekok-emu-eap-usability-00.txt

From: Alan DeKok <[email-masked]>
Date: Mon, 12 Jul 2021 13:57:37 -0400

I've submitted an "EAP usability" document.  The title could perhaps be better.

  It gives guidelines, requirements, and practices for making it easier to use TLS-based EAP methods.

  I've asked the chairs for time at the next IETF to discuss this.  Until then, any feedback / comments are welcome.

> Begin forwarded message:
> 
> From: [email-masked]
> Subject: New Version Notification for draft-dekok-emu-eap-usability-00.txt
> Date: July 12, 2021 at 1:55:58 PM EDT
> To: "Alan DeKok" <[email-masked]>
> 
> 
> A new version of I-D, draft-dekok-emu-eap-usability-00.txt
> has been successfully submitted by Alan DeKok and posted to the
> IETF repository.
> 
> Name:		draft-dekok-emu-eap-usability
> Revision:	00
> Title:		EAP Usability
> Document date:	2021-07-12
> Group:		Individual Submission
> Pages:		58
> URL:            https://www.ietf.org/archive/id/draft-dekok-emu-eap-usability-00.txt
> Status:         https://datatracker.ietf.org/doc/draft-dekok-emu-eap-usability/
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-dekok-emu-eap-usability
> 
> 
> Abstract:
>   This document defines methods which enable simpler deployment of TLS-
>   based EAP methods.  It defines new certificate fields, and uses
>   existing certificate fields in order describe new methods for
>   bootstrapping security.  The methods defined here change TLS-based
>   EAP supplicant configuration from a complex and insecure process to
>   one that is automated, and is essentially trivial.  These methods are
>   still, however, compatible with existing standards and practices.
> 
> 
> 
> 
> The IETF Secretariat
> 
>

---

From: Carolin Baumgartner <[email-masked]>
Date: Thu, 15 Jul 2021 16:24:14 +0200

Hi Alan

some first thoughts

Section 3.1, first bullet point on automation: I would mention "zero 
touch". That should be the goal from a user's perspective.

Section 3.1, fifth (sixth) bullet point on mutual exchange of 
identities: How is that supposed to work? Don't get me wrong, I 
understand the rationale. But that requires a user to understand if the 
identity of the server is correct. I don't think that is a safe assumption.

Section 3.1, last bullet point: I agree on the technical rationale. 
However that must be dead simple to verify from a user perspective

General comment: EAP configuration and implementation is certainly one 
issue, but the whole certificate stuff is terrible from a user's point 
of view. We could try to solve it in this draft, but it certainly 
touches a lot of topics.

Will keep reading...

best regards
Carolin

On 7/12/21 7:57 PM, Alan DeKok wrote:
>   I've asked the chairs for time at the next IETF to discuss this. 
>  Until then, any feedback / comments are welcome.
>
>> Begin forwarded message:
>>
>> *From: [email-masked] <mailto:[email-masked]>
>> *Subject: **New Version Notification for 
>> draft-dekok-emu-eap-usability-00.txt*
>> *Date: *July 12, 2021 at 1:55:58 PM EDT
>> *To: *"Alan DeKok" <[email-masked] 
>> <mailto:[email-masked]>>
>>
>>
>> Name:draft-dekok-emu-eap-usability
>> Revision:00
>> Title:EAP Usability
>> Document date:2021-07-12
>> Group:Individual Submission
>> Pages:58
>> URL: 
>> https://www.ietf.org/archive/id/draft-dekok-emu-eap-usability-00.txt 
>> <https://www.ietf.org/archive/id/draft-dekok-emu-eap-usability-00.txt>
>> Status: 
>> https://datatracker.ietf.org/doc/draft-dekok-emu-eap-usability/ 
>> <https://datatracker.ietf.org/doc/draft-dekok-emu-eap-usability/>
>> Htmlized: 
>> https://datatracker.ietf.org/doc/html/draft-dekok-emu-eap-usability 
>> <https://datatracker.ietf.org/doc/html/draft-dekok-emu-eap-usability>
>>
>>
>> Abstract:
> _______________________________________________
> Emu mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/emu

---

From: Alan DeKok <[email-masked]>
Date: Thu, 15 Jul 2021 14:06:06 -0400

On Jul 15, 2021, at 10:24 AM, Carolin Baumgartner <[email-masked]> wrote:
> 
> Section 3.1, first bullet point on automation: I would mention "zero touch". That should be the goal from a user's perspective.

  Sure.

> Section 3.1, fifth (sixth) bullet point on mutual exchange of identities: How is that supposed to work? Don't get me wrong, I understand the rationale. But that requires a user to understand if the identity of the server is correct. I don't think that is a safe assumption. 

  The rest of the document tries to address this.  The idea is that the device uses the web root CAs to download a trusted CA for this domain, when using EAP.  Then, the device can tell the user that the EAP server for this domain is trusted.  Because it has a signed certificate by a known CA.

> Section 3.1, last bullet point: I agree on the technical rationale. However that must be dead simple to verify from a user perspective

  Yes.  It has to be managed automatically.

> General comment: EAP configuration and implementation is certainly one issue, but the whole certificate stuff is terrible from a user's point of view. We could try to solve it in this draft, but it certainly touches a lot of topics.

  The goal of the draft is to leverage the web root, in order to bootstrap trust in EAP.  The only real thing that the user needs to do is to enter:

Name: [email-masked]
Password: superSecret

  Provided there's some network connection available, everything else can be automatic.

  Alan DeKok.

---

From: Carolin Baumgartner <[email-masked]>
Date: Fri, 16 Jul 2021 12:26:05 +0200

>    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 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

best regards
Carolin

---

From: Alan DeKok <[email-masked]>
Date: Fri, 16 Jul 2021 15:32:14 -0400

On Jul 16, 2021, at 6:26 AM, Carolin Baumgartner <[email-masked]> wrote:
> 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.