Subject: [Reap] PSA: New list for discussing EAP related methods

From: Mohit Sethi <[email-masked]>
Date: Thu, 26 Oct 2017 16:02:48 +0300

Dear all,

We have started a mailing list for discussing new EAP related work that 
currently has no obvious home. The mailing list is called REAP (Renew 
EAP) [email-masked] and you can subscribe here:
https://www.ietf.org/mailman/listinfo/reap

Recently several new EAP methods have been proposed. These include for 
example:

EAP-TLS 1.3: https://tools.ietf.org/html/draft-mattsson-eap-tls13-00

EAP-NOOB: https://tools.ietf.org/html/draft-aura-eap-noob-02

EAP-SASL: https://tools.ietf.org/html/draft-vanrein-eap-sasl-00

The list serves as a venue for discussion of these and other EAP related 
drafts that will be submitted in the near future. As courtesy, we will 
post any new draft to SAAG, but we plan to continue the discussion only 
on the REAP mailing list. We have also asked for a short presentation 
slot during SECDISPATCH at IETF 100 in Singapore.

Comments, early feedback, and discussion on existing or new work is more 
than welcome.

--Mohit

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 26 Oct 2017 08:51:54 -0700

There are existing functioning IETF mailing lists relating to EAP.

Why are you starting yet another one?

>From what I can tell, the EAP-TLS 1.3 draft is merely a copy of RFC 5216
(with no acknowledgement to the original authors) stating that EAP-TLS
implementations must support TLS 1.3.

This is ridiculous because there are 1+ Billion existing implementations
out there that

On Thu, Oct 26, 2017 at 6:02 AM, Mohit Sethi <[email-masked]>
wrote:

> currently has no obvious home. The mailing list is called REAP (Renew EAP)
> [email-masked] and you can subscribe here:
> drafts that will be submitted in the near future. As courtesy, we will post
> any new draft to SAAG, but we plan to continue the discussion only on the
> REAP mailing list. We have also asked for a short presentation slot during
> SECDISPATCH at IETF 100 in Singapore.
>
> _______________________________________________
> saag mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/saag
>

---

From: Mohit Sethi <[email-masked]>
Date: Thu, 26 Oct 2017 20:16:25 +0300

Hi Bernard,

The EAP-TLS 1.3 document is a very rough drafty version that was 
submitted before the cut-off for the last IETF. As you rightly point 
out, it has the skeleton and a lot of material from RFC5216, and still 
many important details are missing.

The purpose of this list is to exactly receive these kind of comments. 
Should RFC5216 be updated or obsoleted by this draft. And it would be 
great if we can have your contributions to the document. We will 
definitely add an acknowledgement section and contact the authors of 
RFC5216 to see if they can contribute and comment. We plan to have more 
EAP related contributions in the near future. We discussed this with the 
Security ADs and thought that a separate list would be appropriate to 
get feedback/criticism and contributions from the folks interested.

--Mohit

