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
