Subject: [Emu] Moving forward with the EMU password method

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Wed, 3 Oct 2007 11:02:48 -0700

At the IETF in Chicago we had a hum as to the direction we should take
with the password based method.  I would like to clarify the choices and
determine working group consensus on the list.  The two directions are
given below please express you preference by 10/25.

Option 1 - Password based method - this option restricts the work item
to what is currently in the charter.  The resulting method would have a
new method ID and selecting this method would mean selecting a password
based exchange that meets the requirements we already set forth.  The
method may use an existing method as its base.  

Option 2 - Tunneling method - this option requires clarifying the
charter to work on a tunneling method which would then be used to meet
the password method requirements.  This would include making sure we
have a valid set of requirements to work with. The working group may
select an existing method as its base and have backwards compatibility
as a goal, however whether the method uses the same method ID and any
modifications to the method will be determined by working group and IETF
consensus.  

Thanks,

Joe

_______________________________________________
Emu mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/emu

---

From: "Stephen Hanna" <[email-masked]>
Date: Wed, 3 Oct 2007 15:54:55 -0400

I favor option 2.

There are tunneling EAP methods already in widespread use that can meet
the requirements with a few extensions (e.g. EAP-TTLSv0 with the
extensions
documented in draft-hanna-eap-ttls-agility-00.txt). Customers are
understandably
reluctant to deploy new EAP methods so it's much more likely that they
will
use the results of our work if we use an existing EAP method instead of
defining a new method.

Thanks,

Steve

-----Original Message-----
From: Joseph Salowey (jsalowey) [mailto:[email-masked]] 
Sent: Wednesday, October 03, 2007 11:03 AM
To: [email-masked]
Subject: [Emu] Moving forward with the EMU password method

Thanks,

Joe

---

From: "Gene Chang (genchang)" <[email-masked]>
Date: Wed, 3 Oct 2007 16:26:54 -0400

I also favor option 2.
There are already several tunneling EAP methods in widespread use.
There is already concern that there are too many alternatives. We should
avoid introducing a new EAP method. It would be better to (a) use an
existing EAP method, (b) merge some of the existing methods, or (c) if
necessary, perfect an existing method to meet our needs.

Gene

------------------------------------------------------------------------
----
Eugene Chang (genchang)
Office:   603-559-2978
Mobile:  781-799-0233

> From: Stephen Hanna [mailto:[email-masked]]
> Sent: Wednesday, October 03, 2007 3:55 PM
> To: Joseph Salowey (jsalowey); [email-masked]
> Subject: RE: [Emu] Moving forward with the EMU password method
> 
> I favor option 2.
>

---

From: "Ray Bell" <[email-masked]>
Date: Wed, 3 Oct 2007 15:26:16 -0700

I favor option 2 as well

Ray

-----Original Message-----
From: Stephen Hanna [mailto:[email-masked]] 
Sent: Wednesday, October 03, 2007 12:55 PM
To: Joseph Salowey (jsalowey); [email-masked]
Subject: RE: [Emu] Moving forward with the EMU password method

I favor option 2.

Thanks,

Steve

-----Original Message-----
From: Joseph Salowey (jsalowey) [mailto:[email-masked]] 
Sent: Wednesday, October 03, 2007 11:03 AM
To: [email-masked]
Subject: [Emu] Moving forward with the EMU password method

Thanks,

Joe

---

From: Ryan Hurst <[email-masked]>
Date: Wed, 3 Oct 2007 16:15:58 -0700

I also favor #2, I like Steve have found customers reluctant to deploy
new methods if we can satisfy the goals with a method that's broadly
deployed (with some tweaks) I think we will have more success than if we
define a new one.

-----Original Message-----
From: Ray Bell [mailto:[email-masked]] 
Sent: Wednesday, October 03, 2007 3:26 PM
To: 'Stephen Hanna'; 'Joseph Salowey (jsalowey)'; [email-masked]
Subject: RE: [Emu] Moving forward with the EMU password method

I favor option 2 as well

Ray

-----Original Message-----
From: Stephen Hanna [mailto:[email-masked]] 
Sent: Wednesday, October 03, 2007 12:55 PM
To: Joseph Salowey (jsalowey); [email-masked]
Subject: RE: [Emu] Moving forward with the EMU password method

I favor option 2.

Thanks,

Steve

-----Original Message-----
From: Joseph Salowey (jsalowey) [mailto:[email-masked]] 
Sent: Wednesday, October 03, 2007 11:03 AM
To: [email-masked]
Subject: [Emu] Moving forward with the EMU password method

Thanks,

Joe

---

From: "Hao Zhou (hzhou)" <[email-masked]>
Date: Wed, 3 Oct 2007 22:56:24 -0400

Me too. I like to see a standard based tunneling method, that supports
crypto-binding, crypto-agility, internationalization, as well as a
standard framework for extension within the tunnel. 