On 10/26/2017 06:51 PM, Bernard Aboba wrote:
> From what I can tell, the EAP-TLS 1.3 draft is merely a copy of RFC 
> 5216 (with no acknowledgement to the original authors) stating that 
> EAP-TLS implementations must support TLS 1.3.
>
> This is ridiculous because there are 1+ Billion existing 
> implementations out there that
>
>
> On Thu, Oct 26, 2017 at 6:02 AM, Mohit Sethi 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     Dear all,
>
>     We have started a mailing list for discussing new EAP related work
>     that currently has no obvious home. The mailing list is called
>     REAP (Renew EAP) [email-masked] <mailto:[email-masked]> and you can
>     subscribe here:
>     <https://www.ietf.org/mailman/listinfo/reap>
>
>     Recently several new EAP methods have been proposed. These include
>     for example:
>
>     EAP-TLS 1.3:
>     https://tools.ietf.org/html/draft-mattsson-eap-tls13-00
>     <https://tools.ietf.org/html/draft-mattsson-eap-tls13-00>
>
>     <https://tools.ietf.org/html/draft-aura-eap-noob-02>
>
>     <https://tools.ietf.org/html/draft-vanrein-eap-sasl-00>
>
>     The list serves as a venue for discussion of these and other EAP
>     related drafts that will be submitted in the near future. As
>     courtesy, we will post any new draft to SAAG, but we plan to
>     continue the discussion only on the REAP mailing list. We have
>     also asked for a short presentation slot during SECDISPATCH at
>     IETF 100 in Singapore.
>
>     Comments, early feedback, and discussion on existing or new work
>     is more than welcome.
>
>     --Mohit
>
>     [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/saag>
>
>
>
>

---

From: Yoav Nir <[email-masked]>
Date: Thu, 26 Oct 2017 20:55:24 +0300

> On 26 Oct 2017, at 18:51, Bernard Aboba <[email-masked]> wrote:
> 

+1

The EMU mailing list seems appropriate.

Yoav

https://tools.ietf.org/wg/emu/ <https://tools.ietf.org/wg/emu/>
https://www.ietf.org/mail-archive/web/emu/current/maillist.html <https://www.ietf.org/mail-archive/web/emu/current/maillist.html>

---

From: David Mitton <[email-masked]>
Date: Thu, 26 Oct 2017 10:45:02 -0400

I’m sorry, it’s been a while since I paid attention.
So EMU has been closed, and you didn’t want to recycle the acronym?
It might be useful to review the progress of the methods that came out of EMU.

Dave.

Sent from Mail for Windows 10

From: Mohit Sethi
Sent: Thursday, October 26, 2017 9:04 AM
To: [email-masked]; [email-masked]
Subject: [saag] PSA: New list for discussing EAP related methods

Dear all,

--Mohit

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

---

From: Alan DeKok <[email-masked]>
Date: Thu, 26 Oct 2017 14:43:43 -0400

> On Oct 26, 2017, at 10:45 AM, David Mitton <[email-masked]> wrote:
> 

  The main output of EMU was TEAP.  While it may be implemented somewhere, I'm now aware of it's existence in any popular OS, or any wide-spread use of it.

  Alan DeKok.

---

From: Kathleen Moriarty <[email-masked]>
Date: Thu, 26 Oct 2017 14:53:36 -0400

On Thu, Oct 26, 2017 at 1:16 PM, Mohit Sethi <[email-masked]> wrote:
> Hi Bernard,
>
> The EAP-TLS 1.3 document is a very rough drafty version that was submitted
> before the cut-off for the last IETF. As you rightly point out, it has the
> skeleton and a lot of material from RFC5216, and still many important
> details are missing.
>
> Should RFC5216 be updated or obsoleted by this draft. And it would be great
> if we can have your contributions to the document. We will definitely add an
> acknowledgement section and contact the authors of RFC5216 to see if they
> can contribute and comment. We plan to have more EAP related contributions
> in the near future. We discussed this with the Security ADs and thought that
> a separate list would be appropriate to get feedback/criticism and
> contributions from the folks interested.

I'm sorry, I didn't realize that a revision of 5216 was involved and
that the authors were not notified at the onset as is normal practice
in case they want to continue as authors.  Thank you for spotting this
issue Bernard.

Is there an existing list that should be used?  Is there adequate
overlap in objectives and personnel?

Thank you,
Kathleen

> This is ridiculous because there are 1+ Billion existing implementations out
> there that
>
>

-- 

Best regards,
Kathleen

---

From: Mohit Sethi <[email-masked]>
Date: Thu, 26 Oct 2017 22:51:31 +0300

Hi Yoav,

Thanks for the feedback. This issue about the list had come up a short 
while back when Rick posted his draft on EAP-SASL to SAAG: 
https://mailarchive.ietf.org/arch/msg/saag/stEf0BxTPKGEJq-2RDrlKj1rxRc

We thought that it would make sense to have a separate mailing list on 
all new EAP related work. This would also allow us to gauge the 
community interest in the new work.

At the end of the day, I believe our objectives are the same: we want to 
work on things that the IETF as a community is interested in, and make 
sure that the work progresses at an acceptable pace.

--Mohit

On 10/26/2017 08:55 PM, Yoav Nir wrote:
>
>
>> On 26 Oct 2017, at 18:51, Bernard Aboba <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
> https://tools.ietf.org/wg/emu/
> https://www.ietf.org/mail-archive/web/emu/current/maillist.html
>
>
>
> REAP mailing list
> [email-masked]

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 26 Oct 2017 18:02:47 -0700

I have nothing against TLS 1.3, but it was not necessary to obsolete RFC
5216 to support TLS 1.2 and there are a number of implementations of TLS
1.3 already in progress with no issues as far as I am aware. So I don't
understand why a new document is needed - and the downside is very
substantial.

Given the prevalence of EAP-TLS in open source, there is great concern over
the introduction of encumbrance into a protocol that is widely required in
high security environments.  Were this to happen, it would in effect impose
a "tax" on each of the 2+ billion devices implementing EAP-TLS.

A cursory search of the IETF IPR database indicates that your draft could
potentially encumber EAP-TLS with a vast number of TLS-related IPR
declarations that would not necessarily apply to an RFC 5216
implementation. While there are  many installations that wish to take on
the costs (and benefits) of TLS 1.3 as well as support for additional
ciphersuites, there are also installations that would not be willing to pay
for the costs of a "forklift" upgrade for every device and server,
particularly if they were forced to migrate off of open-source due to IPR
encumbrance.  Such a migration should be up to the organization deploying
EAP-TLS, not imposed by the IETF without extra-ordinary justification (such
as an unpatcheable vulnerability found in previous versions of TLS).

In addition, the introduction of support for new authentication modes such
as PSK was explicitly rejected by for RFC 5216 in EMU because it
complicated the security analysis and would invalidate existing EAP-TLS
security proofs that were considered critical to deployment in the highest
security installations.  When an organization deploys EAP-TLS today they
know what they are getting - a protocol focused on certificate
authentication that does not attempt to be a "swiss army knife".  Such a
protocol isn't for everyone (indeed, only a small fraction of all EAP
deployments use EAP-TLS), but those that mandate its use have very specific
needs.

