Hi Dan, The EMU group was chartered to work on a password based method to work with existing password databases. During the last year we have had discussions in meetings and on the list to reach working group consensus on the way to meet this task. The consensus is to use a tunnel method to meet this task and is the reason why we are adding this to the charter. Removing the sentence that indicates use of a tunnel method from the charter would be counter to the consensus we have reached.
EMU was chartered with a constrained set of goals, which is why we must re-charter to add a tunnel method. Adding a new item requires gaining consensus within the working group and approval from the IESG. The first step in this process would be to have a proposal. Joe > -----Original Message----- > From: Dan Harkins [mailto:[EMAIL PROTECTED] > Sent: Tuesday, January 29, 2008 5:05 PM > To: Joseph Salowey (jsalowey) > Cc: Dan Harkins; [email protected] > Subject: RE: [Emu] EMU charter update, > > > Hi Joe, > > I don't think I've been very clear. In fact, after speaking > to other people about this topic I'm pretty sure I have not > been clear. So let me try to explain myself again. > > Currently the EMU charter says: > > "This group is chartered to work on the following types of > mechanisms to meet RFC 3748 and RFC 4017 requirements: > [snip] > - A mechanism meeting RFC 3748 and RFC 4017 requirements that > makes use of existing password databases such as AAA > databases. The implementation should strive to be usable in > resource constrained environments." > > So a method that uses an existing password database _is_ in > the charter. > (Note that this was not satisfied by EAP-GPSK nor am I > talking about changing anything about the charter that refers > to EAP-GPSK. EAP-GPSK has an explicit mention in the current > charter that is different from the quoted item above). And > the Goals and Milestones say: > "Aug 2007 Submit password Based Mechanism to IESG" > > Having a password-based authentication method is very > valuable because it uses a very simple trust model. It can be > argued that this trust model is the predominant one in the > Internet today for human to computer interaction. A method > that operates in this simple trust model and uses no > public-key infrastructure would be a valuable contribution > that EMU could make. > > But I should be preaching to the choir because _it's > already in the charter_!!! Certainly the value of this method > has already been discussed in this working group because > consensus was reached to have it be in the charter. > > Now, I also see considerable value in having a tunneled > method that could, just so happen, allow for client-side > authentication with a password. I'd expect it can do a whole > suite of options for various client-side authentication but a > password could be one. That's great. > Let's include that in the charter. In fact, that was "Option > 2" that that there was humming for back in October of 2007. > > What is being proposed is modifying the aforementioned > charter item to read: > > "- A mechanism meeting RFC 3748 and RFC 4017 requirements > that makes use of existing password databases such as AAA > databases. This item will be based on the above tunnel method." > > And it's that last sentence that I'm taking issue with. There > is already, in the proposed charter update, explicit mention > of a tunneled method that will support a password-based > authentication mechanism. So adding that last sentence does > nothing except _remove_ something from the charter. > > I do not see any rationale for, or any value in, removing a > stand-alone method that provides password-authentication from > the charter. All we need to do is update the Goals and > Milestones. I happen to have a protocol in mind that I think > can satisfy this requirement and I'd like it to find a home in EMU. > > regards, > > Dan. > > On Wed, January 23, 2008 1:32 pm, Joseph Salowey (jsalowey) wrote: > > Hi Dan, > > > > Comments inline below: > > > >> -----Original Message----- > >> From: Dan Harkins [mailto:[EMAIL PROTECTED] > >> Sent: Wednesday, January 23, 2008 11:34 AM > >> To: Joseph Salowey (jsalowey) > >> Cc: Dan Harkins; [email protected] > >> Subject: RE: [Emu] EMU charter update, > >> > >> > >> Hi Joe, > >> > >> I went back and looked at the mailing list archives and > the thing > >> is I can't really see where the group decided NOT to pursue an EAP > >> method that is resistant to dictionary attack and is also > not based > >> on a tunnel method. > >> > > [Joe] The group has decided to work on the set of EAP > methods in the > > charter. For the password based method the group has > decided to work > > on a tunnel method (see list archives October 2007). While > this does > > not explicitly exclude another password based method, > another password > > based method is not within the scope of the charter. > > > >> The group wants to add a tunnel method and that method should > >> support passwords as well as other authentication > mechanisms. And I'm > >> all on board for that! But that doesn't mean that password > >> authentication without a tunnel method is something we should not > >> work on. > >> > > [Joe] We need to make more progress on the current work > items before > > we consider taking on new work. > > > >> The working group had consensus for EAP-GPSK over EAP-TLS with > >> TLS-PSK and for those very same reasons I think an EAP-password > >> method that is resistant to dictionary attack would be > good. Is there > >> some reason why it wouldn't be good? > >> Is there something I'm missing? > >> > > [Joe] I think there are differing opinions within the > group. There is > > a strong sentiment that fewer EAP methods is better than > more. Others > > may be more liberal with respect to new methods. Right now it is > > important that we make progress on the items that we have > consensus on > > before we attempt to open up new ones. > > > > > >> regards, > >> > >> Dan. > >> > >> On Tue, January 22, 2008 9:17 pm, Joseph Salowey (jsalowey) wrote: > >> > > >> > > >> >> -----Original Message----- > >> >> From: Dan Harkins [mailto:[EMAIL PROTECTED] > >> >> Sent: Tuesday, January 22, 2008 5:12 PM > >> >> To: Joseph Salowey (jsalowey) > >> >> Cc: Dan Harkins; [email protected] > >> >> Subject: RE: [Emu] EMU charter update, > >> >> > >> >> > >> >> Hi Joe, > >> >> > >> >> OK, so the charter is being opened up to add support for a > >> >> password-based mechanism, which should be resistant to a > >> dictionary > >> >> attack, and that mechanism must use the tunnel method. Right? > >> >> > >> > [Joe] Yes, this is the decision the working group made and > >> the reason > >> > why we are opening the charter. > >> > > >> >> It looks to me like we're explicitly writing a stand-alone > >> >> password-based method (which is resistant to dictionary > >> >> attack) out of the charter. > >> >> That seems odd. Why are we doing that? > >> >> > >> > [Joe] We are explicitly adding a charter item for a tunnel > >> method and > >> > a password method based on the tunnel method. This is the > >> direction > >> > the working group chose. > >> > > >> >> Dan. > >> >> > >> >> On Tue, January 22, 2008 2:41 pm, Joseph Salowey > (jsalowey) wrote: > >> >> > > >> >> > > >> >> >> -----Original Message----- > >> >> >> From: Dan Harkins [mailto:[EMAIL PROTECTED] > >> >> >> Sent: Tuesday, January 22, 2008 2:13 PM > >> >> >> To: Joseph Salowey (jsalowey) > >> >> >> Cc: [email protected] > >> >> >> Subject: RE: [Emu] EMU charter update, > >> >> >> > >> >> >> > >> >> >> Hi Joe, > >> >> >> > >> >> >> On Tue, January 22, 2008 12:38 pm, Joseph Salowey > >> (jsalowey) wrote: > >> >> >> > Hi Dan, > >> >> >> > > >> >> >> >> -----Original Message----- > >> >> >> >> From: Dan Harkins [mailto:[EMAIL PROTECTED] > >> >> >> >> Sent: Sunday, January 20, 2008 9:56 PM > >> >> >> >> To: [email protected] > >> >> >> >> Subject: RE: [Emu] EMU charter update, > >> >> >> >> > >> >> >> >> > >> >> >> >> Hi Joe, > >> >> >> >> > >> >> >> >> Why are we stating that the PSK method must use a > >> >> strong shared > >> >> >> >> secret and the method resistant to dictionary attack > >> >> must use the > >> >> >> >> tunneled method? That seems odd. > >> >> >> > > >> >> >> > [Joe] The PSK is assumed to be a strong shared secret and > >> >> >> is resistant > >> >> >> > to dictionary attack. > >> >> >> > >> >> >> The notion of resistance to dictionary attack is not > >> based on the > >> >> >> strength of the PSK it is based on whether the advantage > >> >> an adversary > >> >> >> can gain to determine the PSK is based _solely_ on > >> >> interaction with a > >> >> >> protocol participant. If any advantage can be gained through > >> >> >> something like computation then the protocol is not > >> resistant to > >> >> >> dictionary attack. > >> >> >> > >> >> >> The GPSK protocol is NOT resistant to a dictionary attack > >> >> >> regardless of the assumptions placed on the PSK. > >> >> >> > >> >> > [Joe] OK, dictionary attack resistance is not a requirement > >> >> for GPSK. > >> >> > > >> >> >> >> How about > >> >> >> >> something along these lines: > >> >> >> >> > >> >> >> >> - A mechanism based on shared secrets that meets RFC > >> >> 3748 and RFC > >> >> >> >> 4017 requirements. This mechanism should strive to be > >> >> simple and > >> >> >> >> compact > >> >> >> >> for implementation in resource constrained environments. > >> >> >> Preference > >> >> >> >> will be given to solutions that can be used with a > >> >> >> cryptographically > >> >> >> >> weak shared secret and that are resistant to > >> >> dictionary attack. > >> >> >> >> > >> >> >> > [Joe] This item of the charter is not open for revision. > >> >> The GPSK > >> >> >> > document to meet this charter item is in IESG review at > >> >> this time. > >> >> >> > >> >> >> That's very curious. A charter that mandates a weak > >> >> solution and is > >> >> >> not open to revision. What other portions are not open for > >> >> revision? > >> >> >> > >> >> > [Joe] The charter is opened up to add support for a tunnel > >> >> method, a > >> >> > password based method and to clarify "enhanced TLS". > >> Other items, > >> >> > especially items that are near completion, are not open for > >> >> revision. > >> >> > > >> >> > > >> >> >> Dan. > >> >> >> > >> >> >> >> If a method based on a shared secret just so happened to > >> >> >> not require > >> >> >> >> a cryptographically strong shared secret and was > >> resistant to > >> >> >> >> dictionary attack I really hope EMU would accept it and > >> >> >> not say, "no, > >> >> >> >> sorry that is too strong for us, our charter mandates a > >> >> >> much weaker > >> >> >> >> solution." Of course if such a solution was not, for > >> >> >> whatever reason, > >> >> >> >> acceptable to the working group we could fall back on the > >> >> >> "must be a > >> >> >> >> strong shared secret" > >> >> >> >> requirement. > >> >> >> >> > >> >> >> >> The tunneled method should be resistant to dictionary > >> >> >> attack but if > >> >> >> >> the non-tunneled one was also resistant to dictionary > >> >> >> attack wouldn't > >> >> >> >> that be goodness? > >> >> >> >> > >> >> >> >> regards, > >> >> >> >> > >> >> >> >> Dan. > >> >> >> >> > >> >> >> >> "Joseph Salowey (jsalowey)" <jsalowey at cisco.com> wrote > >> >> >> >> > Below is a draft of the EMU charter that reflects > >> >> >> >> discussions we had > >> >> >> >> > at IETF 70. Please review this and send comments. I > >> >> >> would like to > >> >> >> >> > have comments in by January 23, 2008. > >> >> >> >> > > >> >> >> >> > 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 and only a few methods are > documented > >> >> >> >> in RFCs. The > >> >> >> >> > lack of documented, open specifications is a > >> deployment and > >> >> >> >> > interoperability problem. In addition, none of the EAP > >> >> >> >> methods in the > >> >> >> >> > standards track implement features such as key > >> >> >> derivation that are > >> >> >> >> > required for many modern applications. This poses a > >> >> >> >> > problem > >> >> >> >> for, among > >> >> >> >> > other things, the selection of a mandatory to implement > >> >> >> >> > EAP > >> >> >> >> method in > >> >> >> >> > new network access technologies. For example, no > >> >> standards track > >> >> >> >> > methods meet new requirements such as those posed in RFC > >> >> >> >> 4017, which > >> >> >> >> > documents IEEE 802.11 requirements for EAP methods. > >> >> >> >> > > >> >> >> >> > This group is chartered to work on the > following types of > >> >> >> >> mechanisms > >> >> >> >> > to meet RFC 3748 and RFC 4017 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 that meets > >> >> >> >> > RFC > >> >> >> >> 3748 and > >> >> >> >> > RFC > >> >> >> >> > 4017 requirements. This mechanism should strive to be > >> >> simple and > >> >> >> >> > compact for implementation in resource constrained > >> >> environments. > >> >> >> >> > > >> >> >> >> > - A mechanism to support extensible communication > >> >> within a TLS > >> >> >> >> > protected tunnel that meets RFC 3748 and RFC 4017 > >> >> >> >> requirements. 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. So as to > >> >> >> >> > enable RFC 2716bis to focus solely on clarifications to > >> >> >> >> > the > >> >> >> >> existing > >> >> >> >> > protocol, this effort will be handled in a separate > >> >> >> document. This > >> >> >> >> > item will not generate a new method, rather it will > >> >> >> >> > enhance > >> >> >> >> EAP-TLS or > >> >> >> >> > the TLS based tunnel method. > >> >> >> >> > > >> >> >> >> > - A mechanism meeting RFC 3748 and RFC 4017 requirements > >> >> >> that makes > >> >> >> >> > use of existing password databases such as AAA > databases. > >> >> >> >> This item > >> >> >> >> > will be based on the above tunnel method. > >> >> >> >> > >> >> >> >> > >> >> >> >> > >> >> >> >> > >> >> >> >> _______________________________________________ > >> >> >> >> Emu mailing list > >> >> >> >> [email protected] > >> >> >> >> https://www1.ietf.org/mailman/listinfo/emu > >> >> >> >> > >> >> >> > > >> >> >> > >> >> >> > >> >> >> > >> >> > > >> >> > >> >> > >> >> > >> > > >> > >> > >> > > > > > _______________________________________________ Emu mailing list [email protected] https://www1.ietf.org/mailman/listinfo/emu
