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

Dan Harkins <dharkins@lounge.org> Tue, 13 September 2016 08:05 UTC

Return-Path: <dharkins@lounge.org>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F54A12B211 for <cfrg@ietfa.amsl.com>; Tue, 13 Sep 2016 01:05:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.202
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XwI5Feq0gPte for <cfrg@ietfa.amsl.com>; Tue, 13 Sep 2016 01:05:46 -0700 (PDT)
Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 7B99E12B11B for <cfrg@irtf.org>; Tue, 13 Sep 2016 01:05:44 -0700 (PDT)
Received: from dhcp-16-207.meeting.verilan.com (unknown [194.247.2.13]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by colo.trepanning.net (Postfix) with ESMTPSA id 94A5210224062; Tue, 13 Sep 2016 01:05:43 -0700 (PDT)
To: Paul Lambert <paul@marvell.com>, "cfrg@irtf.org" <cfrg@irtf.org>
References: <D3FC35C1.9FC94%paul@marvell.com> <56878156-5fdf-9541-f9e2-882ab54a1632@lounge.org> <D3FC63E7.9FF36%paul@marvell.com>
From: Dan Harkins <dharkins@lounge.org>
Message-ID: <8c36f26a-59b4-e483-c1e5-12a083f4b0b0@lounge.org>
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: <D3FC63E7.9FF36%paul@marvell.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/v0DxmRzyAfMTLFiZGu0IHLsoA7Q>
Cc: "Adrangi, Farid" <farid.adrangi@intel.com>
Subject: Re: [Cfrg] Wack-A-Mole and PKEX 3.0 -> Re: Fwd: New Version Notification for draft-harkins-pkex-00.txt
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Tue, 13 Sep 2016 08:05:47 -0000

   Paul,

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.

   Dan.