Re: [Mobopts] [IRSG] IRSG PollforI-D:draft-irtf-mobopts-location-privacy-solutions

Rajeev Koodli <rajeev.koodli@gmail.com> Wed, 18 March 2009 05:00 UTC

Return-Path: <rajeev.koodli@gmail.com>
X-Original-To: mobopts@core3.amsl.com
Delivered-To: mobopts@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 14B523A6B41 for <mobopts@core3.amsl.com>; Tue, 17 Mar 2009 22:00:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.05
X-Spam-Level:
X-Spam-Status: No, score=-1.05 tagged_above=-999 required=5 tests=[AWL=-1.550, BAYES_00=-2.599, MANGLED_LIST=2.3, SARE_SUB_RAND_LETTRS4=0.799]
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 5H527G4W8NPu for <mobopts@core3.amsl.com>; Tue, 17 Mar 2009 22:00:07 -0700 (PDT)
Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.172]) by core3.amsl.com (Postfix) with ESMTP id 16CC23A6AA2 for <mobopts@irtf.org>; Tue, 17 Mar 2009 22:00:06 -0700 (PDT)
Received: by wf-out-1314.google.com with SMTP id 24so347372wfg.7 for <mobopts@irtf.org>; Tue, 17 Mar 2009 22:00:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=1/m7IdL6VRHUTG4cM8IdpVKInlx9stfZ5ytB63RMBgA=; b=E+YUK4qe+K6gWTRrUI+h11fnIV8nuIQ0e1cMulWEC5qV2scQdwfyfyfcK7w4kIRNT8 0HnMOR5wBiz/LdSVWOZUrSKXTHy2AKGqEBCwjBYqehvk+LaPGxxkLtuPmlElGQsRjP1k DTM9Y9EpvDVyMz2O9UVwuXNd3gRkRJX6lNuXM=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=qGMwQNgQkCS7fTQ47ZR203TvODQX5aO6EoUaaAtL5xUoPN2g/VybG2PoZx7a0xl686 vgnFVfF0uxdI2KPUNRPAu2q77kZ6DrcFTJ32kHFgntG7Hz+9U+3WF8K8h8Yl4PVgBzJ2 DPBObI4Xw14bV+L9bWd6qmm1nO1sLqGygRPL4=
MIME-Version: 1.0
Received: by 10.141.146.4 with SMTP id y4mr155658rvn.88.1237352450729; Tue, 17 Mar 2009 22:00:50 -0700 (PDT)
In-Reply-To: <65C0B939696D45A68AF8962E358A19DE@t3400>
References: <FAAB54171A6C764E969E6B4CB3C2ADD206E4878DC9@NOK-EUMSG-03.mgdnok.nokia.com> <C304DB494AC0C04C87C6A6E2FF5603DB220C9F0127@NDJSSCC01.ndc.nasa.gov> <49B7E2D3.3050605@cs.tcd.ie> <65C0B939696D45A68AF8962E358A19DE@t3400>
Date: Tue, 17 Mar 2009 22:00:50 -0700
Message-ID: <3d57679a0903172200m394665e7q8629a3df31c6a18a@mail.gmail.com>
From: Rajeev Koodli <rajeev.koodli@gmail.com>
To: QIU Ying <qiuying@i2r.a-star.edu.sg>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: irsg@isi.edu, Basavaraj.Patil@nokia.com, mobopts@irtf.org, "Eddy, Wesley M. \(GRC-RCN0\)\[Verizon\]" <wesley.m.eddy@nasa.gov>, Stephen Farrell <stephen.farrell@cs.tcd.ie>
Subject: Re: [Mobopts] [IRSG] IRSG PollforI-D:draft-irtf-mobopts-location-privacy-solutions
X-BeenThere: mobopts@irtf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Mobility Optimizations <mobopts.irtf.org>
List-Unsubscribe: <http://www.irtf.org/mailman/listinfo/mobopts>, <mailto:mobopts-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/mobopts>
List-Post: <mailto:mobopts@irtf.org>
List-Help: <mailto:mobopts-request@irtf.org?subject=help>
List-Subscribe: <http://www.irtf.org/mailman/listinfo/mobopts>, <mailto:mobopts-request@irtf.org?subject=subscribe>
X-List-Received-Date: Wed, 18 Mar 2009 05:00:08 -0000

