Subject: [Emu] EMU charter revision

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Thu, 10 Apr 2008 19:26:46 -0700

Below is a revision to the EMU charter that is intended to reflect the
discussions in the Philadelphia meeting.  Please respond to the list if
you approve of the charter or if you have any comments on the charter.
I would like to have responses by 4/24.

Thanks,

Joe

Description of Working Group:
The Extensible Authentication Protocol (EAP) [RFC 3748] is a network
access authentication framework used in the PPP, 802.11, 802.16, VPN,
PANA, and in some functions in 3G networks. EAP itself is a simple
protocol and actual authentication happens in EAP methods.

Over 40 different EAP methods exist. Most of these methods are
proprietary methods, but some are documented in informational RFCs. In
the past the lack of documented, open specifications has been a
deployment and interoperability problem. There are currently only two
EAP methods in the standards track that implement features such as key
derivation that are required for many modern applications.
Authentication types and credentials continue to evolve as do
requirements for EAP methods. 

This group is chartered to work on the following types of mechanisms to
meet RFC 3748, RFC 4017, RFC 4962 and EAP Keying requirements:

- An update to RFC 2716 to bring EAP-TLS into standards track, clarify
specification, interoperability, and implementation issues gathered over
the years, and update the document to meet the requirements of RFC 3748,
RFC 4017, and EAP keying framework documents. Backwards compatibility
with RFC 2716 is a requirement.

- A mechanism based on strong shared secrets. This mechanism should
strive to be simple and compact for implementation in resource
constrained environments.

- A document that defines EAP channel bindings and provides guidance for
establishing EAP channel bindings within EAP methods.  

- A mechanism to support extensible communication within a TLS protected
tunnel. This mechanism must support channel bindings in order to meet
RFC 4962 requirements. This mechanism will support meeting the
requirements of an enhanced TLS mechanism, a password based
authentication mechanism, and additional inner authentication
mechanisms.  

- Enable a TLS-based EAP method to support channel bindings. This item
will not generate a new method, rather it will extend EAP-TLS and/or the
above tunnel method.  

- A mechanism that makes use of existing password databases such as AAA
databases.  This item will be based on the above tunnel method.

Goals and Milestones:
Done	  	Form design team to work on strong shared secret
mechanism
Done	  	Submit 2716bis I-D
Done	  	Submit first draft of shared secret mechanism I-D
Done	  	Form password based mechanism design team
Done		Submit 2716bis draft to IESG for Proposed Standard
Apr 2008	Submit Strong Shared Secret Mechanism to IESG
May 2008 	Submit Tunnel and Password Method requirements first
Draft
Sep 2008	Submit EAP Channel Bindings First Draft
Sep 2008 	Submit Tunnel Method first draft
Oct 2008	Submit TLS based method channel binding first draft
Oct 2008 	Submit Password Method first draft
Jan 2009	Send EAP Channel Bindings to IESG
Mar 2009	Send Tunnel Method to IESG
Apr 2009	Send TLS based method channel binding to IESG
Apr 2009	Send Password based method to IESG
_______________________________________________
Emu mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/emu

---

From: "Dan Harkins" <[email-masked]>
Date: Fri, 11 Apr 2008 10:38:28 -0700 (PDT)

Hi Joe,

  Thank you for giving me the opportunity to object, once again, to
the last sentence in the last item in the charter. If you were to
run the following sed filter on the charter I would approve:

  s/This item will be based on the above tunnel method.//

  What is the process here? This looks the same as the charter revision
you made a consensus call on back in January. I was the only one to opine
before your cutoff last time and my comment was the same as above. Now
we're doing this again.

  Dan.

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Fri, 11 Apr 2008 14:49:26 -0700

> -----Original Message-----
> From: Dan Harkins [mailto:[email-masked]] 
> Sent: Friday, April 11, 2008 10:38 AM
> To: Joseph Salowey (jsalowey)
> Cc: [email-masked]
> Subject: Re: [Emu] EMU charter revision
> 
> 
>   Hi Joe,
> 
>   Thank you for giving me the opportunity to object, once 
> again, to the last sentence in the last item in the charter. 
> If you were to run the following sed filter on the charter I 
> would approve:
> 

