Subject: Re: [Cfrg] Key-Derivation Scheme

From: Simon Josefsson <[email-masked]>
Date: Mon, 09 Jun 2014 09:35:09 +0200

"Dan Harkins" <[email-masked]> writes:

>   A much better solution to your problem is to use a password-authenticated
> key exchange based on a zero knowledge proof. That way, not only does
> the password not cross the wire/ether, neither does password-derived
> data.

I think most people agree would agree with that -- but as far as I know
existing zero-knowledge authentication password mechanisms have other
serious problem (e.g., servers knowing password, lack of security proof,
or patent issues).  Given that, I think it is wortwhile to improve the
practical but theoretically less optimal solutions.

/Simon

---

From: Watson Ladd <[email-masked]>
Date: Mon, 9 Jun 2014 09:00:26 -0300

> practical but theoretically less optimal solutions.

Socialist Millionaires Protocol was published in 1996. Any patents
expire in 2016 if any were filed for: a quick search finds none.
It can be made to work over any group.

PAKE (the original) has a patent expiring in 2016. It has optimal
security with a proof done in 2001.

SIncerely,
Watson Ladd

-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin

---

From: Paul Lambert <[email-masked]>
Date: Mon, 9 Jun 2014 08:57:03 -0700

>security with a proof done in 2001.

The Dragonfly key exchange was adopted by IEEE 802.11s in 2009. This
key exchange has no identified patent issues.  The protocol
(called SAE in the IEEE) will be adopted for other wireless applications
and will be deployed in a large number of consumer
devices in the future (IMO).

The key exchange has been documented for use in applications that include:
IEEE 802.11, IEEE 802.15.9, IPsec and TLS.

The protocol has no identified security issues, but it¹s
structure is less amenable to the development of a security proof.
No formal proof has been developed at this time.

So the options are:
 1 - pake      proof         patents (until after at least 2016)
 2 - pake      no-proof      no-patents (now)
 3 - no-pake   same-old less optimal solutions  no-patents (now)

I¹d rather have a pake now with no proof than continue the same-old
suboptimal solutions.

Paul

>_______________________________________________
>Cfrg mailing list
>[email-masked]
>http://www.irtf.org/mailman/listinfo/cfrg

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Mon, 9 Jun 2014 13:21:50 -0400

