Subject: Re: [Cfrg] SPAKE2+mbDH a PAKE+PKA

From: Dan Harkins <[email-masked]>
Date: Sat, 1 Oct 2016 22:22:11 -0700

Paul,

   Why are you and Andy Lutomirski asking for review of a couple of slides
on a powerpoint deck? Especially a deck whose focus is about a different
protocol that does not exist anymore. Make an Internet-Draft that specifies
_exactly_ how the protocol runs and not some ambiguous powerpoint suggestion
based on a slide that uses some abbreviated notation that you admit is
incomplete?

   An I-D should clarify the unclear stuff regarding how you suggest to
use AEAD schemes. Some of these schemes have critical usage requirements--
like NEVER reuse a counter-- that you will have to deal with. You can't
just wave your hands and say "encrypt".

   Given the fact that it is not really clear what you and Andy Lutomirski
are proposing I can only reply to the slides that you provide under the
caveat that they may be inaccurate given their poor specification. So...

   The "mutually blinded DH" you and Andy Lutomirski propose is 
completely broken
and provides absolutely no authentication at all. A DH by itself provides no
authentication so doing another DH "under the protection of" another 
unauthenticated
DH  does not magically create authentication out of thin air.

   There is a difference between proof-of-possession and authentication. The
former is necessary for the kind of exchange you propose but it is not 
sufficient.
An unauthenticated DH provides the former but not the latter. Your 
mutually blinded
DH also provides the former but not the latter.

   The "mutually blinded DH" that you and Andy Lutomirski propose is 
susceptible to
a simple man-in-the-middle attack due to the fact that it provides 
absolutely no
authentication whatsoever. You have no idea who sends Rb and no idea 
whose public
key is Pb. The fact that Pb is sent encrypted by a secret derived from an
unauthenticated Diffie-Hellman does not change anything. In fact, it 
enables the
attack.

   Modulo the obvious concerns with your proposal being a couple of 
powerpoint
slides I feel safe in saying that the protocol you and Andy Lutomirski 
propose
is completely broken.

   Dan.

