Hi Dan, > -----Original Message----- > From: Dan Harkins [mailto:[EMAIL PROTECTED] > Sent: Sunday, January 20, 2008 9:56 PM > To: emu@ietf.org > 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. > 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. > 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 > Emu@ietf.org > https://www1.ietf.org/mailman/listinfo/emu > _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu
