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

[Andy Lutomirski <[e-mail]>]

On Tue, Aug 30, 2016 at 10:49 PM, Dan Harkins <[e-mail]> wrote:
>
>
> On 8/30/16 5:46 PM, Paul Lambert wrote:
>>>
>>> Section 5.5: Is the PKEX protocol publicly documented anywhere?  I'm
>>> concerned that the crypto here is highly suboptimal.
>>
>> Yes, I¹m not a fan of PKEX in DPP and tried to have it removed. It¹s not
>> been well reviewed, it¹s really hard to review (due to embedding in
>> 802.11) and it¹s just the wrong mechanism (PAKE) for the desired user
>> experience.
>> However,it an interesting design where a PAKE has been extended to provide
>> both peers with authenticated public keys.  The shared passphrase
>> effectively introduces two longer term pubic keys. It¹s a significant
>> design improvement over a typical PAKE that only establishes a shared
>> symmetric key. PKEX should get some review and get used where appropriate
>> or we should be working on similar extensions to PAKEs to authenticate
>> long term public keys.
>>
>> The specification for PKEX is available in two parts:
>> 1) the base SAE protocol is described in IEEE 802.11
>>
>> http://www.ieee802.org/11/private/Draft_Standards/11mc/Draft%20P802.11REVm
>> c_D8.0.pdf
>
>   PKEX has nothing to do with the SAE protocol. And it is not even in the
> draft REVmc document you refer to.
>>
>>         This is a IEEE 802.11 member private site, but I¹ve gotten
>> agreement from
>> the chair that he will provide access to "security researchers²
>>         You¹ll have to contact Adrian Stevens (IEEE 802.11 Chair -
>> [e-mail]) to get the private area password
>> 2) the extension to create PKIX is in IEEE 802.11ai (fragments of text
>> that will later be incorporated into 802.11)
>>         This is also on the private site:
>> http://www.ieee802.org/11/private/index.shtml
>
>   This (802.11ai) is where PKEX is defined.
>>
>> IEEE 802.11 keeps draft specifications private, but the contribution
>> archive is open: https://mentor.ieee.org/802.11/documents
>> You can see some of it¹s structure by looking at:
>> https://mentor.ieee.org/802.11/documents?is_dcn=PKEX
>>
>>
>>> 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.

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?

>>>>
>>>> A well designed short authentication string system (e.g. ZRTP's)
>>>> should have no such issues.
>>
>> Interesting Š yes, a short authentication string is good idea for some
>> user cases (Rich-UI device to Rich-UI device). I¹ll look at it some more Š
>
>   That is exactly the case here. A short authentication string is used to
> bootstrap trust in a peer's public key.
>

Properly designed short authentication strings have very nice security
properties.  An online attacker has a 1/N chance of spoofing an
authentication per actual user interaction.  An offline attacker can't
get anything at all (unless they're willing to brute-force the
underlying high-entropy crypto).  Look at ZRTP for an example.

PKEX, as vaguely described here, doesn't sound like a properly
designed short authentication string.  Sorry.

--Andy