Re: [Hipsec] replacing DH in HIP

Dmitriy Kuptsov <dmitriy.kuptsov@hiit.fi> Thu, 18 March 2010 10:06 UTC

Return-Path: <dmitriy.kuptsov@hiit.fi>
X-Original-To: hipsec@core3.amsl.com
Delivered-To: hipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 417CD3A6B5D for <hipsec@core3.amsl.com>; Thu, 18 Mar 2010 03:06:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 3.285
X-Spam-Level: ***
X-Spam-Status: No, score=3.285 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, FRT_BELOW2=2.154]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s8JLxMSlOqKm for <hipsec@core3.amsl.com>; Thu, 18 Mar 2010 03:06:18 -0700 (PDT)
Received: from argo.otaverkko.fi (argo.otaverkko.fi [212.68.0.2]) by core3.amsl.com (Postfix) with ESMTP id 0F9153A6849 for <hipsec@ietf.org>; Thu, 18 Mar 2010 03:06:18 -0700 (PDT)
Received: from [193.167.187.116] (ip116.infrahip.net [193.167.187.116]) by argo.otaverkko.fi (Postfix) with ESMTP id B949225ED10; Thu, 18 Mar 2010 12:06:28 +0200 (EET)
From: Dmitriy Kuptsov <dmitriy.kuptsov@hiit.fi>
To: Tobias Heer <heer@cs.rwth-aachen.de>
In-Reply-To: <C203E2BC-250E-49C3-8983-EE68E75F5D31@cs.rwth-aachen.de>
References: <1268332644.4b993864212f8@webmail.otaverkko.fi> <C203E2BC-250E-49C3-8983-EE68E75F5D31@cs.rwth-aachen.de>
Content-Type: text/plain; charset="UTF-8"
Organization: HIIT, TKK
Date: Thu, 18 Mar 2010 12:06:19 +0200
Message-ID: <1268906779.4208.87.camel@dmitriy-desktop.hiit.fi>
Mime-Version: 1.0
X-Mailer: Evolution 2.28.1
Content-Transfer-Encoding: 7bit
Cc: hipsec@ietf.org
Subject: Re: [Hipsec] replacing DH in HIP
X-BeenThere: hipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: dmitriy.kuptsov@hiit.fi
List-Id: "This is the official IETF Mailing List for the HIP Working Group." <hipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/hipsec>, <mailto:hipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/hipsec>
List-Post: <mailto:hipsec@ietf.org>
List-Help: <mailto:hipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/hipsec>, <mailto:hipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 18 Mar 2010 10:06:19 -0000

Hi Tobias,

On Tue, 2010-03-16 at 12:31 +0100, Tobias Heer wrote:
> 
> Don't get me wrong: the reason I am asking is not to oppose your approach. I just want to understand it better. In general I appreciate all efforts of speeding up HIP and of extending its scope.
> 

I apologies for being somewhat awkward. 

So the whole process of "optimized" secret key negotiation for
lightweight sensors can look as follows:

1. Each node (similar as what it is in current HIP) have they
public-private key pair (this can be a self-generated or generated and
signed by TTP -  a network operator, depending whether the network
should be an open or closed group). I am not sure whether HITs should
play some other role other than identifiers (in a context of sensor
network), but lets not concentrate on this right now.

2. The goal is for any given 2 nodes (no matter whether they are just 1
hop or several hops away) in the network to establish (or update) a
secret session key in more "lightweight" manner as compared to DH which
is used currently in HIP.

3. To do so, the initiator sends an I1 packet containing common HIP
header, as well as it also sends its public key (corresponding to its
HIT) in a form of HostID parameter. 

4. The responder constructs R1 packet containing the following
parameters (of course common HIP header is still present):
	(i) New parameter that carries some secret, call it ENC(S), where S can
be anything some function, random string, etc., that later will allow
both initiator and responder to agree on some common secret (of way is
to use bivariate polynomials, see bellow the explanation how those can
be used to derive a common secret). The ENC parameter is encrypted using
initiators public key (I assume that encryption is more efficient than
DH or ECDH computation)
	(ii) Responder's HostID
	(iii) Signature that covers the entire HIP packet.


5. Once the initiator receives R1 packet proceeds with normal steps,
such as signature verification, etc. It then decrypts the ENC parameter
with is private key and obtains S. Using S initiator computes a secret
key. Once this is done the initiator constructs I2 packet with the
following parameters:
	(i) The ENC parameter which carries let say S', which will allow the
responder to derive the same secret key. This parameter is encrypted
using responder public key.
	(ii) HMAC parameter as usual 
	(iii) Signature parameter as usual (I am not sure whether HMAC is
sufficient and we can omit using signatures in I2 and R2 packets for
wireless sensor networks)


6. Responder upon receiving I2 decrypts ENC parameter (i) computes the
session key and (ii) verifies HMAC. It then construct an R2 packet with
follwing parameters:
	(i) HMAC 
	(ii) Signature (may HMAC is sufficient and signature parameter can be
omitted in sensor networks?)


Session key deviation function (using bivariate polynomials) can look as
following:

1. Responder randomly selects coefficients {a0, a1, ..., at} and point x
for a bivariate polynomial of form:

F(x, y) = a0*b0 + a1*b1*x*y + ... + at*bt*x^t*y^t 

(Note that this happens when I1 is received)

2. Initiator uses the F(x, y) (found in R1 message) and randomly selects
coefficients {b0, b1, ..., bt} and point y. The initiator now can 
evaluate F(x, y) and get common secret. It then sends back to responder
the evaluated at point y and using coefficients {b0, b1, ..., bt}
polynomial F(x, y).

3. Responder now can also evaluate F(x, y) (knowing both coefficients
{a0, a1, ..., at}, {b0, b1, ..., bt}, x and y points) and get the same
session key as initiator.



Kind regards,
Dmitriy Kuptsov