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