RE: [Emu] Moving forward with the EMU password method
-Original Message- From: Pascal Urien [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 24, 2007 6:52 AM To: Joseph Salowey (jsalowey); emu@ietf.org Subject: Re: [Emu] Moving forward with the EMU password method 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 ? [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. Cheers Pascal At 20:02 03/10/2007, Joseph Salowey (jsalowey) wrote: 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 Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu ___ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu
Re: [Emu] Moving forward with the EMU password method
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 At 20:02 03/10/2007, Joseph Salowey (jsalowey) wrote: 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 Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu ___ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu
Re: [Emu] Moving forward with the EMU password method
Stephen Hanna wrote: I favor option 2. As do I. Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu
RE: [Emu] Moving forward with the EMU password method
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 -Original Message- From: Stephen Hanna [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 03, 2007 3:55 PM To: Joseph Salowey (jsalowey); emu@ietf.org 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 PROTECTED] Sent: Wednesday, October 03, 2007 11:03 AM To: emu@ietf.org Subject: [Emu] Moving forward with the EMU password method 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 Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu ___ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu ___ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu
RE: [Emu] Moving forward with the EMU password method
I favor option 2 as well Ray -Original Message- From: Stephen Hanna [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 03, 2007 12:55 PM To: Joseph Salowey (jsalowey); emu@ietf.org 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 PROTECTED] Sent: Wednesday, October 03, 2007 11:03 AM To: emu@ietf.org Subject: [Emu] Moving forward with the EMU password method 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 Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu ___ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu ___ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu
RE: [Emu] Moving forward with the EMU password method
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. -Original Message- From: Ryan Hurst [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 03, 2007 7:16 PM To: Ray Bell; Stephen Hanna; Joseph Salowey (jsalowey); emu@ietf.org Subject: RE: [Emu] Moving forward with the EMU password method 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 PROTECTED] Sent: Wednesday, October 03, 2007 3:26 PM To: 'Stephen Hanna'; 'Joseph Salowey (jsalowey)'; emu@ietf.org Subject: RE: [Emu] Moving forward with the EMU password method I favor option 2 as well Ray -Original Message- From: Stephen Hanna [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 03, 2007 12:55 PM To: Joseph Salowey (jsalowey); emu@ietf.org 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 PROTECTED] Sent: Wednesday, October 03, 2007 11:03 AM To: emu@ietf.org Subject: [Emu] Moving forward with the EMU password method 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 Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu ___ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu ___ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu ___ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu ___ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu
