Subject: RE: Last Call: draft-harkins-emu-eap-pwd (EAP Authentication Using Only A Password) to Informational RFC

From: "Glen Zorn" <[email-masked]>
Date: Tue, 21 Jul 2009 21:01:05 +0700

It's come to my attention that there is an error in the above referenced
announcement
(http://www.ietf.org/ibin/c5i?mid=6&rid=49&gid=0&k1=934&k2=6759&tid=12481845
60).  The announcement says "The IESG has received a request from an
individual submitter to consider the following document: - 'EAP
Authentication Using Only A Password ' as an Informational RFC" but this
statement is false: the IESG received a request to publish the draft as a
Proposed Standard.  The intended status is clearly indicated in the first
page header (reproduced below).  Please correct this error and issue the
corrected announcement as soon as possible.  Thank you.

Network Working Group                                         D. Harkins
Internet-Draft                                            Aruba Networks
Intended status: Standards Track                                 G. Zorn
Expires: December 31, 2009                                       NetCube
                                                           June 29, 2009

                EAP Authentication Using Only A Password
                      draft-harkins-emu-eap-pwd-04

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Tue, 21 Jul 2009 15:19:03 -0700

I object to this document being published as a Proposed Standard.  When
this document was discussed in the EMU meeting at IETF-71 there was much
concern raised with respect to existing IPR in the area of secure
password methods used by this draft.  Additionally, soon after its
initial publication and announcement on the CFRG list, flaws were found
with the draft.  The authors were very responsive in addressing the
issues, but this points out that the algorithms used in this draft have
had less review than other secure password mechanisms developed over the
years.  Another approach to a secure password only EAP method, EAP-EKE,
has been proposed in draft-sheffer-emu-eap-eke-02.  This method is based
on EKE, which is already in use, has a long history of review, and has
much better understood IPR considerations.  Given that there is an
alternative to consider I do not support publishing EAP-PWD in the
standards track. 

Joe

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Glen Zorn
> Sent: Tuesday, July 21, 2009 7:01 AM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: RE: Last Call: draft-harkins-emu-eap-pwd (EAP 
> Authentication UsingOnly A Password) to Informational RFC 
> 
> It's come to my attention that there is an error in the above 
> referenced announcement
> 60).  The announcement says "The IESG has received a request 
> from an individual submitter to consider the following 
> document: - 'EAP Authentication Using Only A Password ' as an 
> Informational RFC" but this statement is false: the IESG 
> received a request to publish the draft as a Proposed 
> Standard.  The intended status is clearly indicated in the 
> first page header (reproduced below).  Please correct this 
> error and issue the corrected announcement as soon as 
> possible.  Thank you.
> 
> Network Working Group                                         
> D. Harkins
> Internet-Draft                                            
> Aruba Networks
> _______________________________________________
> Ietf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf
>

---

From: "Dan Harkins" <[email-masked]>
Date: Tue, 21 Jul 2009 17:54:23 -0700 (PDT)

Hi Joe,

  As I mentioned in the EMU meeting at IETF-71 I have not patented this
exchange, my employer has not patented this exchange, Glen has not
patented this exchange, and neither has his employer. I am unaware of
any patents on this exchange by others and I believe no existing patents
apply. Of course, reasonable people can disagree on whether other known
patents apply (and trolls may pop up making claims to hold relevant IPR)
but I don't know why that would have an impact on it being published as
a Proposed Standard.

  Let's see how the subject of IPR is being handled _right now_ with
other drafts:

     - TLS extractors: I know you know about this draft because you're
       the document shepherd. This draft is the subject of an IPR
       disclosure and is still on the Standards Track in Last Call.
       EAP-pwd is NOT the subject of any IPR disclosure.

     - draft-green-secsh-ecc: this specifies how to implement a patented
       key exchange (ECMQV) in SSH and it is on the Standards Track
       in Last Call.

If specification of patented algorithms and drafts subject to IPR
disclosure is not enough to knock a draft of the Standards Track then
I don't know why FUD about a possible patent _maybe_ existing that
_might_ apply is. I guess I don't understand your logic. Can you explain
it in a way that justifies the different treatment for these drafts?

  Regarding the flaws, yes the -00 version of this draft had a flaw.
But then, so did draft-sheffer-emu-eap-eke-00. So if the fact that a
flaw was found and fixed is enough to cause you to spoil on a draft
then why do you think draft-sheffer-emu-eap-eke is "an alternative to
consider"? Again, I don't understand your logic.

  EAP-EKE has the additional drawback that it must define its own groups
to use because using the standard Diffie-Hellman groups from the IANA
registry for IKE or TLS gives an attacker a significant advantage
in guessing the password by simply passively observing an exchange.
EAP-pwd does not suffer from this and can use groups that have received
extensive use and review. Forcing people to use new groups that have not
received scrutiny is a recipe for trouble.

  Furthermore, I do not think that EAP-EKE satisfies its security
claims when used with an elliptic curve group. Specifically, I believe
it is subject to passive dictionary attack when using an ECC group.
Small memory- and processor-constrained devices may not be able to
efficiently do operations in a multiplicative field of 3072 bits (to
get a suitably strong AES key) while it may in one of 256 bits. Forcing
them to use weaker groups is not appropriate.

  The relevant AD handling advancement of this draft received a private
