> -----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
