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
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
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?
Ietf mailing list