On Thu, Oct 26, 2017 at 10:16 AM, Mohit Sethi <[email-masked]>
wrote:

> if we can have your contributions to the document. We will definitely add
> an acknowledgement section and contact the authors of RFC5216 to see if
> they can contribute and comment. We plan to have more EAP related
> contributions in the near future. We discussed this with the Security ADs
> and thought that a separate list would be appropriate to get
> feedback/criticism and contributions from the folks interested.
>
> --Mohit
>
> saag mailing [email-masked]://www.ietf.org/mailman/listinfo/saag
>
>
>

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 26 Oct 2017 18:07:25 -0700

Creating a separate list has real drawbacks and very little in the way of
benefits.

If your desire is to get feedback from EAP implementers, why not post on a
list they already subscribe to (such as EMU)?

Creating a new list is in effect requiring those people to actively decide
to pay attention to your work, rather than you bringing the work to them.

For a protocol that is more than 20 years old, with dozens of
implementations and billions of existing devices, this is not a sound way
to move forward.

On Thu, Oct 26, 2017 at 12:51 PM, Mohit Sethi <[email-masked]>
wrote:

> We thought that it would make sense to have a separate mailing list on all
> new EAP related work. This would also allow us to gauge the community
> interest in the new work.
> work on things that the IETF as a community is interested in, and make sure
> that the work progresses at an acceptable pace.
>
> --Mohit
>
>
> REAP mailing [email-masked]://www.ietf.org/mailman/listinfo/reap
>
>
>

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 26 Oct 2017 18:16:04 -0700

Yes, the EMU WG  list has been used for discussion of EAP methods since the
WG closed.

That list is a better venue for discussion of EAP  methods than a new REAP
list, so as to ensure that proper attention is paid to backward
compatibility, IPR, security properties and other critical aspects of EAP
method design.

After all, we are talking about a protocol that is 20+ years old that is
implemented on billions of devices, many of which utilize open-source.

On Thu, Oct 26, 2017 at 11:53 AM, Kathleen Moriarty <
[email-masked]> wrote:

> submitted
> great
> out
> > On Thu, Oct 26, 2017 at 6:02 AM, Mohit Sethi <[email-masked]
> >
> > wrote:
> >>
> >> Dear all,
> >>
> EAP)
> post

---

From: Kathleen Moriarty <[email-masked]>
Date: Thu, 26 Oct 2017 21:43:31 -0400

That sounds like the best plan.

Thank you,
Kathleen 

Sent from my iPhone

