Re: [Cfrg] Wack-A-Mole and PKEX 3.0 -> Re: Fwd: New Version Notification for draft-harkins-pkex-00.txt

Dan Harkins <> Tue, 13 September 2016 08:05 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9F54A12B211 for <>; Tue, 13 Sep 2016 01:05:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.202
X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id XwI5Feq0gPte for <>; Tue, 13 Sep 2016 01:05:46 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 7B99E12B11B for <>; Tue, 13 Sep 2016 01:05:44 -0700 (PDT)
Received: from (unknown []) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 94A5210224062; Tue, 13 Sep 2016 01:05:43 -0700 (PDT)
To: Paul Lambert <>, "" <>
References: <> <> <>
From: Dan Harkins <>
Message-ID: <>
Date: Tue, 13 Sep 2016 01:05:42 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <>
Cc: "Adrangi, Farid" <>
Subject: Re: [Cfrg] Wack-A-Mole and PKEX 3.0 -> Re: Fwd: New Version Notification for draft-harkins-pkex-00.txt
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Crypto Forum Research Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 13 Sep 2016 08:05:47 -0000


On 9/12/16 2:57 PM, Paul Lambert wrote:
>>    They are identities, not mac addresses. Authentication requires some
>> identity to authenticate so to use a public key for authentication in some
>> protocol like TLS or IKEv2 requires that the public key be bound to an
>> identity.
> Ok … but the reason you are proposing this PKEX 3.0 is to replace PKEX 1.0
> used in the Wi-Fi Alliance program to replace Wi-FI Protected Setup (WPS).
> You specifically are using MAC addresses in this context for ‘identity’.

   I asked for a review of the protocol. Whatever reasons for writing 
the I-D
I have are not relevant to the security of the protocol. This is not Wi-Fi
Protected Setup and it's not a Wi-Fi Alliance program. It's the Crypto
Forum Research Group of the Internet Research Task Force.
> Also - if your goal is to start with raw keys, the key is a form of
> identity and knowledge of a peer’s ownership of a particular key are
> adequate for useful access control decisions. Other attributes of a key
> (besides it’s value and ownership) are best exchanged and validated after
> authentication and key setup.

   Yes, you need to have knowledge of a peer's ownership of a particular
key. And you need something like PKEX to obtain that knowledge. You
can't, for example, just do a Diffie-Hellman key exchange and then infer
anything about peer ownership of the public key received in the exchange
for the simple reason that it is not an authenticated exchange.

   There's a chicken-and-egg issue here. You want to do an authenticated
Diffie-Hellman and infer some ownership of the public key used. But how
do you authenticate the Diffie-Hellman in order to justify your inference
of ownership? You don't get authentication out of whole cloth.

   PKEX allows you to obtain trust that a public key actually does belong
to a particular identity, and that kind of trust is _essential_ if the
key is going to be used for any other protocol that uses such "raw"
public keys for authentication.

>>>       If the goal of this protocol is to exchange Œraw¹ publc keys there
>>> should not be a requirement
>>>       to strt with a known identity.
>>    The goal is to exchange public keys that will be suitable for use in
>> an authentication protocol like TLS or IKEv2. If there is no identity
>> bound
>> to the public key (as in a certificate) then what you get is
>> "authentication"
>> and not authentication.
> ?? I think you are throwing up a smoke screen. The thread on PKEX started
> as a review of one piece of the Wi-Fi Alliance DPP protocol. Right now the
> way DPP seems to work if I wish to establish a P2P connection is:
> 1) 6 messages for PKEX
> 2) 2 messages for “DPP Authentication” (normally three, but PKEX used as
> bootstrap)
> 3) 2 messages exchanged for configuration
> 4) 2 messages for DPP Connector Exchange
> 5) 4 messages for 802.11 4-way key setup
> This is 16 messages to setup a P2P connection.
> I believe we need to be discussing "the whole fish and not just the fish
> nose.”

   Now this is a smokescreen. I never said anything about P2P or DPP
or 4-way key set up. I'm just asking for a review of a PAKE exchange
in an I-D.

> I’m done reviewing PKEX 3.0.  Lacking any clear articulation of protocol
> requirements or overall system functionality the PKEX 3.0 protocol is
> irrelevant. PKEX 3.0 is not appropriate for inclusion into IEEE 802.11 or
> inclusion into the WI-FI Alliance program for the Device Provisioning
> Protocol (DPP).

   Done? You never reviewed it!

   I would greatly appreciate a review of the protocol itself and not a
soliloquy on it's appropriateness for some program of a secretive
organization (Wi-Fi Alliance) that requires NDAs to see what it's doing.