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