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> Mon, 12 September 2016 21:57 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 81C1612B13B for <cfrg@ietfa.amsl.com>; Mon, 12 Sep 2016 14:57:12 -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 IPGRE8oh6_Yg for <cfrg@ietfa.amsl.com>; Mon, 12 Sep 2016 14:57:10 -0700 (PDT)
Received: from mx0b-0016f401.pphosted.com (mx0a-0016f401.pphosted.com [67.231.148.174]) (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 1F9D312B0BB for <cfrg@irtf.org>; Mon, 12 Sep 2016 14:57:10 -0700 (PDT)
Received: from pps.filterd (m0045849.ppops.net [127.0.0.1]) by mx0a-0016f401.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id u8CLnvfv027625; Mon, 12 Sep 2016 14:57:08 -0700
Received: from sc-exch04.marvell.com ([199.233.58.184]) by mx0a-0016f401.pphosted.com with ESMTP id 25cfhp3e2q-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 12 Sep 2016 14:57:07 -0700
Received: from SC-EXCH03.marvell.com (10.93.176.83) by SC-EXCH04.marvell.com (10.93.176.84) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 12 Sep 2016 14:57:06 -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; Mon, 12 Sep 2016 14:57:06 -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/qB2ZsaA
Date: Mon, 12 Sep 2016 21:57:06 +0000
Message-ID: <D3FC63E7.9FF36%paul@marvell.com>
References: <D3FC35C1.9FC94%paul@marvell.com> <56878156-5fdf-9541-f9e2-882ab54a1632@lounge.org>
In-Reply-To: <56878156-5fdf-9541-f9e2-882ab54a1632@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: <B7F030E4A74BB444BC70ECE05E5FCF82@marvell.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-09-12_12:, , 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-1609120325
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/JeAsBmUf20zydPNLFORyFfagiH4>
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: Mon, 12 Sep 2016 21:57:12 -0000

Dan,

>
>On 9/12/16 12:59 PM, Paul Lambert wrote:
>>
>> Dan,
>>> Name:		draft-harkins-pkex
>>> Revision:	00
>>> Title:		PKEX
>>> Document date:	2016-09-12
>>> Group:		Individual Submission
>>> Pages:		9
>>> URL:
>>> https://www.ietf.org/internet-drafts/draft-harkins-pkex-00.txt
>>>
>> To prevent confusion on the nature and functionality it might be better
>>to
>> call this protocol PKEX 3.0.
>>
>> The PKEX 2.0 was already the subject of discussion on this list. I am
>> encouraged to see that you acknowledge that PKEX 2.0 had some issues
>>that
>> included a MiTM attack. This attack is documented in:
>> 
>>	https://mentor.ieee.org/802.11/dcn/16/11-16-1142-01-00ai-cryptographic-r
>>ev
>> iew-and-pkex.ppt
>>
>>
>> Comments on PKEX 3.0:
>>
>> 1) Qi term and Hunt-and-Peck
>>          PKEX 2.0:  Qi = H(Alice)*Pwe
>>                       Where Pwe = dhp(pw)    dhp() is dragonfly
>> hunt-and-peck
>>          PKEX 3.0: Qi = H(Alice|pw)*Pi
>>                        Where Pi might be dhp(pw) or role specific fixed
>>     For PKEX 3.0, I do not see how you can make the Pi and Pr terms be
>> unique if you use hunt-and-peck.
>
>   Well it's actually the same way that the fixed elements get
>fixed for SPAKE2. The requirement is that the discrete logarithm
>not be known and hunting-and-pecking based on an input string will
>give you that. I suggest you look at SPAKE2 on how it generates
>the fixed elements that it requires.

Yes, I am very familiar with SPAKE2. It uses two unique fixed points that
stay the same for every protocol run.

The Dragonfly Hunt-and-Peck is designed to run on every new passphrase and
includes protection for side channel attacks that are not required for a
fixed value. 

The reference to Dragonfly is gratuitous and the specification would be
better served simply referencing the points and/or process in SPAKE2.

>
>>     Putting the Œpw¹ into the scalar versus a ECC point is more
>>efficient
>> and is an improvement
>> 2) Qi term and identity
>>          PKEX 3.0: Qi = H(Alice|pw)*Pi
>>       The use of ŒAlice¹ is problematic.  There is no indication in this
>> write-up how Bob learns
>>       ŒAlice¹ or Alice learns to identify Bob as ŒBob¹
>>       In your IEEE submissions for PKEX 2.0, Alice and Bob are
>>identified
>> as MAC addresses (mac_a and mac_b).
>
>   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’.

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.


>How they learn each others identities to bind to the exchanged
>public keys is not germane to the exchange.

I disagree fundamentally. We need useful protocols that consider the
system implications of their application in real world environments. While
it’s convenient to create a modular design. The function of all of the
modules needs to be described.

This protocol already assumes that Alice knows the string or octets (
‘Alice’ )that are the identity of it’s peer Alice. If this is a Wi-Fi
device, what is this identity and how is it used?

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



>>            PKEX 3.0:
>>              a, A = a*G (long term)         b, B = b*G (longterm)
>>              x, X = x*G  (ephemeral)        y, Y = y*G (ephemeral)
>>              Qi = H(Alice|pw)*Pi            Qr = H(Bob|pw)*Pr
>>              M = X + Qa                     N = Y + Qr
>>              --->M
>>                                              N<---
>>              u=f(a,Y,M,N,A,Y,pw,X,Y)         v=f(b,X,N,M,B,X,pw,Y,X)
>>              --->u
>>                                              v<---
>>
>>              R = A + Z                       T= B + Z
>>              --->R
>>
>>                                              T<---
>>
>>       
>>          This is a significant change and may be an improvement in
>> security. Hard to tell yet.
>
>   That is the question I am asking. So?
>>          The protocol has gone from a 4-step to 6-step protocol. Seems
>>like
>> 4-steps should be enough ...
>>
>> 4) How is PKEX used?
>>     "At this point, if the parties didn't fail they have each other's
>>     public key and trust that it belongs to the peer's stated identlty.
>>     They can use the public key in another protocol to authenticate that
>>     identity.²
>>     ??? Not sure what a Œstated identity¹ means or how it is useful.
>>     What is the next protocol, how does this work as a system.
>
>   This is a cryptographic protocol and I am asking for cryptographic
>review of it. How it fits into a system is not relevant to the protocol
>or whether it is secure or not.

Why bother reviewing the security if the properties of the protocol are
not what is required.

I see no reason to pursue review of any protocol without clear
requirements and ideas on it’s application.


>>
>> 5) PKEX is not a key establishment protocol
>>     PKEX  generates and then throws away a pair-wise unique key pair.
>>     Seems like this class of exchange should also provide such key
>>material.
>
>   The goals and properties of the protocol are stated in the document.

Yes … you have in your mind the subsequent use of another two protocols
that are not described as part of this document to provide a “full” set of
security services.

PKEX goes to some length to not expose the long-term public keys.  This is
a good thing, but then later in DPP the “DPP Connector Exchange” directly
exposes these long-term values losing any privacy services you were trying
for with PKEX 3.0

So … no, the goals of the protocol are adequately stated in this document.

>
>> 6) is the goal to be a PAKE plus authenticated public keys (PAKE+Auth)?
>>     If so, clarity on the use of the derived pair-wise key would be
>>useful.
>>     More interesting is if a PAKE is the right base mechanism to
>> Œintroduce¹ public keys.
>
>   There are no derived pair-wise keys to provide clarity on.

This was constructive evaluation from a system perspective. You should be
able to significantly reduce the number of messages exchanged and greatly
improve the overall efficiency of the system solution.


>>     Short authentication strings (SAS) were brought up in the PKEX 2.0
>> discussions and might be
>>     a interesting line of pursuit for a useful protocol.
>>
>>
>> The extension of a PAKE (like SPAKE) to carry long-term public keys is
>>one
>> possible design path.  For PKEX 4.0 9IMHO) a more generically useful
>> exchange could be built using a SIGMA-I type authenticated DH exchange.
>> The proof of holding the passphrase could be carried within the
>>encrypted
>> portions of the authentication exchange. Such a SIGMA based design could
>> also readily be tweaked to generate a SAS. Seems like the same protocol
>> could be used to optionally support OWE-like requirements.
>>
>> Hope these comments are useful ...
>
>Sadly no, not really. They are not about the protocol but, instead, about
>incorrect assumptions on what identities are and irrelevant things about
>how
>this protocol fits into some larger system or about other protocols that
>Have

If you feel that the way the protocol fits into a system is irrelevant,
then the protocol itself is irrelevant.

>nothing to do with this (OWE? Huh?).

> 
Yes it does … ideally we would not be partitioning our protocols so that
each new use case is a new protocol.  Yes, I know you don’t share this
perspective.

>If you have any comments on this
>protocol
>in this draft I would like to hear them.

They were given but not heard.

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


Paul