Re: [Cfrg] Fwd: New Version Notification for draft-harkins-pkex-00.txt

[Andy Lutomirski <[e-mail]>]

On Sep 13, 2016 8:59 AM, "Dan Harkins" <[e-mail]> wrote:
>
>
> On 9/13/16 7:59 AM, Andy Lutomirski wrote:
>>
>> On Sep 13, 2016 12:39 AM, "Dan Harkins" <[e-mail]> wrote:
>> >
>> > On 9/12/16 2:43 PM, Andy Lutomirski wrote:
>> >> Alice and Bob start running the protocol with one password pw1.  Alice
>> >> sends X + Qa = X + F(pw1) * Pi where F is a function that an attacker
>> >> can compute.  The attacker interrupts the exchange and Alice and Bob
>> >> retry using a different pasword.  The draft *says* that the keys are
>> >> ephemeral, but that's really hard to believe because the whole stated
>> >> point is to establish a long-term key.  So Alice how sends X + F(pw2)
>> >> * Pi.
>> >
>> >
>> >   So your "attack" is based on the supposition that it's "really hard
>> > to believe" an ephemeral key is ephemeral? Hmmm.
>> >
>> >   What you have done is to look at the _very first_ of the Security
>> > Considerations, decided to ignore the statement that says you void
>> > the security of the exchange if you reuse ephemeral keys and then claim
>> > you have discovered an "attack" on the protocol?
>>
>> No, I read a different version of the protocol that really did seem to
do this, and I didn't notice that this part changed.
>>
>> But what's the point, then?  Why are you inventing a brand new PAKE that
doesn't have a security proof?  What benefit do you gain over using a real,
proven PAKE?
>>
>> But you are still reusing the ephemeral keys yourself in the very same
protocol! Suppose Bob *doesn't* know the password but does know a.  (He
*shouldn't*, but still.)  Bob can run most of the protocol anyway by
sending random made-up values and Alice will send u.  Bob can now calculate
what Alice would have sent as u for any given pw value and thus brute-force
the password.
>
>
>   If Bob knows a then Bob knows the private key to Alice's long-term
identity
> key. He can also trivially determine A. So he can impersonate Alice in
TLS/IKEv2
> or any other protocol using a trusted "raw" key for authentication. The
point
> of him attacking PKEX to determine an, essentially, one time use password
is....?

Back up a sec.  A real PAKE is secure if the password is reused because no
party in the entire exchange can brute-force it offline.  There is no
legitimate reason that a new protocol shouldn't provide the same property.

>
>   Granted, this does, I guess, technically violate one of the properties
of PKEX
> (active attack only learns whether one guess of the password was right or
wrong)
> but as an attack is so contrived as to be pointless, as are most
"attacks" that
> begin, "Assuming I have the private key...."
>

Attacks only get worse.

>   I guess I could add some note in the assumptions that private keys are
private
> but I figured that went without saying. Thank you for your comment
though, it may
> result in a change to the draft.

Or you could fix the protocol.

>
>> For this type of protocol, you should be building on real primitives
with provable security, and you should use them as intended so the security
proof works.
>
>
>   It is possible to build something, as you suggest, that approximates
PKEX using
> some other PAKE plus an AEAD scheme plus some PKCS#10 blob but it has its
own
> security critical moving parts. And then you end up with something like
TLS-pwd
> authenticating EST, which is a tad heavyweight and not the kind of PAKE
usage that
> the PAKE requirements draft is referring to; PKEX is.
>
>> >> Step 1: define clearly what you're actually trying to do.  I'll guess
>> >> what you're trying to do: Alice and Bob are devices with keyboards,
>> >> and there's a user (an actual person) who will come up with a
>> >> temporary password to use to pair the devices.  Both devices have
>> >> keyboards.
>> >>
>> >> Step 1: User chooses a password and types it in to both devices.
>> >>
>> >> Step 2: Alice and Bob run a balanced PAKE (DH-EKE, SPAKE2, whatever)
>> >> using that password.  They do this the normal way, using fresh
>> >> ephemeral random numbers as prescribed by the PAKE in use, and they do
>> >> not keep any internal values around that they are supposed to discard.
>> >> The result is a shared secret.  They do this PAKE exchange exactly
>> >> once and they do not retry without explicit input from the user.
>> >
>> >
>> >   Interesting that now "fresh ephemeral random numbers as prescribed
>> > by the PAKE" are eminently believable yet you find such behavior
>> > "really hard to believe" for PKEX.
>> >
>> >
>> >>
>> >> This has the usual balanced PAKE security property: an attacker gets
>> >> exactly one guess with which to try cracking the password, and no
>> >> off-line attack against the password is possible.
>> >>
>> >> Step 3: Alice uses her favorite authenticated encryption protocol,
>> >> keyed by the shared secret, to send Bob her public key.  Bob now knows
>> >> that whoever sent this key knows the password or got extremely lucky
>> >> on their one and only chance to guess the password.
>> >
>> >
>> >   And this provides absolutely no proof-of-possession. Bob got a public
>> > key and he knows that Alice sent it to him but there is nothing that
>> > Alice does to prove that she holds the corresponding private key.
>>
>> Did you read the very next sentence of my email?
>
>
>   Yes. Merely signing your public key does not provide proof of ownership.
> To demonstrate ownership you need to additionally sign something that
binds
> your statement to the authenticated state already established (which is
what
> PKEX does). It's tricky to do right and you don't seem to understand that
> which demonstrates the kind of dangerous hubris you seem to be accusing me
> of having.

Of course it's tricky.  You need to define what exactly you're trying to
prove and then prove that.  If you want to prove that whoever did the PAKE
knew the private key at the time (or colluded with someone who knew the
private key), then derive a fresh key from the PAKE output and sign that.
But see the next email I'll send on this particular topic.

Your draft doesn't precisely state what security goals it actually tries to
achieve, so it's quite awkward to try to decide what exactly Bob should
believe at the end of the protocol run.

>
>   So you could perhaps build something that, if done right, did what PKEX
does
> but uses 3+ different crypto tools each with its own set of assumptions
that
> you better make sure you operate inside. Or you could just do PKEX.
>
>   Thank you again for your comment and suggestion.
>
>   Dan.
>
>
>
>