[Joe] I do not think that removing this line would achieve the goal you
wish.  With this line removed EAP-PWD is still out of scope of the
charter as it does not meet the requirements of supporting legacy
password databases.  The message from the ADs in the last meeting was
pretty clear in that EAP-PWD style mechanisms is not something for the
group to take on right now.  This does not mean that we cannot take on
an EAP-PWD style mechanism once we have made progress on the current
charter items.  

>   What is the process here? This looks the same as the 
> charter revision you made a consensus call on back in 
> January. I was the only one to opine before your cutoff last 
> time and my comment was the same as above. Now we're doing this again.
> 
[Joe] There have been several revisions posted to the list and feedback
from several working group members that have been worked into the new
proposal along with input from the discussion in the last meeting.  If
enough people respond positively, such that we have rough consensus,
then we can move forward. 

> > discussions in the Philadelphia meeting.  Please respond to 
> the list 
> > if you approve of the charter or if you have any comments 
> on the charter.
> >f
> > This group is chartered to work on the following types of 
> mechanisms 
> > to meet RFC 3748, RFC 4017, RFC 4962 and EAP Keying requirements:
> >
> > specification, interoperability, and implementation issues gathered 
> > over the years, and update the document to meet the requirements of 
> > RFC 3748, RFC 4017, and EAP keying framework documents. Backwards 
> > compatibility with RFC 2716 is a requirement.
> >
> > - A document that defines EAP channel bindings and provides 
> guidance 
> > for establishing EAP channel bindings within EAP methods.
> >
> > - A mechanism to support extensible communication within a TLS 
> > protected tunnel. This mechanism must support channel bindings in 
> > order to meet RFC 4962 requirements. This mechanism will support 
> > meeting the requirements of an enhanced TLS mechanism, a password 
> > based authentication mechanism, and additional inner authentication 
> > mechanisms.
> >
> > will not generate a new method, rather it will extend 
> EAP-TLS and/or 
> > the above tunnel method.
> >
> > - A mechanism that makes use of existing password databases such as 
> > AAA databases.  This item will be based on the above tunnel method.
> >
> > Goals and Milestones:

---

From: "Dan Harkins" <[email-masked]>
Date: Fri, 25 Apr 2008 17:42:48 -0700 (PDT)

Hi Joe,

  Once again, a call for comments and I'm the only one to comment.

  Whether removing that line achieves "my goals" or not I still think
it should be removed. And that really seems to be the only comment
on the charter you get when you ask.

  regards,

  Dan.

---

From: "Stephen Hanna" <[email-masked]>
Date: Sun, 27 Apr 2008 21:10:01 -0400

I apologize for my tardy response. I have been on vacation.

I agree with and support the proposed charter below. As for
Dan's suggestion that we not require the password based
method to be based on the tunnel method, the WG already
went through a long discussion and consensus check last
fall on this matter. There was clear consensus that we
should NOT work on a new password based method designed
to function without the tunnel method. One person's
opinion to the contrary does not negate that consensus.
I think that the reason we are not seeing much email on
this charter is that the issues and language have been
hashed through many times.

Thanks,

Steve

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Dan Harkins
Sent: Friday, April 25, 2008 5:43 PM
To: Joseph Salowey (jsalowey)
Cc: [email-masked]
Subject: Re: [Emu] EMU charter revision

  Hi Joe,

  regards,

  Dan.

---

From: "Dan Harkins" <[email-masked]>
Date: Sun, 27 Apr 2008 23:11:53 -0700 (PDT)

That's true. One person's opinion does not negate consensus,
even if that one person is the only one who is able to opine
in the alloted time given for opinions (twice now). But so what?
If someone asks then I'll give an honest opinion, especially
since no one else seems to be able to.

  But maybe you're right. Any additional work taken on by this
group would distract from the fantastic progress we've made in the
past 9 months on the tunneled method. It would be a shame to lose
all that. Yes, let's just focus on the snail race....

  Dan.

---

From: "Gene Chang (genchang)" <[email-masked]>
Date: Mon, 28 Apr 2008 06:35:19 -0400

Dan,
I am not sure I am able to clearly understand the end result you seek.
It seems there is a clear consensus for a tunneled method. Are you
pushing for the addition of a tunneled method? 

Ok... I am easily baited. What would you like to see to achieve more
than a snail race? I am assuming we both believe the term "snail race"
is a pejorative. Thus I ask you, how do we do better?