> On Oct 26, 2017, at 9:16 PM, Bernard Aboba <[email-masked]> wrote:
> 
> Yes, the EMU WG  list has been used for discussion of EAP methods since the WG closed. 
> 
> That list is a better venue for discussion of EAP  methods than a new REAP list, so as to ensure that proper attention is paid to backward compatibility, IPR, security properties and other critical aspects of EAP method design. 
> 
> After all, we are talking about a protocol that is 20+ years old that is implemented on billions of devices, many of which utilize open-source.  
> 
> 
> 
> 
> 
> 
> 
> 
>> On Thu, Oct 26, 2017 at 11:53 AM, Kathleen Moriarty <[email-masked]> wrote:

---

From: Eliot Lear <[email-masked]>
Date: Fri, 27 Oct 2017 13:55:08 +0200

Kathleen,

So the plan is to close reap and use emu?

Eliot

On 10/27/17 3:43 AM, Kathleen Moriarty wrote:
> On Oct 26, 2017, at 9:16 PM, Bernard Aboba <[email-masked]
>> That list is a better venue for discussion of EAP  methods than a new
>> REAP list, so as to ensure that proper attention is paid to backward
>> compatibility, IPR, security properties and other critical aspects of
>> EAP method design. 
>>
>> After all, we are talking about a protocol that is 20+ years old that
>> is implemented on billions of devices, many of which utilize
>> open-source.  
>>
>>
>>
>>
>>
>>
>>
>>
>> On Thu, Oct 26, 2017 at 11:53 AM, Kathleen Moriarty
>> <[email-masked]
>> <mailto:[email-masked]>> wrote:
>>
>>     On Thu, Oct 26, 2017 at 1:16 PM, Mohit Sethi
>>     >> [email-masked] <mailto:[email-masked]> and you can subscribe here:
>>     >> EAP-SASL:
>>     https://tools.ietf.org/html/draft-vanrein-eap-sasl-00

---

From: Kathleen Moriarty <[email-masked]>
Date: Fri, 27 Oct 2017 14:07:48 -0400

EKR and I chatted and agree using EMU is the best go forward plan.
Thank you for raising the issue that slipped by us.

Best regards,
Kathleen

On Fri, Oct 27, 2017 at 7:55 AM, Eliot Lear <[email-masked]> wrote:
> <[email-masked]> wrote:
>>
>> > <[email-masked]>
>> > wrote:
>> >>
>> >> Dear all,
>> >>
>> >> related

-- 

Best regards,
Kathleen

---

From: Zhen Cao <[email-masked]>
Date: Sat, 28 Oct 2017 17:00:59 +0800

Thanks Bernard for pointing out this, at least new to me. I check the
emu wg conclusion email, not formally stating that emu will be the
only place for eap-related discussion.

The emu list has been quite silent since the wg conclusion, less than
20 messages for three years.  There were occasionally some drafts
posted for comments, but not any follow-up responses.  This leaves an
impression that either the list members are not interested in new
topics or the emu list is not actually adequately subscribed (who has
the ground truth?).    I believe this is not only a motive for Mohit
and I to request a new mailing list, but may also confuse upcoming
people who seek for a place to have discussion.

Regards,
-Zhen

---

From: Bernard Aboba <[email-masked]>
Date: Sat, 28 Oct 2017 12:16:44 -0700

The IANA EAP page lists the policies for EAP code point allocations and points to RFC 3748 as the document relevant to method type allocations.

RFC 3748 Section 6 describes the EAP method type registration and review process, requiring method reviews to be posted to a designated list. Originally the EAP mailing list was designated, and then EMU was subsequently designated as the successor list. 

> On Oct 28, 2017, at 2:00 AM, Zhen Cao <[email-masked]> wrote:
>

---

From: Mohit Sethi <[email-masked]>
Date: Sun, 29 Oct 2017 19:46:26 +0200

Hi Bernard,

Thanks for pointing this out. Somehow this did not come up earlier when 
Zhen and I discussed with the Security ADs.

I am happy to keep the discussion on EMU. I think our goals are 
ultimately the same: we want the interested people to get engaged in the 
new work and make sure that there is enough review from experts.

We let the security ADs decide on what to do with REAP list. It might be 
better to shut it down now when there hasn't been much discussion. We 
would also encourage others who are not on EMU to join the list to stay 
updated.

--Mohit