Re: [Mip4] Does MIP support RegReq authentication without having to do timekeeping?

I guess Alex has a valid concern.
In order to avoid this Hacking scenario that Alex mentioned, I suggest the following, especially the MR implementation as Alex mentioned is open and possible for modification.

When the MR sends any RRQ, the MR MUST use a good random number generator and include that in the low 32 bits of the RRQ ID.
What does this mean?
When the HA sends RRP with code 133, it always include the same random number that was sent in the RRQ. i.e., The HA will insert its timestamp in the higher order 32 bits of the RRP ID. It also copies the lower 32 bits from the RRQ into the lower 32 bits in the RRP.

How this defeat replay attack:
When MR receives the RRP, as usual, it compares the lower 32 bits of the RRP ID field to the one that was used in the RRQ and they have to be equal. This means that this RRP with code 133 can be available ONLY once. Assuming a strong random number generator at the MR.

Best Regards,
Ahmad

-----Original Message-----
From: mip4-bounces@ietf.org [mailto:mip4-bounces@ietf.org] On Behalf Of Kent Leung (kleung)
Sent: Thursday, March 14, 2013 3:07 PM
To: Alexandru Petrescu
Cc: mip4@ietf.org
Subject: Re: [Mip4] Does MIP support RegReq authentication without having to do timekeeping?

The Authenticator value is different for RRQ vs RRP. The extension carries different value based on the message. The way to calculate the value requires the shared key between MR and HA. So it's not easy for an attacker to know the key.

Kent

-----Original Message-----
From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com]
Sent: Thursday, March 14, 2013 1:03 PM
To: Kent Leung (kleung)
Cc: mip4@ietf.org
Subject: Re: [Mip4] Does MIP support RegReq authentication without having to do timekeeping?

Le 14/03/2013 20:59, Kent Leung (kleung) a écrit :
> The RRP1 cannot be faked since the MN-HA Auth Ext protects the 
> message.

I strongly doubt that.  Were it so, then the same extension could protect the first RRQ1 as well.

I believe it is possible for an attacker HA to intercept the initial RRQ1(time=1970), and the RRP1(time=2013) and fake a RREP towards the MR. 
  No?

Alex

>
> Kent
>
> -----Original Message----- From: Alexandru Petrescu 
> [mailto:alexandru.petrescu@gmail.com] Sent: Thursday, March 14, 2013
> 12:58 PM To: Kent Leung (kleung) Cc: mip4@ietf.org Subject: Re:
> [Mip4] Does MIP support RegReq authentication without having to do 
> timekeeping?
>
> Le 14/03/2013 20:47, Kent Leung (kleung) a écrit :
>> Hmm, I'm not clear with your response.
>>
>> Let's assume the following scenario.
>>
>> 1. MR sends initial RRQ1 (time=a) to HA 2. HA sends RRP1 (time=b) 
>> with code 133
>
> Ok.  Do you think MR receiving this RRP1 will be able to safele verify 
> it is legitimate?  Or is it possible than an attacker HA fakes this
> RRP1 message?
>
>> 3. MR sends RRQ2 (time=b+) 4. HA sends RRP2(time=b+) => registration 
>> successful 5. After MR recovers from failure, MR sends RRQ3(time=c) 
>> 6. HA sends RRP3(time=d) with code 133 7. MR sends RRQ4(time=d+) 8.
>> HA sends RRP4(time=d+) => reregistration successful
>
> These latter steps 3-8 make sense.
>
> Alex
>
>>
>> We would need to confirm if #6 happens properly for a specific 
>> vendor. :) But I would expect #7 should happen if code 133 is 
>> received.
>>
>> Kent
>>
>> -----Original Message----- From: mip4-bounces@ietf.org 
>> [mailto:mip4-bounces@ietf.org] On Behalf Of Alexandru Petrescu
>> Sent: Thursday, March 14, 2013 12:40 PM To: mip4@ietf.org Subject:
>> Re: [Mip4] Does MIP support RegReq authentication without having to 
>> do timekeeping?
>>
>> Le 14/03/2013 20:38, Kent Leung (kleung) a écrit :
>>>
>>> It needs to have the time, even if it does second registration.
>>> It's not a problem it takes longer (we can send easily two 
>>> messages). But the second message will also be refused by the HA 
>>> because it still has the wrong time.
>>>
>>> KL> Why is the timestamp in the 2nd RRQ wrong?
>>
>> Because the computer has lost its time, because it was turned off 
>> long time (vehicle in garage for several weeks in winter time).
>> It now has year 1970.
>>
>> Alex
>>
>>>
>>> Kent
>>>
>>>
>>
>>
>> -- Mip4 mailing list: Mip4@ietf.org Web interface:
>> https://www.ietf.org/mailman/listinfo/mip4 Charter page:
>> http://www.ietf.org/html.charters/mip4-charter.html Supplemental
>> site: http://www.mip4.org/
>>
>>
>
>
>
>

--
Mip4 mailing list: Mip4@ietf.org
    Web interface: https://www.ietf.org/mailman/listinfo/mip4
     Charter page: http://www.ietf.org/html.charters/mip4-charter.html
Supplemental site: http://www.mip4.org/