I clearly hear your comment that there have been a paucity of comments,
if nothing else, simply to affirm we are on track. I agree with the
proposed charter. I am open to a discussion to add a non-tunneled method
if there is sufficient demand. A non-tunneled method does not seem to
promise enough features for the use cases that interest me.

Gene

------------------------------------------------------------------------
----
Eugene Chang (genchang)
Cisco Systems
Office:   603-559-2978
Mobile:  781-799-0233
Skype:  gene02421

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
Dan
> Harkins
> Sent: Monday, April 28, 2008 2:12 AM
> To: Stephen Hanna
> Cc: [email-masked]

---

From: "Dan Harkins" <[email-masked]>
Date: Mon, 28 Apr 2008 09:04:45 -0700 (PDT)

Hi Gene,

  I'm not pushing a tunneled method. We have enough of those and their
differences are not so great.

  Yes, I was using "snail race" as a pejorative. As I said at the last
IETF we should have a cage-match-cum-beauty-contest between TTLS and
FAST, turn the last RFC text of the winner into a -00 EMU draft, add the
channel bindings stuff that was discussed back in Vancouver and then
publish. Apparently this working group can work on nothing except
a tunneled method. And that work is being done at a snail's pace.

  I'm glad to hear that you're open to a discussion of adding a non-
tunneled method "if there is sufficient demand", but you see we have this
long-standing consensus and the mere mention of anything that remotely
sounds like a non-tunneled method gets stifled with "consensus!" So
apparently we're not allowed to have that discussion. At least until we
finish work on a tunneled method.

  Dan.

---

From: "Gene Chang (genchang)" <[email-masked]>
Date: Mon, 28 Apr 2008 14:26:47 -0400

Dan,

I think we can all appreciate the entertainment value of bringing a
reality show to the IETF. Imagine replacing the IETF social with an
arena full of hyped up Internet engineers enjoying a night fellowship
with beer and trash talk.

Unfortunately, all we are doing is dressing up a down select with two
4-5 year old protocols that do not completely meet the requirements
document that is being assembled. We aren't doing the industry a favor
freezing the protocol choice to technology ca. 2004. 

If you are in such a rush, why not simply declare victory and have a
tie. That enshrines the status quo. Picking one over the other won't
change the status quo and thus won't change the deployment preference
already established.

Better for the industry would be a foot race where the candidate
protocol that meets the requirements document and gains 10 million
devices protected would win the standards title. This would advance the
technology to cover the missing requirements and significantly grow
adoption.

Let's focus our efforts on moving the technology forward instead
searching for an entertaining down select.

I really don't see your sense of urgency. I don't see an adoption window
that we are going to miss with the current effort. Yet, I can be really
excited pushing to meet the needs of a critical adoption window.

I would like to see things progress faster but not at the expense of a
weak technical outcome.

Gene

 
> Sent: Monday, April 28, 2008 12:05 PM
> To: Gene Chang (genchang)
> Cc: Dan Harkins; Stephen Hanna; [email-masked]
> Subject: RE: [Emu] EMU charter revision
> 
> 
>   Hi Gene,
> 
> >> > From: [email-masked] [mailto:[email-masked]] On
Behalf
> > Of
> >> >> [Joe] I do not think that removing this line would achieve the
goal
> >> > you
> >> >> password databases.  The message from the ADs in the last
meeting
> > was
> >> >> pretty clear in that EAP-PWD style mechanisms is not something
for
> > the
> >> >> group to take on right now.  This does not mean that we cannot
take
> > on
> >> >> from several working group members that have been worked into
the
> > new
> >> >> proposal along with input from the discussion in the last
meeting.
> > If
> >> >>> > over the years, and update the document to meet the
requirements
> > of
> >> >>> > protected tunnel. This mechanism must support channel
bindings
> > in
> >> >>> > - A mechanism that makes use of existing password databases
such
> > as

---

From: "Dan Harkins" <[email-masked]>
Date: Mon, 28 Apr 2008 12:22:05 -0700 (PDT)

Gene,

  I don't think anyone would find an EMU reality show entertaining. The
only comic relief would be one crazy guy who, once every 4 months, pokes
his head in the window and says "I do not approve" to people sitting
around watching paint dry.

  You are restating Stephen's comment from Philly that I'm more