On 9/29/16 1:54 AM, Paul Lambert wrote:
>
>     Dear Stanislav,
>
>
>     Thank you for these links – they give a slightly new viewpoint on
>     PAKEs applications (I think the most discussed question will be
>     "for which applications will combining public keys and passwords
>     be most useful?").
>
> Yes … it may be useful as a type of ‘introduction’ process.
>
>
>     An editorial comment on the description of the protocol in the
>     slides: it seemts that after the second message A should check
>     that "R_B - w*M_B == x_B * P_B", not "R_B == x_B * P_B" as it is
>     shown now. Similarly with the B's check.
>
>
>     And a tiny remark: there is a misprint in the plaintext that A
>     encrypts on sk_AB for the third message: "(x_A, P_A)" should be
>     there, not "(m_A, P_A)".
>
>
> Many thanks for catching my errors!
>
> I’ve updated the figures and reposted: 
> https://mentor.ieee.org/802.11/dcn/16/11-16-1142-06-00ai-cryptographic-review-and-pkex.ppt
>
>
>     About the protocol itself, I'll try my best to give you our
>     opinion today or tomorrow.
>
>     At a glance, it seems to be useful to add some specific
>     requirements for the used "encrypt" functions now or some concrete
>     cipher modes (e.g. GCM or CTR + HMAC)
>
>
> Yes, this is not clear. The notation slide mentions  AEAD encryption 
> but could say more on requirements. The ‘additional data’ is not being 
> used, so AEAD is not strictly required. For concrete examples, I’m 
> considering AES-SIV or GCM-SIV or something similar.
>
>
>     due to the words "decrypt is successful" (is it a real data
>     authentication or just some padding check?). EMVco used to check
>     PIN-blocks just by correctness of ECB decryption of IUN, so we
>     should have more details here.
>
>
> Yes, exactly.  The decryption provides the validity check for the 
> password based authentication and does need a better description.
>
> Best Regards,
>
> Paul
>
>
>     Kindest regards,
>     Stanislav
>
>
>
>     2016-09-29 4:25 GMT+03:00 Paul Lambert <[email-masked]
>     <mailto:[email-masked]>>:
>
>
>         The PKEX protocol (
>         https://tools.ietf.org/html/draft-harkins-pkex-00
>         <https://tools.ietf.org/html/draft-harkins-pkex-00> )
>         provides PAKE functionality (with SPAKE2) and adds public key
>         authentication (PAKE+PKA).
>
>         In looking at alternatives to PKEX, combining an existing and
>         evaluated
>         authenticated public key exchange with a PAKE seems like an
>         interesting
>         design path. To this end, the SPAKE2 protocol (
>         https://tools.ietf.org/html/draft-irtf-cfrg-spake2-03
>         <https://tools.ietf.org/html/draft-irtf-cfrg-spake2-03> )
>         combines nicely
>         with mutually blinded Diffie-Hellman (mbDH). Blinded DH (bDH)
>         is described
>         in https://www.emvco.com/specifications.aspx?id=285
>         <https://www.emvco.com/specifications.aspx?id=285>
>
>         A brief description of the resulting SPAKE2+mbDH protocol is
>         contained in
>         slides 13 to 18 of:
>
>         https://mentor.ieee.org/802.11/dcn/16/11-16-1142-04-00ai-cryptographic-rev
>         iew-and-pkex.ppt
>         <https://mentor.ieee.org/802.11/dcn/16/11-16-1142-04-00ai-cryptographic-rev%0Aiew-and-pkex.ppt>
>
>         Comments would be appreciated.
>
>         If this protocol seems useful an RFC could be developed.
>
>         Paul
>
>
>
>         _______________________________________________
>         Cfrg mailing list
>         [email-masked] <mailto:[email-masked]>
>         https://www.irtf.org/mailman/listinfo/cfrg
>         <https://www.irtf.org/mailman/listinfo/cfrg>
>
>
>
>
>
>
> _______________________________________________
> Cfrg mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/cfrg

---

From: Andy Lutomirski <[email-masked]>
Date: Sat, 1 Oct 2016 22:48:17 -0700

For the record: I have nothing to do with the proposal here.  This thread
is the first time I've seen it.

I still think that the right way to do this type of exchange is to use
existing, proven primitives as black boxes.  I don't see why the concepts
of "point" or "group", for example, should be involved except insofar as
they occur in the details of the underlying primitives.

So if SPAKE2 is going to be used, use it as is.  Don't modify it without a
very compelling reason and a proof.

On Oct 1, 2016 10:22 PM, "Dan Harkins" <[email-masked]> wrote:

>   The "mutually blinded DH" you and Andy Lutomirski propose is completely
> broken
> authentication whatsoever. You have no idea who sends Rb and no idea whose
> public
> Thank you for these links – they give a slightly new viewpoint on PAKEs
> applications (I think the most discussed question will be "for which
> applications will combining public keys and passwords be most useful?").
>
> An editorial comment on the description of the protocol in the slides: it
> seemts that after the second message A should check that "R_B - w*M_B ==
> x_B * P_B", not "R_B == x_B * P_B" as it is shown now. Similarly with the
> B's check.
>
>
> And a tiny remark: there is a misprint in the plaintext that A encrypts on
> sk_AB for the third message: "(x_A, P_A)" should be there, not "(m_A, P_A)".
>
>
> I’ve updated the figures and reposted: https://mentor.ieee.
> org/802.11/dcn/16/11-16-1142-06-00ai-cryptographic-review-and-pkex.ppt
>
>
> About the protocol itself, I'll try my best to give you our opinion today
> or tomorrow.
>
> At a glance, it seems to be useful to add some specific requirements for
> the used "encrypt" functions now or some concrete cipher modes (e.g. GCM or
> CTR + HMAC)
>
>
> Yes, this is not clear. The notation slide mentions  AEAD encryption but
> could say more on requirements. The ‘additional data’ is not being used, so
> AEAD is not strictly required. For concrete examples, I’m considering
> AES-SIV or GCM-SIV or something similar.
>
>
> due to the words "decrypt is successful" (is it a real data authentication
> or just some padding check?). EMVco used to check PIN-blocks just by
> correctness of ECB decryption of IUN, so we should have more details here.
>
>
> Yes, exactly.  The decryption provides the validity check for the password
> based authentication and does need a better description.
>
> Best Regards,
>
> Paul
>
>
> Kindest regards,
> Stanislav
>
>
>
> 2016-09-29 4:25 GMT+03:00 Paul Lambert <[email-masked]>:
>
>>
>> The PKEX protocol ( https://tools.ietf.org/html/draft-harkins-pkex-00 )
>> In looking at alternatives to PKEX, combining an existing and evaluated
>> authenticated public key exchange with a PAKE seems like an interesting
>> https://tools.ietf.org/html/draft-irtf-cfrg-spake2-03 ) combines nicely
>> with mutually blinded Diffie-Hellman (mbDH). Blinded DH (bDH) is described
>> A brief description of the resulting SPAKE2+mbDH protocol is contained in
>> slides 13 to 18 of:
>>
> Cfrg mailing [email-masked]://www.irtf.org/mailman/listinfo/cfrg
>
>
>

---

From: Paul Lambert <[email-masked]>
Date: Mon, 3 Oct 2016 18:49:28 +0000

Dear Stanislav,

Thank you very much for your time and effort to review this proposal. I greatly appreciate your insights.

Thank you for your comments and for the updated version of the slides. Since you agree with my thoughts about the importance of defining "encrypt" properties, let's remember this question.

After another careful reading of the protocol now I have a concern about it that seems very important to me.

In the original SPAKE2 (as well as in SESPAKE and AugPAKE etc) there is an important property (that is even proven for SPAKE2 and SESPAKE) of absence of password leakage problems in the cases when the resulting session keys are revealed (in real life - when the session key is misused and compromised somehow). It is extremely important since session keys often get compromised in real life and no one wants to leak authentication data with them.

I agree with your concerns. The property of preventing password leakage when session keys are exposed may not be applicable to every application, but it’s still an important attribute. Most importantly …   The combining of two security primitives should retain all of the properties of the original two primitives.

And the proposed protocol lacks this property: if sk_AB is compromised, then x_A and P_A are known to adversary too - thus he knows w*M_A and can find short secret pw by dictionary attack.

Thus in the current version any agreed session key compromise would lead to long-term password compromise, that seems to be a really bad property.

I see now that the ephemeral mask in SPAKE2 with the masked public key from mbDH have contradictory requirements. The mbDH requires the subsequent exposure of the mask to prove possession of the public key. SPAKE2 requires that the mask never be exposed even if encrypted under a session key. This type of replacement of terms is a flawed construction technique.

A more direct combination of protocol mechanisms would be to perform them both in parallel without significant modification to either base mechanism. The calculation of the shared key(s) could be performed jointly for some efficiency benefits without impacting the combined security characteristics.

I'll be thankful for your comments on this concern. Please correct me, if I missed something in your description.

No, your concerns are well founded and show that I violated my own design goals for building on existing mechanisms. In my enthusiasm to save a point multiple and a few bytes, the proposed design broke a subtile, but fundamental security property of SPAKE2.

Best Regards,

Paul

Kindest regards,
Stanislav Smyshlyaev
От: Paul Lambert
Отправлено: четверг, 29 сентября 2016 г., 11:54
Кому: Stanislav V. Smyshlyaev
Копия: [email-masked]<mailto:[email-masked]>
Тема: Re: [Cfrg] SPAKE2+mbDH a PAKE+PKA

Dear Stanislav,

Thank you for these links – they give a slightly new viewpoint on PAKEs applications (I think the most discussed question will be "for which applications will combining public keys and passwords be most useful?").
Yes … it may be useful as a type of ‘introduction’ process.

An editorial comment on the description of the protocol in the slides: it seemts that after the second message A should check that "R_B - w*M_B == x_B * P_B", not "R_B == x_B * P_B" as it is shown now. Similarly with the B's check.

And a tiny remark: there is a misprint in the plaintext that A encrypts on sk_AB for the third message: "(x_A, P_A)" should be there, not "(m_A, P_A)".

I’ve updated the figures and reposted: https://mentor.ieee.org/802.11/dcn/16/11-16-1142-06-00ai-cryptographic-review-and-pkex.ppt

About the protocol itself, I'll try my best to give you our opinion today or tomorrow.

At a glance, it seems to be useful to add some specific requirements for the used "encrypt" functions now or some concrete cipher modes (e.g. GCM or CTR + HMAC)

Yes, this is not clear. The notation slide mentions  AEAD encryption but could say more on requirements. The ‘additional data’ is not being used, so AEAD is not strictly required. For concrete examples, I’m considering AES-SIV or GCM-SIV or something similar.

due to the words "decrypt is successful" (is it a real data authentication or just some padding check?). EMVco used to check PIN-blocks just by correctness of ECB decryption of IUN, so we should have more details here.

Yes, exactly.  The decryption provides the validity check for the password based authentication and does need a better description.

Best Regards,

Paul

Kindest regards,
Stanislav

2016-09-29 4:25 GMT+03:00 Paul Lambert <[email-masked]<mailto:[email-masked]>>:

Paul

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