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

Ahmad Muhanna <amuhanna@awardsolutions.com> Thu, 14 March 2013 22:14 UTC

Return-Path: <amuhanna@awardsolutions.com>
X-Original-To: mip4@ietfa.amsl.com
Delivered-To: mip4@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 682A321F8ED4 for <mip4@ietfa.amsl.com>; Thu, 14 Mar 2013 15:14:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eHdoPjcG2W7L for <mip4@ietfa.amsl.com>; Thu, 14 Mar 2013 15:14:50 -0700 (PDT)
Received: from exprod8og111.obsmtp.com (exprod8og111.obsmtp.com [64.18.3.22]) by ietfa.amsl.com (Postfix) with ESMTP id C91CC21F8F50 for <mip4@ietf.org>; Thu, 14 Mar 2013 15:14:49 -0700 (PDT)
Received: from mail.awardsolutions.com ([66.142.250.98]) (using TLSv1) by exprod8ob111.postini.com ([64.18.7.12]) with SMTP ID DSNKUUJL1nOsd2KucAFeK0kWzsozxEnHauD3@postini.com; Thu, 14 Mar 2013 15:14:50 PDT
Received: from REDWOOD.usa.awardsolutions.com ([fe80::a1f1:7708:4a71:9fee]) by Redwood.usa.awardsolutions.com ([fe80::a1f1:7708:4a71:9fee%11]) with mapi id 14.01.0438.000; Thu, 14 Mar 2013 17:14:44 -0500
From: Ahmad Muhanna <amuhanna@awardsolutions.com>
To: Alexandru Petrescu <alexandru.petrescu@gmail.com>, "Kent Leung (kleung)" <kleung@cisco.com>
Thread-Topic: [Mip4] Does MIP support RegReq authentication without having to do timekeeping?
Thread-Index: AQHOIPyN7rndUjrH0UWKuVF8jTknMJilvCsg
Date: Thu, 14 Mar 2013 22:14:43 +0000
Message-ID: <3359F724933DFD458579D24EAC769098857A54B0@Redwood.usa.awardsolutions.com>
References: <514206FE.7050807@gmail.com> <3359F724933DFD458579D24EAC769098857A51DC@Redwood.usa.awardsolutions.com> <51421CB9.1080100@gmail.com> <CD85F32117029D4F9AEF48BDEF5536AB10215B92@xmb-aln-x03.cisco.com> <514223C4.8010905@gmail.com> <CD85F32117029D4F9AEF48BDEF5536AB10215BCB@xmb-aln-x03.cisco.com> <514226A9.9020700@gmail.com> <CD85F32117029D4F9AEF48BDEF5536AB10215C28@xmb-aln-x03.cisco.com> <51422787.5060509@gmail.com> <CD85F32117029D4F9AEF48BDEF5536AB10215C72@xmb-aln-x03.cisco.com> <51422BCB.30409@gmail.com> <CD85F32117029D4F9AEF48BDEF5536AB10215CA7@xmb-aln-x03.cisco.com> <51422D07.9070901@gmail.com> <CD85F32117029D4F9AEF48BDEF5536AB10215CD2@xmb-aln-x03.cisco.com> <51422F1C.7000705@gmail.com> <CD85F32117029D4F9AEF48BDEF5536AB10215CEC@xmb-aln-x03.cisco.com> <514243D0.2090309@gmail.com>
In-Reply-To: <514243D0.2090309@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.25.208.42]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "mip4@ietf.org" <mip4@ietf.org>
Subject: Re: [Mip4] Does MIP support RegReq authentication without having to do timekeeping?
X-BeenThere: mip4@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobility for IPv4 <mip4.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mip4>, <mailto:mip4-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mip4>
List-Post: <mailto:mip4@ietf.org>
List-Help: <mailto:mip4-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mip4>, <mailto:mip4-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 14 Mar 2013 22:14:51 -0000

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. 

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 RRP. 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!! :-)

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/