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

[Dan Harkins <[e-mail]>]

On 9/13/16 7:59 AM, Andy Lutomirski wrote:
>
> On Sep 13, 2016 12:39 AM, "Dan Harkins" <[e-mail] 
> <mailto:[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....?

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

   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.

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

   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.