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

"Kent Leung (kleung)" <kleung@cisco.com> Thu, 14 March 2013 21:47 UTC

Return-Path: <kleung@cisco.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 C24D21F0D0F for <mip4@ietfa.amsl.com>; Thu, 14 Mar 2013 14:47:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level:
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 uutiywTVi2Lj for <mip4@ietfa.amsl.com>; Thu, 14 Mar 2013 14:47:00 -0700 (PDT)
Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id DAD201F0D09 for <mip4@ietf.org>; Thu, 14 Mar 2013 14:46:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6192; q=dns/txt; s=iport; t=1363297620; x=1364507220; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=uUmxiJeJdjPbgit6Qbzzrk1GA7X3ilJvW/A2TAwVITk=; b=PLj6lpiFhHLePI0lrJF7qG9nCINc4p0ql57w8daqJ7p+4lBlxZMF2Duz eJjmeiWEP9MoKXr81X0c/z4IgjxlY2+4eVmRLpei118vkq9TjAB6QKl8o ZgbJaIO8kQy+mmOjdroFPwI8EROfCHm+R3AUFk6cGkUjYGJybx7IEaEq3 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgEFAEBEQlGtJV2Y/2dsb2JhbABDxQOBZxZ0gisBAQEEAQEBZAcLDAQCAQgRBAEBCx0HIQYLFAkIAgQOBQgBh3kDDwy4IA2JW4xMghkmCwIFBoJZYQOIPow6jUiFGoFUgTaCKA
X-IronPort-AV: E=Sophos;i="4.84,848,1355097600"; d="scan'208";a="187628482"
Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-5.cisco.com with ESMTP; 14 Mar 2013 21:46:59 +0000
Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r2ELkx2L003384 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 14 Mar 2013 21:46:59 GMT
Received: from xmb-aln-x03.cisco.com ([169.254.6.8]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.02.0318.004; Thu, 14 Mar 2013 16:46:59 -0500
From: "Kent Leung (kleung)" <kleung@cisco.com>
To: Alexandru Petrescu <alexandru.petrescu@gmail.com>
Thread-Topic: [Mip4] Does MIP support RegReq authentication without having to do timekeeping?
Thread-Index: AQHOIOVj5IvDl6+vSUiwtmVfOnfckpilj5BAgABVXgD//6zD0IAAVrCA//+sqlCAAFRfgP//rJ+wAAsO3oAACm8KMP//rgCAgABTfsD//679AIAAU29A///FPwCAAFMmMA==
Date: Thu, 14 Mar 2013 21:46:58 +0000
Message-ID: <CD85F32117029D4F9AEF48BDEF5536AB10215D75@xmb-aln-x03.cisco.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.21.115.74]
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 21:47:00 -0000

The next RRQ should not blindly copy the timestamp from HA. The timestamp (in the RRQ) provided by MN needs to be adjusted based on the RRP.

Kent

-----Original Message-----
From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] 
Sent: Thursday, March 14, 2013 2: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/
>>>>
>>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>>
>
>
>
>