RE: [Emu] Re: Thoughts on Password-based EAP Methods
Bernard, By that is probably the place to start, I am assuming you mean insert all EMU changes into an EAP-TTLSv1. What happens with the existing EAP-TTLSv1? Are the authors okay with us taking over and calling something different than theirs EAP-TTLSv1? If yes, then I am for it. Not sure how we can get away with crypto-binding IPR if it is a blanker IPR, I have not read the patent myself. R, Madjid -Original Message- From: Bernard Aboba [mailto:[EMAIL PROTECTED] Sent: Saturday, April 14, 2007 12:54 PM To: [EMAIL PROTECTED]; emu@ietf.org Subject: RE: [Emu] Re: Thoughts on Password-based EAP Methods The emu working agreed on the fact that a secure channel is needed Item1. - a) Is there a consensus for TTLS (what version ?) - b) Is this possible to push TTLS as an RFC (from an IT point of view) Item2 -c) Do we need a new password based method ? I agree with Bernard point of view. Many methods already exist. My personal feeling is a=yes, b=yes, c=no I agree with this. With respect to a) there is realy only one deployed version of EAP-TTLS, namely EAP-TTLSv0. EAP-TTLSv1 has not been implemented. So that is probably the place to start. With respect to b), a fothcoming version of the EAP-TTLSv0 specification will be submitted for publication as an RFC. This will address questions from implementers and address the need for a stable reference from WiMAX Forum, OMA, TNC and other organizations that are incorporating EAP-TTLSv0 into their standards. With respect to c), one needs to take several factors into account, such as the certification/testing situation, availability of reference implementations and IPR declarations. EAP-TTLSv0 is currently being tested for interoperability by WFA so that a certification program is already in place. As far as I could tell, there is only one IPR declaration relating to EAP-TTLS, and that relates to EAP-TTLSv1, rather than EAP-TTLSv0: https://datatracker.ietf.org/public/ipr_detail_show.cgi?ipr_id=594 Compare this with the IPR Declarations relating to EAP FAST: http://www.ietf.org/ietf/IPR/cisco-ipr-draft-cam-winget-eap-fast.txt http://www.ietf.org/ietf/IPR/cisco-ipr-draft-cam-winget-eap-fast-provisionin g-03.txt http://www.ietf.org/ietf/IPR/cisco-ipr-draft-salowey-tls-ticket.txt https://datatracker.ietf.org/public/ipr_detail_show.cgi?ipr_id=595 http://www1.ietf.org/ietf/IPR/microsoft-ipr-draft-cam-winget-eap-fast.txt ___ 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] Re: Thoughts on Password-based EAP Methods
Hi Steve, Sorry for jumping late. Internally within the design team and not having followed this thread, I suggested that we could follow the TTLS path in a way that it meets our requirements. The fact that Paul has agreed to give up control of the draft to IETF is really good news, however, I am a bit confused as how the process you suggested will happen, so let me understand this: We publish the current TTLSv0 as an RFC, and we also publish TTLSvX based on the changes EMU does as a separate RFC in a way that it does not deprecate the first one? (sort of like IKEv1 and IKEv2 scenario?) As good as that sounds to me, the not so rhetorical question would be: wouldn't the two versions still get two different method types? BTW, I am hearing that Paul has promised to add EMSK generation to TTLSv0, so may be TTLSv0 is not quite there yet:)? R, Madjid -Original Message- From: Stephen Hanna [mailto:[EMAIL PROTECTED] Sent: Monday, April 02, 2007 3:00 PM To: [EMAIL PROTECTED] Subject: [Emu] Re: Thoughts on Password-based EAP Methods Sorry it took me a few days to respond to this thread. I agree with Bernard that there's no benefit in creating Yet Another Password-Based EAP Method (YAPBEM). There's no point in reinventing the wheel for a fourth time and it's not the IETF way. We're not researchers. We're practical engineers who respect running code and rough consensus. So, yes, we should have a bias toward existing, well-tested and well-understood protocols. In a security group, it's especially important to avoid the temptation to reinvent the wheel. We should focus our efforts on one secure tunneled EAP method and make that one secure. We should consider existing methods and only invent something new if we need to. I have spoken to Paul Funk, the primary author of the EAP-TTLSv0 spec. He is glad to proceed as Bernard suggested: 1. Publish an updated EAP-TTLSv0 spec that documents current practice (as Informational or Experimental) 2. Give up change control to the IETF so that the EMU WG can make any necessary changes or additions to EAP-TTLS I'm also glad to assist with this effort, since Paul is pretty busy these days. Thanks, Steve -Original Message- From: Bernard Aboba [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 27, 2007 8:07 AM To: [EMAIL PROTECTED] Subject: [Emu] Thoughts on Password-based EAP Methods After listening to the IETF 68 presentation on a password-based EAP method, I would like to voice some concerns. Today we already have an over abundance of such methods. These include PEAPv0, PEAPv1, EAP-TTLSv0, EAP-TTLSv1, and EAP-FAST. In my discussions with customers, I invariably hear complaints about this explosion, and about various interoperability and compatibility problems that it causes. Simply put, customers do not want yet another password-based EAP method; they want a single method that is widely implemented and interoperable. I am concerned that by defining yet another password-based authentication mechanism, EMU WG will be making this problem worse, not better. Creating yet another mechanism which differs little from the existing ones also seems to have very little chance of being implemented. There is a better alternative that EMU WG should consider. This is to choose an existing method for inclusion on the IETF Standards Track, rather than creating a new one. In order to maintain backward compatibility, this would require that the owners give up change control to the IETF. I would suggest that the best candidate for this would be EAP-TTLSv0, since it is very widely implemented, and has an existing certification program in WFA. Also, EAP-TTLSv0 had previously been on the Standards Track in the PPPEXT WG, before work on EAP methods was removed from the PPPEXT WG charter and the EAP WG was formed. In terms of steps to be taken, this would require the following actions: a. Review and publication of the existing EAP-TTLSv0 specification as an RFC. The goal here would be to document EAP-TTLSv0 as it exists today. b. Agreement by the authors to give up change control to the IETF. c. EMU WG efforts to publish an EAP-TTLSv0 bis document, specifying additional capabilities (such as Channel Bindings). ___ Emu mailing list Emu at ietf.org https://www1.ietf.org/mailman/listinfo/emu ___ Emu mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/emu ___ Emu mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/emu
RE: [Emu] Re: Thoughts on Password-based EAP Methods
I'm glad to hear from Steve here that there is support for publishing TTLSv0. I would like to see that happen regardless of whether it is done as an EMU work item or not. My understanding is that a new version of the TTLSv0 document will be forthcoming which will fill in some of the details that were previously missing, such as the EMSK generation formula, and the definitions of the Session-Id, Peer-Id and Server-Id. A new version of the PEAPv0 specification will also be forthcoming. ___ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu
RE: [Emu] Re: Thoughts on Password-based EAP Methods
Bernard Aboba mailto:[EMAIL PROTECTED] allegedly scribbled on Monday, April 02, 2007 3:42 PM: Part of the problem with EAP methods is that people should have started to standardize them within the IETF several years ago. Unfortunately, there was no interest by some of the EAP method authors nor from the EAP WG chairs to allow that. In fact, the IETF was on track to standardize EAP methods back as recently as 2001, within the PPPEXT WG. It was as part of that program that EAP-TLS was first published as an Experimental RFC, and EAP-TTLSv0 was put on the standards track. The decision to remove standards track EAP methods from the PPPEXT WG charter was made by the IESG, not by the authors of EAP methods, or the EAP WG chairs. As I recall, there was considerable opposition to that decision at the time. I was in favor of it at the time, as I recall; however, I imagined that the project would move to the EAP WG, not drop into a black hole. ___ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu
Re: [Emu] Re: Thoughts on Password-based EAP Methods
I am not surprised to hear that EAP method authors agree that no further EAP methods should be developed. Part of the problem with EAP methods is that people should have started to standardize them within the IETF several years ago. Unfortunately, there was no interest by some of the EAP method authors nor from the EAP WG chairs to allow that. But if some (unknown) customers say that they do not want more EAP methods then Sam will have to change his mind. At the last IETF meeting he ruled out the usage of TTLS, for example. I hope that the some people can change their mind with regard to the applicability statement of EAP usage in TLS so quickly as well ~snip~ ___ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu
Re: [Emu] Re: Thoughts on Password-based EAP Methods
Does it need to recharter? Best regards, Badra On 3/28/07, Bernard Aboba [EMAIL PROTECTED] wrote: The latest EAP-TTLSv0 draft is available here: http://www.watersprings.org/pub/id/draft-funk-eap-ttls-v0-00.txt In terms of publication interest, back in the fall Jari Arkko had announced a program to encourage widely implemented EAP methods to publish their specifications as RFCs. As I recall, there was interest to publish EAP-FAST (in the RFC Editor queue), PEAPv0 (documentation currently being revised for submission as an Internet Draft). I don't know the current status of the EAP-TTLSv0 publication effort (e.g. whether publication has been requested or not). Steve Hanna might know. In terms of history, EAP-TTLSv0 was accepted as a Standards Track work item of the PPPEXT WG prior to the formation of the EAP WG. It has been implemented on a wide variety of platforms including open source versions for Windows (http://www.securew2.com/) and Linux (http://open1x.sourceforge.net/). Interoperability of EAP-TTLSv0 implementations is currently certified by the WFA. In terms of features that would be needed to meet EMU WG requirements, I think we are probably talking about crypto-binding and channel binding. It is possible that there may be other features needed for some scenarios ( e.g. mutual certificate authentication for a device/machine plus user auth for scenarios currently discussed within WiMAX Forum and 3GPP2). ___ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu
