Hi John, On Wed, July 22, 2009 10:27 am, John Leslie wrote: > The difference may not be as great as you seem to think. Appeal if > you must, but it's really not unusual to change "proposed status" as > a result of LastCall comments. It might be more helpful to simply post > (polite) LastCall comments of your own about why "Proposed Standard" > would be more appropriate than "Informational". You make a very good suggestion. So let me make some Last Call comments of my own about why "Proposed Standard" is more appropriate that "Informational". Shared keys (including passwords) are the preeminent access method for the Internet today. EAP is a very popular protocol for providing network access. I believe the Internet community needs to recommend a way to _securely_ use this wildly popular credential in this hugely popular authentication protocol. An Informational RFC is published just for the general information of the Internet community and does not represent a recommendation of the Internet community. So Informational doesn't seem like the right level. The importance of this subject, and the need to have a recommendation by the Internet community, can be seen by the fact that a Standards Track RFC already exists to use shared keys in EAP, RFC5433, but it is insecure and is vulnerable to passive dictionary attack. Therefore I believe it is necessary to recommend a way to use shared keys securely; it is necessary to publish another RFC at the same level as RFC5433 that does not have the flaws of RFC5433. It would not make much sense to have the Internet community recommend an insecure way of using shared keys with EAP and then publish a secure way of using shared keys with EAP merely for edification purposes only. No, a Standards Track RFC is really needed. As Joe Salowey noted, there is another draft that specifies use of the Encrypted Key Exchange (EKE) as an EAP method. Unfortunately, that protocol must define its own special finite cyclic groups, and it cannot use finite cyclic groups based on elliptic curve cryptography, or it will suffer from the same flaw as RFC5433. EAP-pwd can use any of the two score or so finite cyclic groups defined by for use in IKE and TLS, both elliptic curve groups and, more traditional, groups based on exponentiation modulo a large prime number. These groups have seen broad use and received scrutiny by the academic and cryptographic community, so it is important to use them and not "roll your own". EAP-pwd is a much more general purpose solution to the problem and is, in my opinion, a better candidate for recommendation. EAP-pwd has received about as much scrutiny as it can in the IETF. When presented at an EMU meeting it received quite a bit of interest but was ruled out-of-scope due to EMU's charter. There were also concerns that there was no definitive statement that EAP-pwd was not IPR encumbered (which is nearly impossible to provide anyway). There is community interest in secure shared-secret authentication with EAP and EAP-pwd provides that. To sum, I think the Internet community must recommend a way to use shared keys (including passwords) securely with EAP (RFC5433 does not recommend a _secure_ way to use them); it must publish an RFC at the Standards Track level. And EAP-pwd is the best choice to do that because it is a more robust and general purpose solution that EAP-EKE. I would like to hear other comments on this topic (with the exception of those over the irrelevant topic of IPR-- for which there is none in this draft). Why shouldn't it be a Proposed Standard? best regards, Dan. _______________________________________________ Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf