[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 20:00 UTC

Return-Path: <paul@marvell.com>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 8153812B100 for <cfrg@ietfa.amsl.com>; Mon, 12 Sep 2016 13:00:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
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 ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id LulPWkQLKzJb for <cfrg@ietfa.amsl.com>; Mon, 12 Sep 2016 12:59:59 -0700 (PDT)
Received: from mx0b-0016f401.pphosted.com (mx0a-0016f401.pphosted.com []) (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 022AC12B0E0 for <cfrg@irtf.org>; Mon, 12 Sep 2016 12:59:58 -0700 (PDT)
Received: from pps.filterd (m0045849.ppops.net []) by mx0a-0016f401.pphosted.com ( with SMTP id u8CJxr7L024807; Mon, 12 Sep 2016 12:59:56 -0700
Received: from sc-exch03.marvell.com ([]) by mx0a-0016f401.pphosted.com with ESMTP id 25cfhp2v3s-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 12 Sep 2016 12:59:41 -0700
Received: from SC-EXCH03.marvell.com ( by SC-EXCH03.marvell.com ( with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 12 Sep 2016 12:59:40 -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 12:59:40 -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: AQHSDTAynxZ/BpmgNESRosCNDlMtMA==
Date: Mon, 12 Sep 2016 19:59:39 +0000
Message-ID: <D3FC35C1.9FC94%paul@marvell.com>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <50A066820CDB19478FE2AC86DD8CE669@marvell.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-09-12_10:, , signatures=0
X-Proofpoint-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1609020000 definitions=main-1609120307
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/puDOeXRX2rfe41fcs7JwrjfO2ko>
Cc: "Adrangi, Farid" <farid.adrangi@intel.com>
Subject: [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 20:00:00 -0000

>Name:		draft-harkins-pkex
>Revision:	00
>Title:		PKEX
>Document date:	2016-09-12
>Group:		Individual Submission
>Pages:		9

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:

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
        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.
   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).
     As shown in slide 8 of:
     the use of MAC addresses is problematic because they can readily be
    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 binding of this type of protocol to a network address prevents
usage in tunneling, proxy applications where the
    external visible address may change (e.g. IPsec and NAT)
3) PKEX ŒEncryption¹ and public key transport
          PKEX 2.0:
            a, A = a*G (long term)          b, B = b*G (longterm)
            Qi = H(Alice)*Pwe                Qr = H(Bob)*Pwe
            M = A + Qa                       N = B + Qr

             The M=A+Qa term was a major aspect of dictionary and MiTM

          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
            u=f(a,Y,M,N,A,Y,pw,X,Y)         v=f(b,X,N,M,B,X,pw,Y,X)

            R = A + Z                       T= B + Z



        This is a significant change and may be an improvement in
security. Hard to tell yet.
        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
   ??? Not sure what a Œstated identity¹ means or how it is useful.
   What is the next protocol, how does this work as a system.

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.

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