Re: [Cfrg] FW: SPM2 -> was Re: SPAKE2+mbDH a PAKE+PKA

Dan Harkins <dharkins@lounge.org> Fri, 14 October 2016 21:42 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 6254B1294D0 for <cfrg@ietfa.amsl.com>; Fri, 14 Oct 2016 14:42:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.706
X-Spam-Level:
X-Spam-Status: No, score=-0.706 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_SORBS_WEB=3.496, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no 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 RabF9jjm3MAd for <cfrg@ietfa.amsl.com>; Fri, 14 Oct 2016 14:42:11 -0700 (PDT)
Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 00ACC129401 for <cfrg@irtf.org>; Fri, 14 Oct 2016 14:42:10 -0700 (PDT)
Received: from thinny.local (unknown [69.38.252.84]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by colo.trepanning.net (Postfix) with ESMTPSA id 98C961FE01F6 for <cfrg@irtf.org>; Fri, 14 Oct 2016 14:42:10 -0700 (PDT)
To: cfrg@irtf.org
References: <D41831C3.A2964%paul@marvell.com> <CAMr0u6k4U0fsXV2jHxam6Lk0OmmDS1NkV9Z43QF3sjJinW7fPQ@mail.gmail.com> <CAMr0u6ngTf+_eW_qhVz0G_jUNHUqPEMyQO+4A3xrqCh2tRe6FQ@mail.gmail.com> <D418A094.A29E7%paul@marvell.com> <CAMr0u6mUWxjqZbFBriMv8wDnmsWU6g2SBm3vnvOhX=B2rRF3aQ@mail.gmail.com> <D41D5F87.A2EC7%paul@marvell.com> <D41D71D9.A2F6E%paul@marvell.com> <CALCETrVG501pb=JgZ7LAsqWPVnpQ=_wVD7YZ3fM+=YGvtYM8FQ@mail.gmail.com> <D4255871.A3843%paul@marvell.com>
From: Dan Harkins <dharkins@lounge.org>
Message-ID: <f6c87e9a-ccb8-87b4-9f39-a0c16c47a86c@lounge.org>
Date: Fri, 14 Oct 2016 14:42:08 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.3.0
MIME-Version: 1.0
In-Reply-To: <D4255871.A3843%paul@marvell.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/E83c6EAGSuvX-BkqaQt54CPIN3k>
Subject: Re: [Cfrg] FW: SPM2 -> was Re: SPAKE2+mbDH a PAKE+PKA
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: Fri, 14 Oct 2016 21:42:12 -0000

   Hi Paul,

On 10/13/16 4:24 PM, Paul Lambert wrote:
>
> Hi Andy,
>
>>> Œbootstrap¹ public key (exchanged out-of-band, e.g QR code)
>>>     Secret key calculation:
>>>         S = (p_R + b_R) * (p_I + b_I) * G
>>>       = (p_R + b_R) * (P_I + B_I)[by Responder]
>>>     = (p_I + b_I) * (P_R + B_R)               [by Initiator]
>> What's the need for this fanciness?  Why not create a secure channel
>> using your favorite authenticated DH protocol using just the bootstrap
>> keys and then exchange long-term public keys over that channel?
> Yes Š this does become a little silly - especially when you look at the
> end result of all the combined protocols. Specifically for DPP, PKEX is
> always run first and then another 3-step authentication protocol is run to
> exchange the long-term keys.

   Correct me if I'm wrong but isn't PKEX an _optional_ bootstrapping
method of which there are several others? So it's not, necessarily,
always run first. It's just that some bootstrapping technique is run
to obtain some modicum of trust in the bootstrapped keys and *then*
those keys are used in DPP to do authentication.

>> This
>> all seems to be doing something like Signal's [or whatever it's called
>> these days] "triple DH" protocol, except that triple DH uses genuinely
>> unauthenticated ephemeral points and triple DH hashes everything
>> together instead of using EC addition.
> Yes, the EC addition trick is bad. The Triple DH looks like one
> alternative for the simultaneous demonstration of ownership of two keys.
>
> On this type of integration of authenticated DH and a PAKE, it makes more
> sense to me to put an optional PAKE ³inside" a authenticated DH exchange.
>
> This way you get:
>   - an ephemeral key exchange
>   - the long-term keys encrypted under the ephemeral key (privacy from
> third party observation)

   Except that sending a "long-term key" encrypted using a key derived from
an unauthenticated exchange of ephemeral keys buys you nothing. These
"long-term keys" are public after all and anyone can encrypt anyone else's
public key by the result of another unauthenticated Diffie-Hellman. Are
there any useful properties to such an exchange? I can't see them.

