Re: [CGA-EXT] [dhcwg] Follow up request for review of draft-ietf-csi-dhcpv6-cga-ps

"Laganier, Julien" <julienl@qualcomm.com> Wed, 15 September 2010 15:55 UTC

Return-Path: <julienl@qualcomm.com>
X-Original-To: cga-ext@core3.amsl.com
Delivered-To: cga-ext@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B98613A698E; Wed, 15 Sep 2010 08:55:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.553
X-Spam-Level:
X-Spam-Status: No, score=-106.553 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 Wru1N1DDHt+K; Wed, 15 Sep 2010 08:55:38 -0700 (PDT)
Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 2FCF73A69BB; Wed, 15 Sep 2010 08:55:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=julienl@qualcomm.com; q=dns/txt; s=qcdkim; t=1284566162; x=1316102162; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version; z=From:=20"Laganier,=20Julien"=20<julienl@qualcomm.com> |To:=20Ted=20Lemon=20<Ted.Lemon@nominum.com>,=20Tony=20Ch eneau=0D=0A=09<tony.cheneau@it-sudparis.eu>|CC:=20"dhcwg@ ietf.org=20Group"=20<dhcwg@ietf.org>,=20"cga-ext@ietf.org "=0D=0A=09<cga-ext@ietf.org>,=20Droms=20<rdroms.ietf@gmai l.com>,=20"Ralph@core3.amsl.com"=0D=0A=09<Ralph@core3.ams l.com>|Date:=20Wed,=2015=20Sep=202010=2008:56:01=20-0700 |Subject:=20RE:=20[CGA-EXT]=20[dhcwg]=20Follow=20up=20req uest=20for=20review=20of=0D=0A=09draft-ietf-csi-dhcpv6-cg a-ps|Thread-Topic:=20[CGA-EXT]=20[dhcwg]=20Follow=20up=20 request=20for=20review=20of=0D=0A=09draft-ietf-csi-dhcpv6 -cga-ps|Thread-Index:=20ActUYZcyQDNVkOOgToS0CVAZg2RW5gAi0 TNg|Message-ID:=20<BF345F63074F8040B58C00A186FCA57F1F6826 E5AE@NALASEXMB04.na.qualcomm.com>|References:=20<21C043C9 -FE72-44F4-97A9-4684384F013D@gmail.com>=0D=0A=09<57452427 -8824-4736-A8EF-022B3157935A@nominum.com>=0D=0A=09<201009 15000842.667d28ae@it-sudparis.eu>=0D=0A=20<A19EC513-6C71- 467C-A447-83C5FE600BC2@nominum.com>|In-Reply-To:=20<A19EC 513-6C71-467C-A447-83C5FE600BC2@nominum.com> |Accept-Language:=20en-US|Content-Language:=20en-US |X-MS-Has-Attach:|X-MS-TNEF-Correlator:|acceptlanguage: =20en-US|Content-Type:=20text/plain=3B=20charset=3D"us-as cii"|Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0; bh=/PkszJa7Kfk67YLRjYNqZSWY5ao5hA6t4CJr/d0Uito=; b=S35dKR8yIX1WH+NeCepkk2OakaTX6q2x6277TCzAfo4SLk1zHa86a+pK F/MYJ0pFda7e+oni1HMsIYS7i2BhiAvhaireT7m8xjIed0oJM1QqHTYcs HOs0Z6MOs0st4oAencRKtkUlpLikES6Ss441B+3sOI/5TIS1621udtwvO U=;
X-IronPort-AV: E=McAfee;i="5400,1158,6106"; a="54437869"
Received: from ironmsg02-r.qualcomm.com ([172.30.46.16]) by wolverine02.qualcomm.com with ESMTP; 15 Sep 2010 08:56:01 -0700
X-IronPort-AV: E=Sophos;i="4.56,371,1280732400"; d="scan'208";a="85721083"
Received: from nasanexhub04.qualcomm.com (HELO nasanexhub04.na.qualcomm.com) ([129.46.134.222]) by ironmsg02-R.qualcomm.com with ESMTP/TLS/RC4-MD5; 15 Sep 2010 08:56:01 -0700
Received: from nalasexhc02.na.qualcomm.com (10.47.129.186) by nasanexhub04.na.qualcomm.com (129.46.134.222) with Microsoft SMTP Server (TLS) id 8.2.254.0; Wed, 15 Sep 2010 08:56:01 -0700
Received: from NALASEXMB04.na.qualcomm.com ([10.47.7.118]) by nalasexhc02.na.qualcomm.com ([10.47.129.186]) with mapi; Wed, 15 Sep 2010 08:56:01 -0700
From: "Laganier, Julien" <julienl@qualcomm.com>
To: Ted Lemon <Ted.Lemon@nominum.com>, Tony Cheneau <tony.cheneau@it-sudparis.eu>
Date: Wed, 15 Sep 2010 08:56:01 -0700
Thread-Topic: [CGA-EXT] [dhcwg] Follow up request for review of draft-ietf-csi-dhcpv6-cga-ps
Thread-Index: ActUYZcyQDNVkOOgToS0CVAZg2RW5gAi0TNg
Message-ID: <BF345F63074F8040B58C00A186FCA57F1F6826E5AE@NALASEXMB04.na.qualcomm.com>
References: <21C043C9-FE72-44F4-97A9-4684384F013D@gmail.com> <57452427-8824-4736-A8EF-022B3157935A@nominum.com> <20100915000842.667d28ae@it-sudparis.eu> <A19EC513-6C71-467C-A447-83C5FE600BC2@nominum.com>
In-Reply-To: <A19EC513-6C71-467C-A447-83C5FE600BC2@nominum.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "dhcwg@ietf.org Group" <dhcwg@ietf.org>, "cga-ext@ietf.org" <cga-ext@ietf.org>, Droms <rdroms.ietf@gmail.com>, "Ralph@core3.amsl.com" <Ralph@core3.amsl.com>
Subject: Re: [CGA-EXT] [dhcwg] Follow up request for review of draft-ietf-csi-dhcpv6-cga-ps
X-BeenThere: cga-ext@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: CGA and SeND Extensions <cga-ext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/cga-ext>, <mailto:cga-ext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/cga-ext>
List-Post: <mailto:cga-ext@ietf.org>
List-Help: <mailto:cga-ext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/cga-ext>, <mailto:cga-ext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 15 Sep 2010 15:55:45 -0000

