Re: [Emu] EMU charter revision
Hi Hao, On Wed, April 30, 2008 9:34 am, Hao Zhou (hzhou) wrote: Dan wrote: The real thing holding up adoption of EAP-pwd as a work item is finishing work on the tunneled method. Which wouldn't be such a bad thing if we were further along towards that goal after Philly than we were after Vancouver and from the looks of it we won't be any further after Dublin than we were after Vancouver. :-( I don't think tunnel method is the real thing holding up the EAP-pw as a work item, so stop attacking the tunnel method or hurry it into some kind of sword fight. As others pointed out, EAP-pw might be quite useful for multiple WGs and should be bring to SAAG. But security review and IPR analysis need to be done before any WG is willing to take that work, I think. Let me quote the chairman of this group, Joe Salowey: 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. And what are the current charter items? GPSK which is getting one last edit before going off to IETF LC and... the tunneled method! So until we have made some progress on the tunneled method the charter cannot change to make EAP-pwd in scope of the group. Let me mention once more I'm not interested in sword fights. Let's call it a beauty contest. And it would be really nice if the contestants would finish their hair-dos and make-up and get into their evening gowns and out on the runway so the winner can get crowned. Dan. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] EMU charter revision,
[Joe] Jari had asked to keep this open to TLS. I think he was suggesting it could be done as a TLS extension and would not require tunneling. I agree that we do not want to extend EAP-TLS to do tunneling. How about: - Enable a TLS-based EAP method to support channel bindings. This item will not generate a new method, rather it will focus on supporting EAP channel bindings within the tunnel method. The possiblity of adding channel bindings to EAP-TLS through a TLS extension or other standard TLS mechanism may also be investigated. [BA] I think we only want one mechanism for support of channel bindings in TLS-based methods. So it's ok to investigate a TLS extension vs. other mechanisms for supporting channel bindings, but I'd suggest we only want to choose one path. So my suggestion would be to modify the text as follows: - Enable a TLS-based EAP method to support channel bindings. This item will not generate a new method, rather it will focus on adding support for EAP channel bindings. Potential mechanisms for addition of support for channel bindings will be investigated, including tunneling of channel binding parameters, or a TLS extension or other standard TLS mechanism. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
[Emu] EMU charter update
In order to get things moving we will send the following charter update to Pasi tomorrow. I will also let Pasi and Tim know there is interest in secure password methods and they should consider it as a topic for SAAG. 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 requirements relevant to EAP methods in RFC 3748, RFC 4017, RFC 4962 and EAP Keying: - 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 focus on supporting EAP channel bindings within the tunnel method. The possibility of adding channel bindings to EAP-TLS through a TLS extension or other standard TLS mechanism may also be investigated. - 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: DoneForm design team to work on strong shared secret mechanism DoneSubmit 2716bis I-D DoneSubmit first draft of shared secret mechanism I-D DoneForm password based mechanism design team DoneSubmit 2716bis draft to IESG for Proposed Standard May 2008Submit Strong Shared Secret Mechanism to IESG May 2008Submit Tunnel and Password Method requirements first Draft Sep 2008Submit EAP Channel Bindings First Draft Sep 2008Submit Tunnel Method first draft Oct 2008Submit TLS based method channel binding first draft Oct 2008Submit Password Method first draft Jan 2009Send EAP Channel Bindings to IESG Mar 2009Send Tunnel Method to IESG Apr 2009Send TLS based method channel binding to IESG Apr 2009Send Password based method to IESG ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] EMU charter revision,
I like Bernard's text better. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bernard Aboba Sent: Wednesday, April 30, 2008 7:54 PM To: Joseph Salowey (jsalowey); emu@ietf.org Subject: Re: [Emu] EMU charter revision, [Joe] Jari had asked to keep this open to TLS. I think he was suggesting it could be done as a TLS extension and would not require tunneling. I agree that we do not want to extend EAP-TLS to do tunneling. How about: - Enable a TLS-based EAP method to support channel bindings. This item will not generate a new method, rather it will focus on supporting EAP channel bindings within the tunnel method. The possiblity of adding channel bindings to EAP-TLS through a TLS extension or other standard TLS mechanism may also be investigated. [BA] I think we only want one mechanism for support of channel bindings in TLS-based methods. So it's ok to investigate a TLS extension vs. other mechanisms for supporting channel bindings, but I'd suggest we only want to choose one path. So my suggestion would be to modify the text as follows: - Enable a TLS-based EAP method to support channel bindings. This item will not generate a new method, rather it will focus on adding support for EAP channel bindings. Potential mechanisms for addition of support for channel bindings will be investigated, including tunneling of channel binding parameters, or a TLS extension or other standard TLS mechanism. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