Hi Stephen,

I agree with Qiu Ying's reply.

We can address the nits as part of RFC Editor revisions.

So, I request that the ID be progressed forward.

Thanks for your review.

Regards,

-Rajeev


On Mon, Mar 16, 2009 at 3:37 AM, QIU Ying <qiuying@i2r.a-star.edu.sg> wrote:
> Hi, Stephen
>
> Thanks for your review and support.
>
> For the #1 comment regarding to active attacks: we discussed this issue
> before, but it is too difficult to enumerate all of active attacks. In fact,
> if an attacker launches an active attack signaling,  the mobile node has 2
> choices: 1) simply drop the signaling message according to its own access
> policy, hence it is not much for further discussion. 2) accept the signaling
> messages, then the MN must response the signaling. Hence the attacker is
> treated as a correspondent node and the correspondent node is still not able
> to map the real home address and the in-use care-of-address according to our
> solution.
>
> For the #2 comment regarding to using ECB in DES: since KM is derived from
> Kbm: Kpm = HMAC_SHA1(Kbm, 0), and Kbm is always changed by every RR process,
> a Kpm can not be re-used during the communication. By the way, the example
> you describe here, I prefer to call it as passive attack because it does not
> tempt messages from MN or HA directly.
>
> Please correct me if I am wrong.
>
> Regards and Thanks
> Qiu Ying
>
>
> ----- Original Message ----- From: "Stephen Farrell"
> <stephen.farrell@cs.tcd.ie>
> To: "Eddy, Wesley M. (GRC-RCN0)[Verizon]" <wesley.m.eddy@nasa.gov>
> Cc: <irsg@ISI.EDU>DU>; <mobopts@irtf.org>rg>; <Basavaraj.Patil@nokia.com>
> Sent: Thursday, March 12, 2009 12:12 AM
> Subject: Re: [Mobopts] [IRSG] IRSG
> PollforI-D:draft-irtf-mobopts-location-privacy-solutions
>
>
>>
>> Eddy, Wesley M. (GRC-RCN0)[Verizon] wrote:
>>>
>>> You can record a vote for "ready to publish" from me.
>>
>> Same here.
>>
>> My non-blocking comments are below. Feel free to take 'em
>> on board or not, as you see fit.
>>
>> Stephen.
>>
>> #1 Its a bit surprising that active attackers aren't considered.
>> Maybe adding a justification for that would be good? I guess the
>> danger is that someone goes and implements all of this and claims
>> to have produced a "secure" solution, but in fact has only produced
>> something good against passive attacks.
>>
>> #2 section 5.1, what mode of operation is used for the generation
>> of the encrypted home address? For AES I think ECB is ok, but if
>> a block cipher with a smaller block (e.g.  3DES) is used, then you
>> should probably not use ECB as that'd expose some information if
>> Kpm is re-used and if the home address structure is sensitive.
>> I've no idea if that's significant or not, but specifying CBC mode
>> for shorter-block ciphers would I think remove the potential
>> vulnerability. (3DES with ECB mode might also allow some non-obvious
>> cut'n'paste attacks if Kpm is re-used, though those'd be active
>> attacks and so presumably out of scope.)
>>
>> Nits:
>>
>> #1 1st sentence of section 1 is missing a word, maybe "problem"
>>
>> #2, p12: s/If such/If so/
>>
>>
>>
>> _______________________________________________
>> Mobopts mailing list
>> Mobopts@irtf.org
>> http://www.irtf.org/mailman/listinfo/mobopts
>
> Institute for Infocomm Research disclaimer:  "This email is confidential and
> may be privileged. If you are not the intended recipient, please delete it
> and notify us immediately. Please do not copy or use it for any purpose, or
> disclose its contents to any other person. Thank you."
> _______________________________________________
> Mobopts mailing list
> Mobopts@irtf.org
> http://www.irtf.org/mailman/listinfo/mobopts
>