>   - a PAKE optionally within the encrypted exchange

   Why do "an optional PAKE 'inside' an authenticated DH exchange"? If
the DH is authenticated then the PAKE buys you nothing. Anything that
calls itself a PAKE should not need to be run "inside" an authenticated
channel.

>   - the ability to securely exchange info related to the PAKE identities
> and process
>
> For:
>      R_A and R_B are ephemeral public keys
>
>      {} indicting AEAD encryption with key derived from ephemeral exchange
>      P_A and P_B are long-term keys
>      ... Ellipsis indicate protecte fields outside the scope of this
> discussion
>      [x] brackets indicate an optional field
>
>
>      R_A --->
>      <--- R_B, { (proof, P_B) ... }
>      { (proof, P_A) ... } --->
>
>      <--- { ... }
>
>
> Here I¹m ignoring the math to better discuss the structure of the protocol.
> The Œproof¹ would be some technique (like the Triple DH) to strongly
> demonstrate the joint ownership of the ephemeral

   But "the math" is crucial, you can't ignore it. You do AEAD encryption
"with key derived from ephemeral exchange"... of what? "proof" is proof
of what? If it's just of knowledge of the private analogs to R_A and R_B
then you don't get authentication since R_A and R_B are ephemeral.

>
> This has some interesting properties if you make the long-term key and
> proof optional:
>
>      R_A --->
>      <--- R_B, {[(proof, P_B)] ... }
>      {[(proof, P_A)] ... } --->
>      <--- { ... }

   Only if an unauthenticated Diffie-Hellman has "interesting properties".
I don't think it does. Key agreement is not authentication. And if you
exclude the long-term keys and whatever "proof" is then you have an
unauthenticated Diffie-Hellman.

> The same exchange would then support one-sided, mutual or no
> authentication to a long-term key.
> The protocol could support some negotiation of which device goes first
> exposing their long-term key.
>
>      R_A --->
>      <--- R_B, { Œyou first' ... }
>      { (proof, P_A) ... } --->
>      <--- { (proof, P_B) ... }
>
> If there is a need to bind this exchange to human validation of a string
> it could be extended to support a SAS and associated human interaction:
>
>
>      R_A --->
>      <--- R_B, {[(proof, P_B)] ... }
> Display SAS
>      {[(proof, P_A)] ... } --->
>                              Display SAS
>      <--- { ... }
> Confirm

   Without an explanation of what "proof" means and what "{...}"
is performed with then this is just a bunch of hand-waving.

>
> Integration of a PAKE would look like:
>      R_A --->
>      <--- R_B, {(proof, P_B), pake_m1  ... }
>      {(proof, P_A), pake_m2 ... } --->
>      <‹ {pake_m3 ... }
>
> First, I proposing that any PAKE should be able to be mapped into three
> messages: pkae_1, pake_2 and pake_3
>
> So ...one protocol structure could support multiple types of
> authentication (none/owe, one-sided, mutual) and provide optional support
> for short authentication strings or user input passphrases.

   Requiring an authenticated key exchange to conform to the message
requirements of a different protocol seems bassackwards.
>
>> I guess what I'm really asking, though, is: what's the point of having
>> separate bootstrap and long-term keys?
> For an in-line exchange there is no benefit.
>
> If you look at how a static QR code might contain a key it becomes more
> complicated and this printed key might be called a "bootstrap key² if it
> is not the long-term key.

   Are you saying that "bootstrap key" cannot be "long-term key"? Is that
part of DPP?
>
> On this type of bootstrapping, there are several different use cases with
> very different requirements:
>   - a static unchanging key associated directly with a device
>     (a QR code printed on a device where the QR code data is associated
> with a long-term key)
>   - a dynamic key that is used once to introduce devices
>     (e.g. A one-time QR code displayed on a TV screen where the QR code
> data is associated with a long-term key)
>
> Given the above, and working to avoid the term Œbootstrap¹, there are
> three types of public keys required:
>   - ephemeral keys that are used only once
>   - long-term identity keys that are used for access control and
> authorization
>   - long-term hardware keys that are bound to a physical device
>
> The latter two key types should not be the same key for most consumer
> devices. The hardware oriented key is fixed and not reset when devices are
> reset. An Œidentity¹ key should be reset as it is used by other systems to
> determine access control and authorization decisions.
>
> This implies that devices may need to support and demonstrate ownership of
> multiple long-term keys. For example:
>
>      R_A --->
>      <--- R_B, { (proof, P_B), (proof, P_hw_B) ... }
>      { (proof, P_A), (proof, P_hw_A) ... } --->
>      <--- { Š }

   Now the intricacies of the math compound due to you sending multiple
public keys under protection of... well not sure. It's impossible to
analyze this.

   regards,

   Dan.