The following is a quote from section 1 of the J-PAKE draft (
http://tools.ietf.org/html/draft-hao-jpake-01):

   There are a few factors that may be considered in favor of J-PAKE
   over others.  First, J-PAKE has security proofs, while equivalent
   proofs are lacking in EKE, SPEKE and SRP-6.  Second, J-PAKE is not

   patented.  It follows a completely different design approach from all
   other PAKE protocols, and is built upon a well-established Zero
   Knowledge Proof (ZKP) primitive: Schnorr NIZK proof [I-D-Schnorr
<http://tools.ietf.org/html/draft-hao-jpake-01#ref-I-D-Schnorr>].

If this is indeed the case, then we do have a PAKE with a proof and no
patents.

Regards,
 Rifaat

---

From: Paul Lambert <[email-masked]>
Date: Mon, 9 Jun 2014 11:21:27 -0700

The following is a quote from section 1 of the J-PAKE draft (http://tools.ietf.org/html/draft-hao-jpake-01):

   patented.  It follows a completely different design approach from all
   other PAKE protocols, and is built upon a well-established Zero
   Knowledge Proof (ZKP) primitive: Schnorr NIZK proof [I-D-Schnorr<http://tools.ietf.org/html/draft-hao-jpake-01#ref-I-D-Schnorr>].

If this is indeed the case, then we do have a PAKE with a proof and no patents.

Would be very nice if true, while not patented some investigation by interested parties would be useful.
Also … quick skim of the references it looks like there is some possible clean-up work depending on goals:
 - better clarification of operation (e.g. Use and necessity of  “UserId”)
 - clarification of protocol formats associated with algorithm
 - translation to ECC and clear identification of default curves
 - … Etc

Paul

Regards,
 Rifaat

On Mon, Jun 9, 2014 at 11:57 AM, Paul Lambert <[email-masked]<mailto:[email-masked]>> wrote:

On 6/9/14, 5:00 AM, "Watson Ladd" <[email-masked]<mailto:[email-masked]>> wrote:

>On Mon, Jun 9, 2014 at 4:35 AM, Simon Josefsson <[email-masked]<mailto:[email-masked]>>
>wrote:
>> "Dan Harkins" <[email-masked]<mailto:[email-masked]>> writes:
>>

So the options are:

Paul

>[email-masked]<mailto:[email-masked]>

_______________________________________________
Cfrg mailing list
[email-masked]<mailto:[email-masked]>
http://www.irtf.org/mailman/listinfo/cfrg

---

From: Watson Ladd <[email-masked]>
Date: Mon, 9 Jun 2014 18:47:46 -0300

>  3 - no-pake   same-old less optimal solutions  no-patents (now)

Really? There are other pakes then Dragonfly and PAKE. In particular SRP
was included in TLS years ago, SMP is used by OTR today. JPAKE is
questionable: the claimed proofs don't exist, but at least there is
analysis that doesn't exist for dragonfly.

-- 
"Those who would give up Essential Liberty to purchase a little Temporary
Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin

---

From: Paul Lambert <[email-masked]>
Date: Mon, 9 Jun 2014 16:24:19 -0700

So the options are:

Really? There are other pakes then Dragonfly and PAKE. In particular SRP was included in TLS years ago, SMP is used by OTR today.
No, the above was a classification of the options and was not intended to restrict the list of potential acronyms.    I’d put SRP in option 1 … assumed issues with IPR that prevent adoption.  I’m not familiar with SMP.

JPAKE is questionable: the claimed proofs don't exist, but at least there is analysis that doesn't exist for dragonfly.

Ok.  JPAKE is also new with respect to patent claims, Dragonfly has been out since 2009 and has not had any open claims made against the protocol.

It is truly a shame that this forum is unable to clearly select and define the usage of an IPR-free PAKE suitable for broad Internet application.

 Paul

Paul

--
"Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin

---

From: Schmidt, Jörn-Marc <[email-masked]>
Date: Tue, 10 Jun 2014 08:09:23 +0000

>It is truly a shame that this forum is unable to clearly select and define the usage of an IPR-free PAKE suitable for broad Internet application.

I think PACE  is an interesting PAKE to look at: I comes with a security proof [1] and was designed to avoid patents [2]. Further, it has been used in European travel documents for some years now without security or patent issues. 
Just the used integrated mapping is patented - but there are other interesting solutions like simplified SWU or Elligator around.

Best,

Jörn

[1] Security Analysis of the PACE Key-Agreement Protocol. Jens Bender, Marc Fischlin and Dennis Kügler
[2] Introducing the PACE solution. Jens Bender and Dennis Kügler

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Thu, 12 Jun 2014 13:46:26 -0400

On Mon, Jun 9, 2014 at 7:24 PM, Paul Lambert <[email-masked]> wrote:

>
> It is truly a shame that this forum is unable to clearly select and define
> the usage of an IPR-free PAKE suitable for broad Internet application.
>
>  Paul
>

It is indeed a shame.

But this brings me back to the original proposal for a Key-Derivation
Scheme.
While it is not ideal, like a PAKE-based solution, it is probably much
better than the Digest scheme.

Attached is a new version of the document that addresses the comments I
received so far:

1. Use of the Scrypt function, instead of PBKDF2 function
2. Mutual authentication, instead of client authentication only.
3. Protect against replay attack by adding a nonce to the calculation of
the proof-of-possession.

Is that something that could be discussed on this mailing list?

Regards,
 Rifaat

On Mon, Jun 9, 2014 at 7:24 PM, Paul Lambert <[email-masked]> wrote:

> was included in TLS years ago, SMP is used by OTR today.
>
> No, the above was a classification of the options and was not intended to
> restrict the list of potential acronyms.    I'd put SRP in option 1 ...
> assumed issues with IPR that prevent adoption.  I'm not familiar with SMP.
>
> JPAKE is questionable: the claimed proofs don't exist, but at least there
> is analysis that doesn't exist for dragonfly.
>
>
> Ok.  JPAKE is also new with respect to patent claims, Dragonfly has been
> out since 2009 and has not had any open claims made against the protocol.
>
> It is truly a shame that this forum is unable to clearly select and define
> the usage of an IPR-free PAKE suitable for broad Internet application.
>
>  Paul
>
>
>
>
>