request asking that it be Informational "like other EAP methods." He has
asked this individual to take the request public but that has not
happened. Let me take this opportunity to address that individual in
the hopes that he or she speaks up.

  There is no known policy of which EAP methods get advanced how. It seems
very bizarre that an EAP method for authentication using a shared secret
that is subject to PASSIVE OFF-LINE DICTIONARY ATTACK is a Proposed
Standard (EAP-GPSK) but an EAP method for authentication using a shared
secret that is resistant to passive, active and all forms of off-line
dictionary attack should be Informational. If it's flawed it's Standards
Track, if it's not flawed it's Informational. That doesn't make sense
much sense to me.

  I respectfully request this draft to be published on the track it was
intended to be published on. Given that drafts with considerable IPR
considerations, both individual submissions and products of a WG, are
on the Standards Track, IPR FUD should not be used as a way to prevent
this draft from advancing as a Proposed Standard.  EAP-pwd is a general
purpose solution for the broader Internet community to do EAP
authentication using only a password; EAP-EKE is not. EAP-EKE is not
"an alternative to consider" because of it's limited use.

  There do not seem to be consistently applied policies regarding why a
draft has to be Informational so I think it is only fair to treat this
draft the way other drafts are being treated (see above): the way it
intends to be advanced, as a Proposed Standard.

  regards,

  Dan.

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Tue, 21 Jul 2009 21:16:23 -0400

On Tue, 21 Jul 2009 17:54:23 -0700 (PDT)
"Dan Harkins" <[email-masked]> wrote:

> _might_ apply is.

I'm no longer an AD, but if I were, I'd propose a policy that the IESG
automatically disregard any objection to a spec on the grounds that it
uses a patented protocol.

Folks, the IETF, via the IPR WG (of which I used to be co-chair)
explicitly declined to adopt that standard.  The policy under which it
operates, *by IETF consensus*, is that the WG should decide for any
given document if the (vast) disadvantages of an encumbered technology
are outweighed by the abilities it grants.  I see no reason whatsoever
to even consider a generic objection.; that's not what our explicit
policy says.

I should note that I have no opinions on the merits of this draft
compared with an EKE-based alternative, though I should also note that
(a) I'm the coinventor of EKE, and (b) as far as I know the US patent
on EKE (5,241,599) doesn't expire until October 1, 2011.

		--Steve Bellovin, http://www.cs.columbia.edu/~smb

---

From: "Dan Harkins" <[email-masked]>
Date: Tue, 21 Jul 2009 20:28:45 -0700 (PDT)

Hi Steve,

> uses a patented protocol.

  I completely agree. I am on the record stating that the TLS Extractors
draft should be advanced on the Standards Track. All I'm saying is that
the policy applied to it (and others) should apply to mine.

> to even consider a generic objection.; that's not what our explicit

  And in this case there is not even a statement that this draft uses
encumbered technology, only the lack of a statement that it does not
(and given that it's really hard to prove a negative, that is an
unreasonable bar to set, in my opinion).

  I really hope this IPR nonsense as it relates to EAP-pwd can be
dispatched.

  regards,

  Dan.

---

From: "Glen Zorn" <[email-masked]>
Date: Wed, 22 Jul 2009 14:55:36 +0700

> alternative to consider I do not support publishing EAP-PWD in the

IMHO, this question is orthogonal (& largely immaterial) to the one at hand.
It's one thing for the IETF to reach consensus that the draft be
Informational; it is a completely different thing for the publication path
to be changed without either notification of (other than the Last Call
announcement itself) or consultation with the authors.  If this was _not_ a
simple error, then the action was arbitrary & capricious, not to mentioned
underhanded & must certainly be considered as grounds for dismissal of the
(as yet unnamed) person or persons responsible, unless the IETF has recently
converted to an authoritarian regime.  As an aside, it seems that
draft-green-secsh-ecc has suffered the same fate, suggesting that this is
neither an error nor an isolated occurrence.

...

---

From: John Leslie <[email-masked]>
Date: Wed, 22 Jul 2009 13:27:42 -0400

Glen Zorn <[email-masked]> wrote:
>> this document was discussed in the EMU meeting at IETF-71 there was
>> much concern raised with respect to existing IPR...
> 

   Agreed.

> announcement itself) or consultation with the authors.

   Lack of consultation with the authors would be unfortunate.

> If this was _not_ a simple error, then the action was arbitrary &
> capricious, not to mentioned underhanded & must certainly be considered
> as grounds for dismissal of the (as yet unnamed) person or persons
> responsible,

   I do not agree. At most, an apology might be required.

> unless the IETF has recently converted to an authoritarian regime.

   There is nothing "recent" about this. To be considered by the IESG,
there must be a sponsoring Area Director for any Individual Submission.
That Area Director has always had full authority to decide whether to
LastCall as Informational or Proposed Standard.

> As an aside, it seems that draft-green-secsh-ecc has suffered the same
> fate, suggesting that this is neither an error nor an isolated occurrence.

   Exactly!

   (You technically have the right to appeal the decision to LastCall as
Informational; but the Area Director will always have the right to
decline to sponsor publication as Proposed Standard.)

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

--
John Leslie <[email-masked]>

---

From: "Dan Harkins" <[email-masked]>
Date: Wed, 22 Jul 2009 16:41:13 -0700 (PDT)

Hi John,

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