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

[<Basavaraj.Patil at nokia.com>]

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 at 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 at 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 at cs.tcd.ie>
>> To: "Eddy, Wesley M. (GRC-RCN0)[Verizon]" <wesley.m.eddy at nasa.gov>
>> Cc: <irsg at ISI.EDU>; <mobopts at irtf.org>; <Basavaraj.Patil at 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 at 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 at irtf.org
>> http://www.irtf.org/mailman/listinfo/mobopts
>>