Ted,

Some clarifications:

Ted Lemon wrote:
> Sent: Tuesday, September 14, 2010 4:07 PM
> To: Tony Cheneau
> Cc: dhcwg@ietf.org Group; cga-ext@ietf.org; Droms; Ralph@core3.amsl.com
> Subject: Re: [CGA-EXT] [dhcwg] Follow up request for review of draft-
> ietf-csi-dhcpv6-cga-ps
> 
> On Sep 14, 2010, at 6:08 PM, Tony Cheneau wrote:
> > So, as long as the public/private key are generated on the node, I
> > would say that you will not need to communicate the private key (in
> > clear or in a ciphered form).
> 
> Actually, this is clear as mud to me.   What is the big compute job
> that's being done on the server, then?   Can you point me to the RFC I
> should be reading that explains all this?   Sorry to be obtuse.   :'}

If you have a look at the CGA generation algorithm described in RFC 3972 you will see that there are potentially two distinct computationally intensive tasks:

1. generation of public-private (RSA) key pair
2. generation of a CGA modifier value for a given Security Parameter (Sec) as per RFC 3972. (The Sec is used to harden the resistance of brute force attacks on the 64-bits IIDs of CGAs.)

#2 above might become computationally intensive for values of the Sec higher than zero (if it's zero any Modifier satisfies 3972). Back in 2002 I remember running the algorithm on then standard personal computers (e.g., x86 / ~1GhZ) and it would took ~20 seconds for Sec = 1 and a couple of minutes for Sec = 2. I do not remember going higher...

I understand the proposal is to offload #2 to the server while #1 would not be. 

IMHO it does not any make sense to offload when Sec is set to 0 because the computational load is nil. 

When Sec is set to 1 the computational load of #2 seems to be in the same order of magnitude as for #1, which does not necessarily means that offloading is useless as #1 might not need to be done by the constrained device itself (e.g., it's been offload to someone else, and result is stored on a smartcard.)

That being set I have not been convinced yet that there's a real world use case for Sec values higher than zero.

HTH,

--julien