Dan: Not on the charter doesn't mean it prevent from someone working on such method. Just the group agreed to develop a tunnel method supports password authentication as a WG charter item.
> -----Original Message----- > From: Dan Harkins [mailto:[EMAIL PROTECTED] > Sent: Wednesday, January 23, 2008 2:34 PM > To: Joseph Salowey (jsalowey) > Cc: [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. > > 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. > > 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? > > 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 > _______________________________________________ Emu mailing list [email protected] https://www1.ietf.org/mailman/listinfo/emu
