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.
On Tue, July 21, 2009 3:19 pm, Joseph Salowey (jsalowey) wrote:
> 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: ietf-bounces@xxxxxxxx [mailto:ietf-bounces@xxxxxxxx] On
>> Behalf Of Glen Zorn
>> Sent: Tuesday, July 21, 2009 7:01 AM
>> To: iesg-secretary@xxxxxxxx
>> Cc: iesg-secretary@xxxxxxxx; ietf@xxxxxxxx
>> 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
>> (http://www.ietf.org/ibin/c5i?mid=6&rid=49&gid=0&k1=934&k2=675
>> 9&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
>>
>>
>>
>> _______________________________________________
>> Ietf mailing list
>> Ietf@xxxxxxxx
>> https://www.ietf.org/mailman/listinfo/ietf
>>
> _______________________________________________
> Ietf mailing list
> Ietf@xxxxxxxx
> https://www.ietf.org/mailman/listinfo/ietf
>
_______________________________________________
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf