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

Le 14/03/2013 23:14, Ahmad Muhanna a écrit :
> Alex,
>
> The MN/MR needs to send another RRQ; It is not just a warning.
> Otherwise, its Registration will timeout and the HA will delete its
> binding.

YEs, that is right.  But the specification doesn't say that so explicitely.

> There was a reason for the MN to send a Re-Registration, most
> probably extends its registration lifetime, for example. If the Reply
> is NOT successful, the MN can NOT assume its registration has been
> extended successfully. Thus, the MN/MR needs to send another RRQ.

Yes.

> This uis the behavior I have seen many times of very popular MIP4
> MNs.
>
> BTW: also, the purpose of 133 error code is to let the MN know that
> its time stamp is NOT in synch with the HA. Usually, the Mobile node
>  will adjust its timestamp according to what is coming from the HA. I
>  have seen this a lot!! :-)

Ok.  So we now do it as well.  Our implementation of MR works with the
HA from that manufacturarer - synchronizes time.  I will post separately
the procedure.

Alex

>
> Anyhow; enjoy your IETF meeting!
>
> Best Regards, Ahmad
>
> -----Original Message----- From: mip4-bounces@ietf.org
> [mailto:mip4-bounces@ietf.org] On Behalf Of Alexandru Petrescu Sent:
>  Thursday, March 14, 2013 4:41 PM To: Kent Leung (kleung) Cc:
> mip4@ietf.org Subject: Re: [Mip4] Does MIP support RegReq
> authentication without having to do timekeeping?
>
> Kent,
>
> Thanks for the discussion and clarification.  Thanks for the pointer
>  to the spec RFC5944 says:
>
> "   Code 133: (Denied by home agent, registration Identification
> mismatch)
>
> In this case, the Identification field in the Registration Reply will
> contain a value that allows the mobile node to synchronize with the
> home agent, based upon the style of replay protection in effect
> (Section 5.7).  The mobile node MUST adjust the parameters it uses to
> compute the Identification field based upon the information in the
> Registration Reply, before issuing any future Registration
> Requests."
>
> When we read this last phrase we didnt see an incentive to send
> another RREQ containing the Id copied from the RREP.  Reads more like
> a warning to take care next time, but it doesnt explicitely say that
> the HA expects a RREQ in the immediate, and that the MR should send
> it.
>
> We could only rely on the error log in the HA, which doesnt invite to
> send another RREQ either, it says:
>
> "Mar 11 09:35:55.107: MobileIP: HA rejects registration for MN
> 13.8.9.3 - registration id mismatch (133) Mar 11 09:35:55.107:
> MobileIP: Sending Registration Reply message for MN 13.8.9.3 with
> Lifetime 40, Home Address 13.8.9.3, Home Agent 13.8.9.4 Code 133 "
>
> Alex
>
> Le 14/03/2013 21:15, Kent Leung (kleung) a écrit :
>> Timestamp is one of the fields in the message that is protected by
>>  key using a hash function. Since we are at IETF, let's talk
>> offline as this seems to need some clarification and hand waving.
>> :)
>>
>> Kent
>>
>> -----Original Message----- From: Alexandru Petrescu
>> [mailto:alexandru.petrescu@gmail.com] Sent: Thursday, March 14,
>> 2013 1:12 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 21:07, Kent Leung (kleung) a écrit :
>>> 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.
>>
>> Yes, there is a key which is hardly guessable.
>>
>> Do you think the same key could be used precisely in the same
>> manner in the first place, for the first RREQ, without timestamp?
>>
>> Alex
>>
>>>
>>> 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/
>
>