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

Alexandru Petrescu <alexandru.petrescu@gmail.com> Thu, 21 March 2013 15:30 UTC

Return-Path: <alexandru.petrescu@gmail.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 E7E1E21F90F5 for <mip4@ietfa.amsl.com>; Thu, 21 Mar 2013 08:30:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.186
X-Spam-Level:
X-Spam-Status: No, score=-10.186 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8]
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 Eu6m+wV4eo33 for <mip4@ietfa.amsl.com>; Thu, 21 Mar 2013 08:30:50 -0700 (PDT)
Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) by ietfa.amsl.com (Postfix) with ESMTP id 6E17821F9111 for <mip4@ietf.org>; Thu, 21 Mar 2013 08:30:50 -0700 (PDT)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id r2LFUhKs032002 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 21 Mar 2013 16:30:43 +0100
Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r2LFUhi5003975; Thu, 21 Mar 2013 16:30:43 +0100 (envelope-from alexandru.petrescu@gmail.com)
Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r2LFUa4N003400; Thu, 21 Mar 2013 16:30:43 +0100
Message-ID: <514B2771.9080504@gmail.com>
Date: Thu, 21 Mar 2013 16:29:53 +0100
From: Alexandru Petrescu <alexandru.petrescu@gmail.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130307 Thunderbird/17.0.4
MIME-Version: 1.0
To: Ahmad Muhanna <amuhanna@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> <3359F724933DFD458579D24EAC769098857A54B0@Redwood.usa.awardsolutions.com>
In-Reply-To: <3359F724933DFD458579D24EAC769098857A54B0@Redwood.usa.awardsolutions.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Cc: "Kent Leung \(kleung\)" <kleung@cisco.com>, "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, 21 Mar 2013 15:30:52 -0000

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/
>
>