> From: Ryan Hurst [mailto:[email-masked]] 
> Sent: Wednesday, October 03, 2007 7:16 PM
> To: Ray Bell; Stephen Hanna; Joseph Salowey (jsalowey); [email-masked]
> I also favor #2, I like Steve have found customers reluctant 
> to deploy new methods if we can satisfy the goals with a 
> method that's broadly deployed (with some tweaks) I think we 
> will have more success than if we define a new one.
> 
> There are tunneling EAP methods already in widespread use 
> that can meet the requirements with a few extensions (e.g. 
> EAP-TTLSv0 with the extensions documented in 
> draft-hanna-eap-ttls-agility-00.txt). Customers are 
> understandably reluctant to deploy new EAP methods so it's 
> much more likely that they will use the results of our work 
> if we use an existing EAP method instead of defining a new method.
> 
> Thanks,
> 
> Steve
> 
> At the IETF in Chicago we had a hum as to the direction we 
> should take with the password based method.  I would like to 
> clarify the choices and determine working group consensus on 
> the list.  The two directions are given below please express 
> you preference by 10/25.
> 
> Option 1 - Password based method - this option restricts the 
> work item to what is currently in the charter.  The resulting 
> method would have a new method ID and selecting this method 
> would mean selecting a password based exchange that meets the 
> requirements we already set forth.  The method may use an 
> existing method as its base.  
> 
> Option 2 - Tunneling method - this option requires clarifying 
> the charter to work on a tunneling method which would then be 
> used to meet the password method requirements.  This would 
> include making sure we have a valid set of requirements to 
> work with. The working group may select an existing method as 
> its base and have backwards compatibility as a goal, however 
> whether the method uses the same method ID and any 
> modifications to the method will be determined by working 
> group and IETF consensus.  
> 
> Thanks,
> 
> Joe
> 
>

---

From: Alan DeKok <[email-masked]>
Date: Thu, 04 Oct 2007 09:19:25 +0200

> I favor option 2.

  As do I.

  Alan DeKok.

---

From: "Nancy Winget (ncamwing)" <[email-masked]>
Date: Thu, 4 Oct 2007 08:28:25 -0700

I also favor option 2.  There are several tunneled EAP methods that can
serve as a baseline such as TTLS, EAP-FAST and PEAP.  Though similar,
there are differences between them that may be significant and could
preclude them from consideration based on the requirements.  So, it is
important that we first agree on the set of requirements before deciding
on how to proceed on standardization of such a method.

	Nancy.

-----Original Message-----
From: Stephen Hanna [mailto:[email-masked]] 
Sent: Wednesday, October 03, 2007 12:55 PM
To: Joseph Salowey (jsalowey); [email-masked]
Subject: RE: [Emu] Moving forward with the EMU password method

I favor option 2.

There are tunneling EAP methods already in widespread use that can meet
the requirements with a few extensions (e.g. EAP-TTLSv0 with the
extensions documented in draft-hanna-eap-ttls-agility-00.txt). Customers
are understandably reluctant to deploy new EAP methods so it's much more
likely that they will use the results of our work if we use an existing
EAP method instead of defining a new method.

Thanks,

Steve

-----Original Message-----
From: Joseph Salowey (jsalowey) [mailto:[email-masked]]
Sent: Wednesday, October 03, 2007 11:03 AM
To: [email-masked]
Subject: [Emu] Moving forward with the EMU password method

Thanks,

Joe

---

From: Pascal Urien <[email-masked]>
Date: Wed, 24 Oct 2007 15:51:30 +0200

Hi Joe,

   I support method 2, with the following remarks

   Under VISTA i have found three tunnels methods already supported, 
PEAP, EAP-FAST, TTLS.
  PEAP and TTLS are drafts with multiple versions. EAP-FAST is an RFC

   All these methods use two phases, phase 1 and phase 2

   Phase 1 coding (e.g EAP format) looks similar, i did not have 
sufficient time to check if they are exactly
   equivalent (does somebody know that ?)

   Phase 2 coding is different in every cases.

   Could it be possible to think about a method with a common phase 1 
coding and multiple phase 2 coding ?

Cheers

Pascal

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Thu, 25 Oct 2007 16:17:14 -0700

> From: Pascal Urien [mailto:[email-masked]] 
> Sent: Wednesday, October 24, 2007 6:52 AM
> Subject: Re: [Emu] Moving forward with the EMU password method
> 
> Hi Joe,
> 
>    Under VISTA i have found three tunnels methods already 
> supported, PEAP, EAP-FAST, TTLS.
>    Phase 1 coding (e.g EAP format) looks similar, i did not 
> have sufficient time to check if they are exactly
>    Could it be possible to think about a method with a common 
> phase 1 coding and multiple phase 2 coding ?
> 
[Joe] While this would be possible, the working group would probably
have to select a particular phase 2 coding to be mandatory to implement
for interoperability.  

> should take 
> >with the password based method.  I would like to clarify the choices 
> >and determine working group consensus on the list.  The two 
> directions 
> >are given below please express you preference by 10/25.
> >
> work item 
> >modifications to the method will be determined by working group and 
> >IETF consensus.
> >
> >Thanks,
> >
> >Joe
> >
> >