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

Paul Lambert <paul@marvell.com> Tue, 13 September 2016 15:03 UTC

Return-Path: <paul@marvell.com>
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 3FADE12B610 for <cfrg@ietfa.amsl.com>; Tue, 13 Sep 2016 08:03:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 fYB6iAGZmfdw for <cfrg@ietfa.amsl.com>; Tue, 13 Sep 2016 08:03:49 -0700 (PDT)
Received: from mx0b-0016f401.pphosted.com (mx0b-0016f401.pphosted.com [67.231.156.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38DE412B7AF for <cfrg@irtf.org>; Tue, 13 Sep 2016 07:36:59 -0700 (PDT)
Received: from pps.filterd (m0045851.ppops.net [127.0.0.1]) by mx0b-0016f401.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id u8DEZAmv013407; Tue, 13 Sep 2016 07:36:55 -0700
Received: from sc-exch02.marvell.com ([199.233.58.182]) by mx0b-0016f401.pphosted.com with ESMTP id 25chpn0m3a-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 13 Sep 2016 07:36:52 -0700
Received: from SC-EXCH03.marvell.com (10.93.176.83) by SC-EXCH02.marvell.com (10.93.176.82) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 13 Sep 2016 07:36:51 -0700
Received: from SC-EXCH03.marvell.com ([fe80::6cb0:4dfa:f3f3:b8b6]) by SC-EXCH03.marvell.com ([fe80::6cb0:4dfa:f3f3:b8b6%21]) with mapi id 15.00.1104.000; Tue, 13 Sep 2016 07:36:51 -0700
From: Paul Lambert <paul@marvell.com>
To: Dan Harkins <dharkins@lounge.org>, "cfrg@irtf.org" <cfrg@irtf.org>
Thread-Topic: Wack-A-Mole and PKEX 3.0 -> Re: [Cfrg] Fwd: New Version Notification for draft-harkins-pkex-00.txt
Thread-Index: AQHSDTZM0qIxVLUEk0KxYsqHJEGP/qB2ZsaAgAEfZAD///fugA==
Date: Tue, 13 Sep 2016 14:36:51 +0000
Message-ID: <D3FD4294.A005A%paul@marvell.com>
References: <D3FC35C1.9FC94%paul@marvell.com> <56878156-5fdf-9541-f9e2-882ab54a1632@lounge.org> <D3FC63E7.9FF36%paul@marvell.com> <8c36f26a-59b4-e483-c1e5-12a083f4b0b0@lounge.org>
In-Reply-To: <8c36f26a-59b4-e483-c1e5-12a083f4b0b0@lounge.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.6.5.160527
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.94.250.30]
Content-Type: text/plain; charset="utf-8"
Content-ID: <71F4AEE8420F184F81639A3B3FB55754@marvell.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-09-13_09:, , signatures=0
X-Proofpoint-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1609020000 definitions=main-1609130215
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/NsAv3UsFEPbok58KIip5H-ke2ig>
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 15:03:54 -0000



Dan,

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

A useful protocol is designed for a purpose and has requirements and
constraints based on it’s intended application.

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

The discussion of PKEX 2.0 started on this list as part of a review and
discussions of the WI-Fi Alliance DPP protocol.

PKEX 2.0 was defined in IEEE 802.11ai, and referenced by the Wi-FI
Alliance DPP project (aka replacement for WPS).

PKEX 2.0 was removed today from IEEE specification given the identified
issues.
	https://mentor.ieee.org/802.11/dcn/16/11-16-1142-01-00ai-cryptographic-rev
iew-and-pkex.ppt

PKEX 3.0 now appears as a IETF draft.

PKEX 3.0 is an improvement over PKEX 2.0 … but you may want to add some
acknowledgements to this new RFC that others contributed to your better
understanding of the limitations of PKEX 2.0 to create the current draft.


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

No, you mentioned above that PKEX could be used for TLS or IKEv2. PKEX 1.0
was developed in IEEE 802.11ai for Wi-Fi communications.

PKEX 2.0 is deeply embedded into the WI-FI Alliance program to replace
WPS. PKEX 3.0 maintains the same usage model as PKEX 2.0


With enough tries … PKEX 3.0 or PKEX n.0 could be deemed secure. Including
the validated exchange of public keys in a PAKE exchange is a very
interesting mechanism. Usage constraints of such a protocol still may make
it inappropriate for particular applications.

Given the target usage of the protocol it’s security and system
applicability are both critical topics.

> I'm just asking for a review of a PAKE exchange
>in an I-D.

PKEX is NOT quite a PAKE. The protocol as defined does not provide ‘key
establishment’. A shared key is developed, but then not used.  This could
be changed easily.  This odd definition is based on your system
perspective that PKEX fits within a suite of modular protocol exchanges.
This sounds nice, but this creates some unusual interfaces and many extra
message exchanges. (Constructive Comment #3 make PKEX a PAKE)

Given that shared keys are established and PKEX 3.1 is a PAKE, it’s worth
consideration as a new “PAKE+" class of exchange that establishes a shared
key and exchanges authenticated public keys

If you keep the current modularity where the is no maintained shared
secret, it’s a new animal … a password authenticated public key protocol
(PAPK or whatever).

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

This mailing list was invited to review the Wi-Fi Alliance DPP
specification:

	https://www.wi-fi.org/download.php?file=/sites/default/files/private/Wi-Fi
_DPP_Tech_Spec_v0_0_23.pdf

DPP Page 27:
  "Step 1: Bootstrapping of trust
  The public keys of the devices are transferred from one device to
another. This
  places a trust that the public key belongs to the peer device. This can
be performed
  using either the Out-of-Band (OOB) mechanism for devices with limited
capability or
  using in-band bootstrapping (PKEX frames) for devices which have a user
interface.”

DPP Page 27:
						
					
  "This bootstrapping technique should never be run multiple times with the
same code. 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.
The PKEX protocol (from section 11.6.12 of published version of Draft
P802.11ai) is used to
establish trust in a peer’s bootstrapping key, and correspondingly allow
the peer to establish
trust in the device’s bootstrapping key, using a shared code."


				
			
		
	
PKEX imposes a shared one-time secret as a means to ‘setup’ two devices
with rich user interfaces.
This is a suboptimal design and goes against most notions of good user
experience.

PKEX might be interesting for other use cases



Paul




>
>   Dan.
>
>
>
>
>