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

<Basavaraj.Patil@nokia.com> Fri, 15 May 2009 21:08 UTC

Return-Path: <Basavaraj.Patil@nokia.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 1FA203A6E5D for <mobopts@core3.amsl.com>; Fri, 15 May 2009 14:08:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.87
X-Spam-Level:
X-Spam-Status: No, score=-4.87 tagged_above=-999 required=5 tests=[AWL=-1.370, BAYES_00=-2.599, MANGLED_LIST=2.3, RCVD_IN_DNSWL_MED=-4, 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 eQpqNlJQQuw2 for <mobopts@core3.amsl.com>; Fri, 15 May 2009 14:08:52 -0700 (PDT)
Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id CA1EA3A6924 for <mobopts@irtf.org>; Fri, 15 May 2009 14:08:51 -0700 (PDT)
Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n4FLA2XA006036; Fri, 15 May 2009 16:10:10 -0500
Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 16 May 2009 00:09:58 +0300
Received: from vaebh101.NOE.Nokia.com ([10.160.244.22]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 16 May 2009 00:09:58 +0300
Received: from smtp.mgd.nokia.com ([65.54.30.5]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Sat, 16 May 2009 00:09:53 +0300
Received: from NOK-EUMSG-03.mgdnok.nokia.com ([65.54.30.108]) by nok-am1mhub-01.mgdnok.nokia.com ([65.54.30.5]) with mapi; Fri, 15 May 2009 23:09:53 +0200
From: <Basavaraj.Patil@nokia.com>
To: <rajeev.koodli@gmail.com>, <qiuying@i2r.a-star.edu.sg>
Date: Fri, 15 May 2009 23:10:02 +0200
Thread-Topic: [Mobopts] [IRSG] IRSG PollforI-D:draft-irtf-mobopts-location-privacy-solutions
Thread-Index: Acmnhoi0QItsMES6TYGcLIgE+QgMuAuGvo/1
Message-ID: <C633445A.2892D%basavaraj.patil@nokia.com>
In-Reply-To: <3d57679a0903172200m394665e7q8629a3df31c6a18a@mail.gmail.com>
Accept-Language: en-US
Content-Language: en
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginalArrivalTime: 15 May 2009 21:09:53.0328 (UTC) FILETIME=[7DC4F300:01C9D5A1]
X-Nokia-AV: Clean
Cc: irsg@isi.edu, mobopts@irtf.org, wesley.m.eddy@nasa.gov, 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: Fri, 15 May 2009 21:08:53 -0000

The outcome of the IRSG poll has been positive and I have received at least
3 "Ready to publish" recommendations.
A few nits have been identified.

While it is possible to handle these as part of the RFC editor process, I
think it would be best to spin a new revision of the ID which takes care of
these nits now. It would also avoid the problem of these issues falling
through the cracks as the document progresses thru the pipeline.

-Basavaraj


On 3/17/09 11:00 PM, "ext Rajeev Koodli" <rajeev.koodli@gmail.com> wrote:

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