Re: [Cfrg] Wi-Fi Alliance Device Provisioning Protocol (DPP) - Draft Released for Public Review and Comments

[Dan Harkins <[e-mail]>]

On 8/31/16 1:34 PM, Andy Lutomirski wrote:
> On Wed, Aug 31, 2016 at 1:12 PM, Dan Harkins <[e-mail]> wrote:
>>
>> On 8/31/16 12:25 PM, Andy Lutomirski wrote:
>>> On Tue, Aug 30, 2016 at 10:49 PM, Dan Harkins <[e-mail]> wrote:
>>>>
>>>>>> For example, the
>>>>>> text mentions that:
>>>>>>
>>>>>>> Using this bootstrapping technique more than once with a different
>>>>>>> code
>>>>>>> but the same bootstrapping key can enable a dictionary attack (to
>>>>>>> recover the code) by the entity that obtained the bootstrapping key
>>>>>>> the
>>>>>>> first time.
>>>>     Think of EKE, a password is used to encrypt a public key to peer1. Now
>>>> some
>>>> time later the same public key is sent to peer2 using a different
>>>> password.
>>>> In this case peer1 would be able to do an off-line dictionary attack to
>>>> recover
>>>> the password used in the exchange to peer2. That's what is intended by
>>>> the
>>>> text
>>>> in question.
>>> If by EKE you mean DH-EKE, then I think this just means you're doing
>>> EKE wrong.  For DH-EKE (which is actually secure), you send a brand
>>> new share every time.  Given my very, very limited understanding of
>>> what is proposed here (since I haven't gone and asked the editors for
>>> all the relevant documents), the protocol being used doesn't really
>>> achieve anything useful.
>>
>> Yes, you use a fresh share every time with EKE because the derived
>> session key is the important thing, you're doing a key exchange protocol
>> to derive a secure, shared session key. That's not the case with PKEX.
>> In PKEX the important thing is the decrypted public key, any derived
>> session key is discarded. So reusing the public key would result in
>> the issue that the text addresses.
> Then at the very least why not do real PAKE (DH-EKE or whatever) and
> then exchange public keys over the resulting secure channel?  ISTM the
> spec is inventing a new protocol that's strictly worse than the
> standard protocols out there.

   Doing DH-EKE and exchanging public keys in the resulting secure channel
would not provide proof of possession of the exchanged public keys. And it
would also double the amount of crypto for no apparent benefit.

   Can you please explain how it is "strictly worse" than the standard
protocols out there?

>>> But from reading the draft DPP document, I can't even tell what the
>>> workflow is.  Who generates a password, who types it where, and who
>>> sends what?
>>>
>>> And can someone explain what security properties the protocol is
>>> trying to achieve?
>>
>> It was added to 802.11ai to enable raw public keys to be used for
>> authentication in the 802.11ai protocol. Usually raw public keys are
>> exchanged "in a manner outside the scope of the standard" but that's
>> kind of a cop out. So PKEX was added to allow for 2 parties to exchange
>> raw public keys in a manner that would provide some modicum of trust
>> to the received public key. Each device will get the peer's public key
>> in a manner that guarantees the integrity of the received key, with
>> proof of possession of the private key, from a someone who knows the
>> shared password. Presuming no one else knows the shared password then
>> you know who's public key you just received and you know to whom
>> you just gave your public key.
> This doesn't answer the question.  What's the workflow?  Do I, as the
> user, make up an arbitrary password and type it in to both devices?
> Do I, as a user, read a password generated by one device and type it
> in to the other?  I'm pretty sure that, for any of these variants,
> there exist much more secure protocols.  If you further clarify the
> workflow, I'm sure I can name a better protocol, and the folks lurking
> here who are good at provable security can probably come up with a
> straightforwardly provably secure protocol for a far stronger notion
> of security than you're providing.

   The workflow could be either of those. Or it could be: I see you
in person and we want to enable our devices to securely communicate
using DPP so we each enter some short code on our devices and they
do PKEX.

   What is the security flaw in PKEX that makes other protocols "much
more secure"?
>
> The 802.11 folks already screwed up WPA Personal by failing to use a
> real PAKE for silly reasons.  Please don't screw up DPP as well.

   SAE is the PAKE in 802.11. But as I said to Paul, PKEX is not SAE.

   I would like to understand what you mean by "screw up DPP as well."
How is DPP being screwed up by the inclusion of PKEX?
>>    The properties listed in in the 802.11ai amendment for PKEX are:
>>
>>    - the protocol will result in the exchange of trusted public
>>      keys or it will fail;
>>    - a passive adversary is unable to subvert the exchange, insert
>>      any different public keys, learn the public keys, or learn the
>>      key/code/word/phrase shared by the two peers;
>>    - an active adversary that does not know the shared key/code/word/
>>      phrase cannot successfully complete the exchange; and,
>>    - an attacker is not able to perform an off-line dictionary attack
>>      against PKEX in order to determine wither the public keys or
>>      determine the shared key/code/word/phrase.
> You aren't actually providing this last property AFAICT.

   Why not? If you mean that reusing the same public key with a different
key/code/word/phrase then see the quote at the top of this email that
started this thread. That is an acknowledged security consideration already.

   Please explain how the _protocol_ itself is not providing this property
because it's not clear to me what you mean.

   Dan.