interested in the cage match than in the coronation of the winner.
That is not true but it is also irrelevant. I actually don't care
who wins or how much blood is let, I just want it to be over.

  It would really be an abuse of process to hold up all other work while
each side crunches numbers and pays analysts to run surveys so that
someone can claim to have reached an arbitrary 10M mark. And it would not
be a service to anybody.

  So what we have is argument over the wording of "requirements" so
that they will subtly favor one side over the other. Then we create a
"requirements" document that captures all the carefully constructed
verbage. And while that's getting advanced we then argue over which
candidate best matches the customized wording of the "requirements". And
then we finally get down to the work of actually changing one of the
specifications to add channel binding. And this must all be done
serially. Sigh.

  Both FAST and TTLS are equally amenable to modification and their
differences are not so great or we'd have had a clear "winner" already.
No matter which one gets selected we will not end up with a weak solution.

  You don't see my sense of urgency because what you view as interesting
work is not being held up.

  Dan.

---

From: "Gene Chang (genchang)" <[email-masked]>
Date: Mon, 28 Apr 2008 15:44:20 -0400

Dan,
Great, we are not back to lets get those requirements done. It's the
gate to the next steps.

Gene

 

> Sent: Monday, April 28, 2008 3:22 PM
> >> FAST, turn the last RFC text of the winner into a -00 EMU draft,
add
> >> tunneled method "if there is sufficient demand", but you see we
have
> > this
> >> apparently we're not allowed to have that discussion. At least
until
> > we
> >> > if there is sufficient demand. A non-tunneled method does not
seem
> > to
Behalf
> >> >> >   Whether removing that line achieves "my goals" or not I
still
> >> > think
> >> >> >> wish.  With this line removed EAP-PWD is still out of scope
of
> >> >> >>> time and my comment was the same as above. Now we're doing
this
> >> >> > again.
> >> >> >>>
> >> >> >> [Joe] There have been several revisions posted to the list
and
> >> >> > feedback
> >> >> >>> > PANA, and in some functions in 3G networks. EAP itself is
a
> >> > simple
> >> >> >>> > the past the lack of documented, open specifications has
been
> > a
> >> >> >>> > - A mechanism based on strong shared secrets. This
mechanism
> >> > should
> >> >> >>> > AAA databases.  This item will be based on the above
tunnel
> >> > method.

---

From: "Gene Chang (genchang)" <[email-masked]>
Date: Mon, 28 Apr 2008 15:47:15 -0400

Oops... a key typo in the earlier version...

Dan,
Great, we are now back to let's get those requirements done. It's the
gate to the next steps.

Gene

 

Gene
> Chang (genchang)
> Sent: Monday, April 28, 2008 3:44 PM
> To: Dan Harkins
> Cc: [email-masked]
> > someone can claim to have reached an arbitrary 10M mark. And it
would
> not
> > > devices protected would win the standards title. This would
advance
> > > I would like to see things progress faster but not at the expense
of
> > >> > I am not sure I am able to clearly understand the end result
you
> > > seek.
> > >> > than a snail race? I am assuming we both believe the term
"snail
> > > race"
> > >> > proposed charter. I am open to a discussion to add a
non-tunneled
> > > method
> > >> >> >> an EAP-PWD style mechanism once we have made progress on
the
> > >> > current
> > >> >> >>> > Below is a revision to the EMU charter that is intended
to
> > >> >> >>> reflect the
> > >> >> >>> > The Extensible Authentication Protocol (EAP) [RFC 3748]
is
> > >> >> >>> a network
> > >> >> >>> > Over 40 different EAP methods exist. Most of these
methods
> > > are
> > >> >> >>> > EAP methods in the standards track that implement
features
> > >> >> >>> such as key
> > >> >> >>> > Authentication types and credentials continue to evolve
as
> do
> > >> >> >>> > specification, interoperability, and implementation
issues
> > >> > gathered
> > >> >> >>> > - A mechanism to support extensible communication within
a
> > > TLS
> > >> >> >>> > May 2008 	Submit Tunnel and Password Method
requirements
> > >> > first
> > >> >> >>> > Oct 2008	Submit TLS based method channel binding
first
> > >> > draft