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

[Rajeev Koodli <rajeev.koodli at gmail.com>]

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
>