From alexandru.petrescu@gmail.com Thu Mar 14 10:21:45 2013 Return-Path: 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 6E3AC21F8EAD for ; Thu, 14 Mar 2013 10:21:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.609 X-Spam-Level: X-Spam-Status: No, score=-9.609 tagged_above=-999 required=5 tests=[AWL=0.640, 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 k+WOeHFWkIr2 for ; Thu, 14 Mar 2013 10:21:44 -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 DD14221F8F50 for ; Thu, 14 Mar 2013 10:21:42 -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 r2EHLfd1027062 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 14 Mar 2013 18:21:41 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r2EHLftf000821 for ; Thu, 14 Mar 2013 18:21:41 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.86.7]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r2EHLXkJ017470 for ; Thu, 14 Mar 2013 18:21:40 +0100 Message-ID: <514206FE.7050807@gmail.com> Date: Thu, 14 Mar 2013 18:21:02 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Mobile IPv4 Mailing List Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2013 17:21:45 -0000 MIP4 participants, I would like to learn whether Mobile IPv4 spec supports an authentication scheme for RegReq/RegRep which does not rely on timekeeping. Let me explain why. We use a Mobile Router in a moving network that gets connected to the Home Agent. The Mobile Router's power supply may be turned off (its battery dies out after an extended period of inactivity, like in a vehicle). At that point the MR looses its time. When it finally wakes up, it has to perform a Registration Req/Rep with the HA, without assuming that its time is correct. Or, the MIP4 regreq/regrep HA implementation that we use seems to rely on having the right time, otherwise the registration fails. Under these conditions, is it possible to use an auth mechanism which does not rely on timekeeping? Alex From amuhanna@awardsolutions.com Thu Mar 14 11:44:39 2013 Return-Path: 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 0E81121F8DA8 for ; Thu, 14 Mar 2013 11:44:39 -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 s+JuM4-MDP3Z for ; Thu, 14 Mar 2013 11:44:38 -0700 (PDT) Received: from exprod8og114.obsmtp.com (exprod8og114.obsmtp.com [64.18.3.28]) by ietfa.amsl.com (Postfix) with ESMTP id B5E7121F8D17 for ; Thu, 14 Mar 2013 11:44:37 -0700 (PDT) Received: from mail.awardsolutions.com ([66.142.250.98]) (using TLSv1) by exprod8ob114.postini.com ([64.18.7.12]) with SMTP ID DSNKUUIZtL10+/qhTDV2innEZ5d1X6MEhI+m@postini.com; Thu, 14 Mar 2013 11:40:53 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 13:44:35 -0500 From: Ahmad Muhanna To: Alexandru Petrescu , Mobile IPv4 Mailing List Thread-Topic: [Mip4] Does MIP support RegReq authentication without having to do timekeeping? Thread-Index: AQHOINhsTBPzIQFtNkS6cO9qzV4P1pilhFTw Date: Thu, 14 Mar 2013 18:44:34 +0000 Message-ID: <3359F724933DFD458579D24EAC769098857A51DC@Redwood.usa.awardsolutions.com> References: <514206FE.7050807@gmail.com> In-Reply-To: <514206FE.7050807@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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2013 18:44:39 -0000 Hi Alex, As far as I recall, RFC2002 and all updates afterwards, allow the use of no= nce. Basically like a challenge. >From implementation prospective; I would allow both to coexist as follows: 1. Both HA and MR uses timestamp as normal and no issue there. 2. When the MR fails or start NOT to have a valid time, the MR should have = remembered the last RRP ID which is based on timestamp and use that for Re-= Registration. 3. At the HA, it should check timestamp first, if it passes then timestamp = continues to work; if it fails, the HA should check the Re-Registration ID = against the last ID that was sent in the last RRP, if it is the same, the H= A should allow the RRP to go through. I Hope this helps! Cheers! Best Regards, Ahmad -----Original Message----- From: mip4-bounces@ietf.org [mailto:mip4-bounces@ietf.org] On Behalf Of Ale= xandru Petrescu Sent: Thursday, March 14, 2013 12:21 PM To: Mobile IPv4 Mailing List Subject: [Mip4] Does MIP support RegReq authentication without having to do= timekeeping? MIP4 participants, I would like to learn whether Mobile IPv4 spec supports an authentication s= cheme for RegReq/RegRep which does not rely on timekeeping. Let me explain why. We use a Mobile Router in a moving network that gets connected to the Home = Agent. The Mobile Router's power supply may be turned off (its battery die= s out after an extended period of inactivity, like in a vehicle). At that = point the MR looses its time. When it finally wakes up, it has to perform a Registration Req/Rep with the= HA, without assuming that its time is correct. Or, the MIP4 regreq/regrep= HA implementation that we use seems to rely on having the right time, othe= rwise the registration fails. Under these conditions, is it possible to use an auth mechanism which does = not rely on timekeeping? Alex -- 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/ From alexandru.petrescu@gmail.com Thu Mar 14 11:54:37 2013 Return-Path: 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 B96D711E80DF for ; Thu, 14 Mar 2013 11:54:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.728 X-Spam-Level: X-Spam-Status: No, score=-9.728 tagged_above=-999 required=5 tests=[AWL=0.521, 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 NILGZLPHktU5 for ; Thu, 14 Mar 2013 11:54:37 -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 A975F11E8193 for ; Thu, 14 Mar 2013 11:54:34 -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 r2EIsKQn006120 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 14 Mar 2013 19:54:21 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r2EIsKOg018167; Thu, 14 Mar 2013 19:54:20 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.86.1]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r2EIsEPD015599; Thu, 14 Mar 2013 19:54:19 +0100 Message-ID: <51421CB9.1080100@gmail.com> Date: Thu, 14 Mar 2013 19:53:45 +0100 From: Alexandru Petrescu 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 References: <514206FE.7050807@gmail.com> <3359F724933DFD458579D24EAC769098857A51DC@Redwood.usa.awardsolutions.com> In-Reply-To: <3359F724933DFD458579D24EAC769098857A51DC@Redwood.usa.awardsolutions.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: Mobile IPv4 Mailing List 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2013 18:54:37 -0000 Sounds reasonable to use timestamp as usual and if it fails then try the nonce... but... Does this behaviour require modification of the HA? (we are not able to modify it, but we can modify the MR). Le 14/03/2013 19:44, Ahmad Muhanna a écrit : > Hi Alex, > > As far as I recall, RFC2002 and all updates afterwards, allow the > use of nonce. Basically like a challenge. > >> From implementation prospective; I would allow both to coexist as >> follows: > 1. Both HA and MR uses timestamp as normal and no issue there. Yes. > 2. When the MR fails or start NOT to have a valid time, the MR > should have remembered the last RRP ID which is based on timestamp > and use that for Re-Registration. Ok, this could be done. > 3. At the HA, it should check timestamp first, if it passes then > timestamp continues to work; if it fails, the HA should check the > Re-Registration ID against the last ID that was sent in the last > RRP, if it is the same, the HA should allow the RRP to go through. This is a modification to the HA implementation, isn't it? Alex > > I Hope this helps! > > Cheers! > > 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 12:21 PM To: Mobile IPv4 Mailing List > Subject: [Mip4] Does MIP support RegReq authentication without > having to do timekeeping? > > MIP4 participants, > > I would like to learn whether Mobile IPv4 spec supports an > authentication scheme for RegReq/RegRep which does not rely on > timekeeping. > > Let me explain why. > > We use a Mobile Router in a moving network that gets connected to > the Home Agent. The Mobile Router's power supply may be turned off > (its battery dies out after an extended period of inactivity, like in > a vehicle). At that point the MR looses its time. > > When it finally wakes up, it has to perform a Registration Req/Rep > with the HA, without assuming that its time is correct. Or, the > MIP4 regreq/regrep HA implementation that we use seems to rely on > having the right time, otherwise the registration fails. > > Under these conditions, is it possible to use an auth mechanism > which does not rely on timekeeping? > > Alex > > -- 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/ > > From kleung@cisco.com Thu Mar 14 12:20:18 2013 Return-Path: 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 BB08911E81B8 for ; Thu, 14 Mar 2013 12:20:18 -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 BsZgpOlNGk3R for ; Thu, 14 Mar 2013 12:20:18 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id DD1CD11E80F2 for ; Thu, 14 Mar 2013 12:20:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3284; q=dns/txt; s=iport; t=1363288817; x=1364498417; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=oZzBaJYGxbWmQdaahxcTDZHs5RC4+VrtQzNhagtIboQ=; b=RapoGIOUYkdO0Xc2hofQwvoeXNyGXxUxZmIsvh7XGWGFNHGQWb8/YdOi mivE/O+9v5Pn5coFFTqeLgW9ejhY89nZM7N3PkaEAcl1jpslCua5+JoYF Cn/uQGEDVvDvBmX4b3AU0yQTgbaAESUewxHgmPGl31JkgkLg+vBualEx8 Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAI0hQlGtJV2b/2dsb2JhbABDxQKBZRZ0gisBAQEDAQEBAWsLBQcEAgEIEQQBAQsdBycLFAkIAgQBDQUIAYgFBgzBa41PDgl/MQIFBoJZYQOIPp8cgVSBNoIo X-IronPort-AV: E=Sophos;i="4.84,846,1355097600"; d="scan'208";a="187614528" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-3.cisco.com with ESMTP; 14 Mar 2013 19:20:17 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r2EJKHk9025482 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 14 Mar 2013 19:20:17 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.8]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.02.0318.004; Thu, 14 Mar 2013 14:20:17 -0500 From: "Kent Leung (kleung)" To: Alexandru Petrescu , Ahmad Muhanna Thread-Topic: [Mip4] Does MIP support RegReq authentication without having to do timekeeping? Thread-Index: AQHOIOVj5IvDl6+vSUiwtmVfOnfckpilj5BA Date: Thu, 14 Mar 2013 19:20:16 +0000 Message-ID: References: <514206FE.7050807@gmail.com> <3359F724933DFD458579D24EAC769098857A51DC@Redwood.usa.awardsolutions.com> <51421CB9.1080100@gmail.com> In-Reply-To: <51421CB9.1080100@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: Mobile IPv4 Mailing List 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2013 19:20:18 -0000 Hi Alex. The nonce method is specified in the Mobile IP RFCs. But I'm not s= ure if any vendor supports that. If #2 works, that should address you issue= . Kent -----Original Message----- From: mip4-bounces@ietf.org [mailto:mip4-bounces@ietf.org] On Behalf Of Ale= xandru Petrescu Sent: Thursday, March 14, 2013 11:54 AM To: Ahmad Muhanna Cc: Mobile IPv4 Mailing List Subject: Re: [Mip4] Does MIP support RegReq authentication without having t= o do timekeeping? Sounds reasonable to use timestamp as usual and if it fails then try the no= nce... but... Does this behaviour require modification of the HA? (we are not able to mod= ify it, but we can modify the MR). Le 14/03/2013 19:44, Ahmad Muhanna a =E9crit : > Hi Alex, > > As far as I recall, RFC2002 and all updates afterwards, allow the use=20 > of nonce. Basically like a challenge. > >> From implementation prospective; I would allow both to coexist as >> follows: > 1. Both HA and MR uses timestamp as normal and no issue there. Yes. > 2. When the MR fails or start NOT to have a valid time, the MR should=20 > have remembered the last RRP ID which is based on timestamp and use=20 > that for Re-Registration. Ok, this could be done. > 3. At the HA, it should check timestamp first, if it passes then=20 > timestamp continues to work; if it fails, the HA should check the=20 > Re-Registration ID against the last ID that was sent in the last RRP,=20 > if it is the same, the HA should allow the RRP to go through. This is a modification to the HA implementation, isn't it? Alex > > I Hope this helps! > > Cheers! > > Best Regards, Ahmad > > -----Original Message----- From: mip4-bounces@ietf.org=20 > [mailto:mip4-bounces@ietf.org] On Behalf Of Alexandru Petrescu Sent: > Thursday, March 14, 2013 12:21 PM To: Mobile IPv4 Mailing List > Subject: [Mip4] Does MIP support RegReq authentication without having=20 > to do timekeeping? > > MIP4 participants, > > I would like to learn whether Mobile IPv4 spec supports an=20 > authentication scheme for RegReq/RegRep which does not rely on=20 > timekeeping. > > Let me explain why. > > We use a Mobile Router in a moving network that gets connected to the=20 > Home Agent. The Mobile Router's power supply may be turned off (its=20 > battery dies out after an extended period of inactivity, like in a=20 > vehicle). At that point the MR looses its time. > > When it finally wakes up, it has to perform a Registration Req/Rep=20 > with the HA, without assuming that its time is correct. Or, the > MIP4 regreq/regrep HA implementation that we use seems to rely on=20 > having the right time, otherwise the registration fails. > > Under these conditions, is it possible to use an auth mechanism which=20 > does not rely on timekeeping? > > Alex > > -- 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/ From amuhanna@awardsolutions.com Thu Mar 14 12:24:29 2013 Return-Path: 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 0929021F8DA8 for ; Thu, 14 Mar 2013 12:24:29 -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 aDw1EIi1MmBb for ; Thu, 14 Mar 2013 12:24:28 -0700 (PDT) Received: from exprod8og110.obsmtp.com (exprod8og110.obsmtp.com [64.18.3.100]) by ietfa.amsl.com (Postfix) with ESMTP id 125B221F8D86 for ; Thu, 14 Mar 2013 12:24:28 -0700 (PDT) Received: from mail.awardsolutions.com ([66.142.250.98]) (using TLSv1) by exprod8ob110.postini.com ([64.18.7.12]) with SMTP ID DSNKUUIj6tGaWcfaYFkA/mjp3i6WNe8lPfdm@postini.com; Thu, 14 Mar 2013 12:24:28 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 14:24:25 -0500 From: Ahmad Muhanna To: Alexandru Petrescu Thread-Topic: [Mip4] Does MIP support RegReq authentication without having to do timekeeping? Thread-Index: AQHOIOVe6tN+JjF66kaY3dsRHs+8+5ilj/Dw Date: Thu, 14 Mar 2013 19:24:24 +0000 Message-ID: <3359F724933DFD458579D24EAC769098857A527E@Redwood.usa.awardsolutions.com> References: <514206FE.7050807@gmail.com> <3359F724933DFD458579D24EAC769098857A51DC@Redwood.usa.awardsolutions.com> <51421CB9.1080100@gmail.com> In-Reply-To: <51421CB9.1080100@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: Mobile IPv4 Mailing List 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2013 19:24:29 -0000 Okay, here an easier one BUT I am NOT sure if you will be able to get that = without a change at the HA! :-) Please remember the support of timestamp replay protection is Mandatory whi= le the nonce is OPTIONAL. In case the HA supports nonce, then the following is your best option: 1. Configure on the HA two different Security Associations that are indexed= using two different SPIs. One with replay protection using timestamp and t= he other using nonce. 2. When the MR time fails, the MR uses the what mentioned before, i.e., it = could use the last RRP timestamp, but uses the SPI which reference nonce as= replay protection. If HA does NOT support nonce, then NO solution my friend, at least that wha= t I am thinking. :-) Best Regards, Ahmad -----Original Message----- From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com]=20 Sent: Thursday, March 14, 2013 1:54 PM To: Ahmad Muhanna Cc: Mobile IPv4 Mailing List Subject: Re: [Mip4] Does MIP support RegReq authentication without having t= o do timekeeping? Sounds reasonable to use timestamp as usual and if it fails then try the no= nce... but... Does this behaviour require modification of the HA? (we are not able to mod= ify it, but we can modify the MR). Le 14/03/2013 19:44, Ahmad Muhanna a =E9crit : > Hi Alex, > > As far as I recall, RFC2002 and all updates afterwards, allow the use=20 > of nonce. Basically like a challenge. > >> From implementation prospective; I would allow both to coexist as >> follows: > 1. Both HA and MR uses timestamp as normal and no issue there. Yes. > 2. When the MR fails or start NOT to have a valid time, the MR should=20 > have remembered the last RRP ID which is based on timestamp and use=20 > that for Re-Registration. Ok, this could be done. > 3. At the HA, it should check timestamp first, if it passes then=20 > timestamp continues to work; if it fails, the HA should check the=20 > Re-Registration ID against the last ID that was sent in the last RRP,=20 > if it is the same, the HA should allow the RRP to go through. This is a modification to the HA implementation, isn't it? Alex > > I Hope this helps! > > Cheers! > > Best Regards, Ahmad > > -----Original Message----- From: mip4-bounces@ietf.org=20 > [mailto:mip4-bounces@ietf.org] On Behalf Of Alexandru Petrescu Sent: > Thursday, March 14, 2013 12:21 PM To: Mobile IPv4 Mailing List > Subject: [Mip4] Does MIP support RegReq authentication without having=20 > to do timekeeping? > > MIP4 participants, > > I would like to learn whether Mobile IPv4 spec supports an=20 > authentication scheme for RegReq/RegRep which does not rely on=20 > timekeeping. > > Let me explain why. > > We use a Mobile Router in a moving network that gets connected to the=20 > Home Agent. The Mobile Router's power supply may be turned off (its=20 > battery dies out after an extended period of inactivity, like in a=20 > vehicle). At that point the MR looses its time. > > When it finally wakes up, it has to perform a Registration Req/Rep=20 > with the HA, without assuming that its time is correct. Or, the > MIP4 regreq/regrep HA implementation that we use seems to rely on=20 > having the right time, otherwise the registration fails. > > Under these conditions, is it possible to use an auth mechanism which=20 > does not rely on timekeeping? > > Alex > > -- 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/ > > From alexandru.petrescu@gmail.com Thu Mar 14 12:24:29 2013 Return-Path: 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 B2AE421F8D86 for ; Thu, 14 Mar 2013 12:24:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.793 X-Spam-Level: X-Spam-Status: No, score=-9.793 tagged_above=-999 required=5 tests=[AWL=0.456, 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 4rvOUI5aphpS for ; Thu, 14 Mar 2013 12:24:28 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) by ietfa.amsl.com (Postfix) with ESMTP id 3CE6F21F8B8F for ; Thu, 14 Mar 2013 12:24:28 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id r2EJOL0R030075 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 14 Mar 2013 20:24:21 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r2EJOLup021955; Thu, 14 Mar 2013 20:24:21 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.86.3]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r2EJOIg2022847; Thu, 14 Mar 2013 20:24:20 +0100 Message-ID: <514223C4.8010905@gmail.com> Date: Thu, 14 Mar 2013 20:23:48 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: "Kent Leung (kleung)" References: <514206FE.7050807@gmail.com> <3359F724933DFD458579D24EAC769098857A51DC@Redwood.usa.awardsolutions.com> <51421CB9.1080100@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: Ahmad Muhanna , Mobile IPv4 Mailing List 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2013 19:24:29 -0000 Le 14/03/2013 20:20, Kent Leung (kleung) a écrit : > Hi Alex. The nonce method is specified in the Mobile IP RFCs. But I'm > not sure if any vendor supports that. If #2 works, that should > address you issue. This is something we should implement on the MR side. Do you think the HA side already does it (I doubt?)? Alex > > Kent > > -----Original Message----- From: mip4-bounces@ietf.org > [mailto:mip4-bounces@ietf.org] On Behalf Of Alexandru Petrescu Sent: > Thursday, March 14, 2013 11:54 AM To: Ahmad Muhanna Cc: Mobile IPv4 > Mailing List Subject: Re: [Mip4] Does MIP support RegReq > authentication without having to do timekeeping? > > Sounds reasonable to use timestamp as usual and if it fails then try > the nonce... but... > > Does this behaviour require modification of the HA? (we are not able > to modify it, but we can modify the MR). > > Le 14/03/2013 19:44, Ahmad Muhanna a écrit : >> Hi Alex, >> >> As far as I recall, RFC2002 and all updates afterwards, allow the >> use of nonce. Basically like a challenge. >> >>> From implementation prospective; I would allow both to coexist >>> as follows: >> 1. Both HA and MR uses timestamp as normal and no issue there. > > Yes. > >> 2. When the MR fails or start NOT to have a valid time, the MR >> should have remembered the last RRP ID which is based on timestamp >> and use that for Re-Registration. > > Ok, this could be done. > >> 3. At the HA, it should check timestamp first, if it passes then >> timestamp continues to work; if it fails, the HA should check the >> Re-Registration ID against the last ID that was sent in the last >> RRP, if it is the same, the HA should allow the RRP to go through. > > This is a modification to the HA implementation, isn't it? > > Alex > >> >> I Hope this helps! >> >> Cheers! >> >> 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 12:21 PM To: Mobile IPv4 Mailing >> List Subject: [Mip4] Does MIP support RegReq authentication without >> having to do timekeeping? >> >> MIP4 participants, >> >> I would like to learn whether Mobile IPv4 spec supports an >> authentication scheme for RegReq/RegRep which does not rely on >> timekeeping. >> >> Let me explain why. >> >> We use a Mobile Router in a moving network that gets connected to >> the Home Agent. The Mobile Router's power supply may be turned off >> (its battery dies out after an extended period of inactivity, like >> in a vehicle). At that point the MR looses its time. >> >> When it finally wakes up, it has to perform a Registration Req/Rep >> with the HA, without assuming that its time is correct. Or, the >> MIP4 regreq/regrep HA implementation that we use seems to rely on >> having the right time, otherwise the registration fails. >> >> Under these conditions, is it possible to use an auth mechanism >> which does not rely on timekeeping? >> >> Alex >> >> -- 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/ > > From kleung@cisco.com Thu Mar 14 12:31:33 2013 Return-Path: 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 2A13F11E81CE for ; Thu, 14 Mar 2013 12:31:33 -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 qGQae5jQWNud for ; Thu, 14 Mar 2013 12:31:32 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 50CC611E81CA for ; Thu, 14 Mar 2013 12:31:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4250; q=dns/txt; s=iport; t=1363289492; x=1364499092; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=qwwIuqKsZ3yjMMKw+0zlVGyKeNiYmBNPhgT2xuSER5M=; b=aAPbibGDfMskJTXos8Pq2eBdrm2eHIii54W9/ODWsHjIUvbglMlD+Cig q6T7Jtl9CZFfCnA0o3k0VLe8MkSP7LLSiY6GSdKUISsyU8Rlnvqul73xV N8NzaH6+tBABtT2wSwHU8sqyl0WLGIDsMOwWgE7eRU3BSEjtfsUx8S+4c s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAD4kQlGtJXG+/2dsb2JhbABDxQKBZRZ0gisBAQEDAQEBAWsLDAQCAQgRBAEBCx0HIQYLFAkIAgQOBQgBh3kDCQYMt3wNiVuMTIEDDgl/MQIFBoJZYQOIPow6jUiFGoFUgTaCKA X-IronPort-AV: E=Sophos;i="4.84,846,1355097600"; d="scan'208";a="187584762" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-7.cisco.com with ESMTP; 14 Mar 2013 19:31:31 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r2EJVV4B021281 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 14 Mar 2013 19:31:31 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.8]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.02.0318.004; Thu, 14 Mar 2013 14:31:31 -0500 From: "Kent Leung (kleung)" To: Alexandru Petrescu Thread-Topic: [Mip4] Does MIP support RegReq authentication without having to do timekeeping? Thread-Index: AQHOIOVj5IvDl6+vSUiwtmVfOnfckpilj5BAgABVXgD//6zD0A== Date: Thu, 14 Mar 2013 19:31:30 +0000 Message-ID: References: <514206FE.7050807@gmail.com> <3359F724933DFD458579D24EAC769098857A51DC@Redwood.usa.awardsolutions.com> <51421CB9.1080100@gmail.com> <514223C4.8010905@gmail.com> In-Reply-To: <514223C4.8010905@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: Ahmad Muhanna , Mobile IPv4 Mailing List 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2013 19:31:33 -0000 I assumed that you had an MR that could do that. I'm not aware of any MR ve= ndor that will maintain the timestamp state after recovering from a failure= .=20 On your original issue, wouldn't the re-registration succeed after the HA r= eplies with code 133? It would take two registration messages from MR so it= takes a little longer. Kent -----Original Message----- From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com]=20 Sent: Thursday, March 14, 2013 12:24 PM To: Kent Leung (kleung) Cc: Ahmad Muhanna; Mobile IPv4 Mailing List Subject: Re: [Mip4] Does MIP support RegReq authentication without having t= o do timekeeping? Le 14/03/2013 20:20, Kent Leung (kleung) a =E9crit : > Hi Alex. The nonce method is specified in the Mobile IP RFCs. But I'm=20 > not sure if any vendor supports that. If #2 works, that should address=20 > you issue. This is something we should implement on the MR side. Do you think the HA = side already does it (I doubt?)? Alex > > Kent > > -----Original Message----- From: mip4-bounces@ietf.org=20 > [mailto:mip4-bounces@ietf.org] On Behalf Of Alexandru Petrescu Sent: > Thursday, March 14, 2013 11:54 AM To: Ahmad Muhanna Cc: Mobile IPv4 =20 > Mailing List Subject: Re: [Mip4] Does MIP support RegReq=20 > authentication without having to do timekeeping? > > Sounds reasonable to use timestamp as usual and if it fails then try =20 > the nonce... but... > > Does this behaviour require modification of the HA? (we are not able =20 > to modify it, but we can modify the MR). > > Le 14/03/2013 19:44, Ahmad Muhanna a =E9crit : >> Hi Alex, >> >> As far as I recall, RFC2002 and all updates afterwards, allow the use=20 >> of nonce. Basically like a challenge. >> >>> From implementation prospective; I would allow both to coexist as=20 >>> follows: >> 1. Both HA and MR uses timestamp as normal and no issue there. > > Yes. > >> 2. When the MR fails or start NOT to have a valid time, the MR should=20 >> have remembered the last RRP ID which is based on timestamp and use=20 >> that for Re-Registration. > > Ok, this could be done. > >> 3. At the HA, it should check timestamp first, if it passes then=20 >> timestamp continues to work; if it fails, the HA should check the=20 >> Re-Registration ID against the last ID that was sent in the last RRP,=20 >> if it is the same, the HA should allow the RRP to go through. > > This is a modification to the HA implementation, isn't it? > > Alex > >> >> I Hope this helps! >> >> Cheers! >> >> Best Regards, Ahmad >> >> -----Original Message----- From: mip4-bounces@ietf.org=20 >> [mailto:mip4-bounces@ietf.org] On Behalf Of Alexandru Petrescu >> Sent: Thursday, March 14, 2013 12:21 PM To: Mobile IPv4 Mailing List=20 >> Subject: [Mip4] Does MIP support RegReq authentication without having=20 >> to do timekeeping? >> >> MIP4 participants, >> >> I would like to learn whether Mobile IPv4 spec supports an=20 >> authentication scheme for RegReq/RegRep which does not rely on=20 >> timekeeping. >> >> Let me explain why. >> >> We use a Mobile Router in a moving network that gets connected to the=20 >> Home Agent. The Mobile Router's power supply may be turned off (its=20 >> battery dies out after an extended period of inactivity, like in a=20 >> vehicle). At that point the MR looses its time. >> >> When it finally wakes up, it has to perform a Registration Req/Rep=20 >> with the HA, without assuming that its time is correct. Or, the >> MIP4 regreq/regrep HA implementation that we use seems to rely on=20 >> having the right time, otherwise the registration fails. >> >> Under these conditions, is it possible to use an auth mechanism which=20 >> does not rely on timekeeping? >> >> Alex >> >> -- 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/ > > From alexandru.petrescu@gmail.com Thu Mar 14 12:36:52 2013 Return-Path: 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 5AD0D11E81FD for ; Thu, 14 Mar 2013 12:36:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.844 X-Spam-Level: X-Spam-Status: No, score=-9.844 tagged_above=-999 required=5 tests=[AWL=0.405, 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 r1gBhJc--z-Z for ; Thu, 14 Mar 2013 12:36:51 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) by ietfa.amsl.com (Postfix) with ESMTP id 1FE1811E81E3 for ; Thu, 14 Mar 2013 12:36:50 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id r2EJajZO000556 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 14 Mar 2013 20:36:45 +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 r2EJajOD023715; Thu, 14 Mar 2013 20:36:45 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.86.3]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r2EJadZT019786; Thu, 14 Mar 2013 20:36:44 +0100 Message-ID: <514226A9.9020700@gmail.com> Date: Thu, 14 Mar 2013 20:36:09 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: "Kent Leung (kleung)" References: <514206FE.7050807@gmail.com> <3359F724933DFD458579D24EAC769098857A51DC@Redwood.usa.awardsolutions.com> <51421CB9.1080100@gmail.com> <514223C4.8010905@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: Ahmad Muhanna , Mobile IPv4 Mailing List 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2013 19:36:52 -0000 Le 14/03/2013 20:31, Kent Leung (kleung) a écrit : > I assumed that you had an MR that could do that. I'm not aware of > any MR vendor that will maintain the timestamp state after > recovering from a failure. Well, with our MR that could be implemented - it's simple, just save it before dying out. (no, we are not an MR vendor). > On your original issue, wouldn't the re-registration succeed after > the HA replies with code 133? It would take two registration > messages from MR so it takes a little longer. 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. Alex > > Kent > > -----Original Message----- From: Alexandru Petrescu > [mailto:alexandru.petrescu@gmail.com] Sent: Thursday, March 14, 2013 > 12:24 PM To: Kent Leung (kleung) Cc: Ahmad Muhanna; Mobile IPv4 > Mailing List Subject: Re: [Mip4] Does MIP support RegReq > authentication without having to do timekeeping? > > Le 14/03/2013 20:20, Kent Leung (kleung) a écrit : >> Hi Alex. The nonce method is specified in the Mobile IP RFCs. But >> I'm not sure if any vendor supports that. If #2 works, that should >> address you issue. > > This is something we should implement on the MR side. Do you think > the HA side already does it (I doubt?)? > > Alex > >> >> Kent >> >> -----Original Message----- From: mip4-bounces@ietf.org >> [mailto:mip4-bounces@ietf.org] On Behalf Of Alexandru Petrescu >> Sent: Thursday, March 14, 2013 11:54 AM To: Ahmad Muhanna Cc: >> Mobile IPv4 Mailing List Subject: Re: [Mip4] Does MIP support >> RegReq authentication without having to do timekeeping? >> >> Sounds reasonable to use timestamp as usual and if it fails then >> try the nonce... but... >> >> Does this behaviour require modification of the HA? (we are not >> able to modify it, but we can modify the MR). >> >> Le 14/03/2013 19:44, Ahmad Muhanna a écrit : >>> Hi Alex, >>> >>> As far as I recall, RFC2002 and all updates afterwards, allow >>> the use of nonce. Basically like a challenge. >>> >>>> From implementation prospective; I would allow both to coexist >>>> as follows: >>> 1. Both HA and MR uses timestamp as normal and no issue there. >> >> Yes. >> >>> 2. When the MR fails or start NOT to have a valid time, the MR >>> should have remembered the last RRP ID which is based on >>> timestamp and use that for Re-Registration. >> >> Ok, this could be done. >> >>> 3. At the HA, it should check timestamp first, if it passes then >>> timestamp continues to work; if it fails, the HA should check >>> the Re-Registration ID against the last ID that was sent in the >>> last RRP, if it is the same, the HA should allow the RRP to go >>> through. >> >> This is a modification to the HA implementation, isn't it? >> >> Alex >> >>> >>> I Hope this helps! >>> >>> Cheers! >>> >>> 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 12:21 PM To: Mobile IPv4 Mailing >>> List Subject: [Mip4] Does MIP support RegReq authentication >>> without having to do timekeeping? >>> >>> MIP4 participants, >>> >>> I would like to learn whether Mobile IPv4 spec supports an >>> authentication scheme for RegReq/RegRep which does not rely on >>> timekeeping. >>> >>> Let me explain why. >>> >>> We use a Mobile Router in a moving network that gets connected >>> to the Home Agent. The Mobile Router's power supply may be >>> turned off (its battery dies out after an extended period of >>> inactivity, like in a vehicle). At that point the MR looses its >>> time. >>> >>> When it finally wakes up, it has to perform a Registration >>> Req/Rep with the HA, without assuming that its time is correct. >>> Or, the MIP4 regreq/regrep HA implementation that we use seems >>> to rely on having the right time, otherwise the registration >>> fails. >>> >>> Under these conditions, is it possible to use an auth mechanism >>> which does not rely on timekeeping? >>> >>> Alex >>> >>> -- 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/ >> >> > > > > From amuhanna@awardsolutions.com Thu Mar 14 12:37:01 2013 Return-Path: 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 8CDDD11E81FD for ; Thu, 14 Mar 2013 12:37:01 -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 9JTFlgOHrKAQ for ; Thu, 14 Mar 2013 12:37:00 -0700 (PDT) Received: from exprod8og118.obsmtp.com (exprod8og118.obsmtp.com [64.18.3.36]) by ietfa.amsl.com (Postfix) with ESMTP id B3B0611E8205 for ; Thu, 14 Mar 2013 12:37:00 -0700 (PDT) Received: from mail.awardsolutions.com ([66.142.250.98]) (using TLSv1) by exprod8ob118.postini.com ([64.18.7.12]) with SMTP ID DSNKUUIm2gLBL2alnX1FBahzmq7sbzG/ovRj@postini.com; Thu, 14 Mar 2013 12:37:00 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 14:36:46 -0500 From: Ahmad Muhanna To: "Kent Leung (kleung)" , Alexandru Petrescu Thread-Topic: [Mip4] Does MIP support RegReq authentication without having to do timekeeping? Thread-Index: AQHOIOVj5IvDl6+vSUiwtmVfOnfckpilj5BAgABVXgD//6zD0IAAAnGQ Date: Thu, 14 Mar 2013 19:36:45 +0000 Message-ID: <3359F724933DFD458579D24EAC769098857A52C0@Redwood.usa.awardsolutions.com> References: <514206FE.7050807@gmail.com> <3359F724933DFD458579D24EAC769098857A51DC@Redwood.usa.awardsolutions.com> <51421CB9.1080100@gmail.com> <514223C4.8010905@gmail.com> In-Reply-To: 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: Mobile IPv4 Mailing List 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2013 19:37:01 -0000 Yep. I think what Kent said makes sense. MR will use the timestamp returned in the RRP with code 133 and the second = RRQ should work just fine.=20 I guess no need to change anything then :-) Best Regards, Ahmad -----Original Message----- From: Kent Leung (kleung) [mailto:kleung@cisco.com]=20 Sent: Thursday, March 14, 2013 2:32 PM To: Alexandru Petrescu Cc: Ahmad Muhanna; Mobile IPv4 Mailing List Subject: RE: [Mip4] Does MIP support RegReq authentication without having t= o do timekeeping? I assumed that you had an MR that could do that. I'm not aware of any MR ve= ndor that will maintain the timestamp state after recovering from a failure= .=20 On your original issue, wouldn't the re-registration succeed after the HA r= eplies with code 133? It would take two registration messages from MR so it= takes a little longer. Kent -----Original Message----- From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] Sent: Thursday, March 14, 2013 12:24 PM To: Kent Leung (kleung) Cc: Ahmad Muhanna; Mobile IPv4 Mailing List Subject: Re: [Mip4] Does MIP support RegReq authentication without having t= o do timekeeping? Le 14/03/2013 20:20, Kent Leung (kleung) a =E9crit : > Hi Alex. The nonce method is specified in the Mobile IP RFCs. But I'm=20 > not sure if any vendor supports that. If #2 works, that should address=20 > you issue. This is something we should implement on the MR side. Do you think the HA = side already does it (I doubt?)? Alex > > Kent > > -----Original Message----- From: mip4-bounces@ietf.org=20 > [mailto:mip4-bounces@ietf.org] On Behalf Of Alexandru Petrescu Sent: > Thursday, March 14, 2013 11:54 AM To: Ahmad Muhanna Cc: Mobile IPv4=20 > Mailing List Subject: Re: [Mip4] Does MIP support RegReq=20 > authentication without having to do timekeeping? > > Sounds reasonable to use timestamp as usual and if it fails then try=20 > the nonce... but... > > Does this behaviour require modification of the HA? (we are not able=20 > to modify it, but we can modify the MR). > > Le 14/03/2013 19:44, Ahmad Muhanna a =E9crit : >> Hi Alex, >> >> As far as I recall, RFC2002 and all updates afterwards, allow the use=20 >> of nonce. Basically like a challenge. >> >>> From implementation prospective; I would allow both to coexist as >>> follows: >> 1. Both HA and MR uses timestamp as normal and no issue there. > > Yes. > >> 2. When the MR fails or start NOT to have a valid time, the MR should=20 >> have remembered the last RRP ID which is based on timestamp and use=20 >> that for Re-Registration. > > Ok, this could be done. > >> 3. At the HA, it should check timestamp first, if it passes then=20 >> timestamp continues to work; if it fails, the HA should check the=20 >> Re-Registration ID against the last ID that was sent in the last RRP,=20 >> if it is the same, the HA should allow the RRP to go through. > > This is a modification to the HA implementation, isn't it? > > Alex > >> >> I Hope this helps! >> >> Cheers! >> >> Best Regards, Ahmad >> >> -----Original Message----- From: mip4-bounces@ietf.org=20 >> [mailto:mip4-bounces@ietf.org] On Behalf Of Alexandru Petrescu >> Sent: Thursday, March 14, 2013 12:21 PM To: Mobile IPv4 Mailing List >> Subject: [Mip4] Does MIP support RegReq authentication without having=20 >> to do timekeeping? >> >> MIP4 participants, >> >> I would like to learn whether Mobile IPv4 spec supports an=20 >> authentication scheme for RegReq/RegRep which does not rely on=20 >> timekeeping. >> >> Let me explain why. >> >> We use a Mobile Router in a moving network that gets connected to the=20 >> Home Agent. The Mobile Router's power supply may be turned off (its=20 >> battery dies out after an extended period of inactivity, like in a=20 >> vehicle). At that point the MR looses its time. >> >> When it finally wakes up, it has to perform a Registration Req/Rep=20 >> with the HA, without assuming that its time is correct. Or, the >> MIP4 regreq/regrep HA implementation that we use seems to rely on=20 >> having the right time, otherwise the registration fails. >> >> Under these conditions, is it possible to use an auth mechanism which=20 >> does not rely on timekeeping? >> >> Alex >> >> -- 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/ > > From kleung@cisco.com Thu Mar 14 12:38:46 2013 Return-Path: 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 131B121F8DAB for ; Thu, 14 Mar 2013 12:38:46 -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 QtWNqy8Az6VI for ; Thu, 14 Mar 2013 12:38:45 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 7CEC021F8DB7 for ; Thu, 14 Mar 2013 12:38:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=297; q=dns/txt; s=iport; t=1363289925; x=1364499525; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=WEAH+YAKIkBcXu9vexHAohL8WixJ4R5FXKO8u3qEFmI=; b=I4h43z0KcbNVBE9JwAAE96whD7dyvnbd/AzG1BcdIDnBNSSrlE995pDX ynEiNCohvA2lTqHGTVma8uT3lpeueASLG4s18HBd/u5ngGzSRXMaYRUfp 88/Xnyb4JSMq0vjtN4rrHLIyIa56oNM3PEpKvyM1dTUSY2MGkugRjm7jH U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAP0lQlGtJXHA/2dsb2JhbABDxQKBZRZ0giwBAQQ6PxACAQgiFBAyJQIEDg2IDMFyjmUxB4JfYQOnWoFUgTaCKA X-IronPort-AV: E=Sophos;i="4.84,846,1355097600"; d="scan'208";a="187622022" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-3.cisco.com with ESMTP; 14 Mar 2013 19:38:45 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r2EJcjJL020098 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 14 Mar 2013 19:38:45 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.8]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.02.0318.004; Thu, 14 Mar 2013 14:38:44 -0500 From: "Kent Leung (kleung)" To: Alexandru Petrescu Thread-Topic: [Mip4] Does MIP support RegReq authentication without having to do timekeeping? Thread-Index: AQHOIOVj5IvDl6+vSUiwtmVfOnfckpilj5BAgABVXgD//6zD0IAAVrCA//+sqlA= Date: Thu, 14 Mar 2013 19:38:43 +0000 Message-ID: References: <514206FE.7050807@gmail.com> <3359F724933DFD458579D24EAC769098857A51DC@Redwood.usa.awardsolutions.com> <51421CB9.1080100@gmail.com> <514223C4.8010905@gmail.com> <514226A9.9020700@gmail.com> In-Reply-To: <514226A9.9020700@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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Ahmad Muhanna , Mobile IPv4 Mailing List 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2013 19:38:46 -0000 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? Kent From alexandru.petrescu@gmail.com Thu Mar 14 12:39:14 2013 Return-Path: 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 C1C4B11E81F4 for ; Thu, 14 Mar 2013 12:39:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.884 X-Spam-Level: X-Spam-Status: No, score=-9.884 tagged_above=-999 required=5 tests=[AWL=0.365, 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 YuR+vmcy8dqh for ; Thu, 14 Mar 2013 12:39:14 -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 C58C511E8166 for ; Thu, 14 Mar 2013 12:39:13 -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 r2EJd7wU000661 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 14 Mar 2013 20:39:07 +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 r2EJd7GN024402; Thu, 14 Mar 2013 20:39:07 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.86.3]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r2EJd3f6020618; Thu, 14 Mar 2013 20:39:06 +0100 Message-ID: <5142273A.3000406@gmail.com> Date: Thu, 14 Mar 2013 20:38:34 +0100 From: Alexandru Petrescu 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 References: <514206FE.7050807@gmail.com> <3359F724933DFD458579D24EAC769098857A51DC@Redwood.usa.awardsolutions.com> <51421CB9.1080100@gmail.com> <514223C4.8010905@gmail.com> <3359F724933DFD458579D24EAC769098857A52C0@Redwood.usa.awardsolutions.com> In-Reply-To: <3359F724933DFD458579D24EAC769098857A52C0@Redwood.usa.awardsolutions.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "Kent Leung \(kleung\)" , Mobile IPv4 Mailing List 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2013 19:39:14 -0000 Le 14/03/2013 20:36, Ahmad Muhanna a écrit : > Yep. I think what Kent said makes sense. MR will use the timestamp > returned in the RRP with code 133 and the second RRQ should work just > fine. Sorry for my naivity, but does the RREP contain a timestamp that the MR should put back in the RREQ? If yes - is that secure? Alex > > I guess no need to change anything then :-) > > Best Regards, Ahmad > > > -----Original Message----- From: Kent Leung (kleung) > [mailto:kleung@cisco.com] Sent: Thursday, March 14, 2013 2:32 PM To: > Alexandru Petrescu Cc: Ahmad Muhanna; Mobile IPv4 Mailing List > Subject: RE: [Mip4] Does MIP support RegReq authentication without > having to do timekeeping? > > I assumed that you had an MR that could do that. I'm not aware of any > MR vendor that will maintain the timestamp state after recovering > from a failure. > > On your original issue, wouldn't the re-registration succeed after > the HA replies with code 133? It would take two registration messages > from MR so it takes a little longer. > > Kent > > -----Original Message----- From: Alexandru Petrescu > [mailto:alexandru.petrescu@gmail.com] Sent: Thursday, March 14, 2013 > 12:24 PM To: Kent Leung (kleung) Cc: Ahmad Muhanna; Mobile IPv4 > Mailing List Subject: Re: [Mip4] Does MIP support RegReq > authentication without having to do timekeeping? > > Le 14/03/2013 20:20, Kent Leung (kleung) a écrit : >> Hi Alex. The nonce method is specified in the Mobile IP RFCs. But >> I'm not sure if any vendor supports that. If #2 works, that should >> address you issue. > > This is something we should implement on the MR side. Do you think > the HA side already does it (I doubt?)? > > Alex > >> >> Kent >> >> -----Original Message----- From: mip4-bounces@ietf.org >> [mailto:mip4-bounces@ietf.org] On Behalf Of Alexandru Petrescu >> Sent: Thursday, March 14, 2013 11:54 AM To: Ahmad Muhanna Cc: >> Mobile IPv4 Mailing List Subject: Re: [Mip4] Does MIP support >> RegReq authentication without having to do timekeeping? >> >> Sounds reasonable to use timestamp as usual and if it fails then >> try the nonce... but... >> >> Does this behaviour require modification of the HA? (we are not >> able to modify it, but we can modify the MR). >> >> Le 14/03/2013 19:44, Ahmad Muhanna a écrit : >>> Hi Alex, >>> >>> As far as I recall, RFC2002 and all updates afterwards, allow the >>> use of nonce. Basically like a challenge. >>> >>>> From implementation prospective; I would allow both to coexist >>>> as follows: >>> 1. Both HA and MR uses timestamp as normal and no issue there. >> >> Yes. >> >>> 2. When the MR fails or start NOT to have a valid time, the MR >>> should have remembered the last RRP ID which is based on >>> timestamp and use that for Re-Registration. >> >> Ok, this could be done. >> >>> 3. At the HA, it should check timestamp first, if it passes then >>> timestamp continues to work; if it fails, the HA should check >>> the Re-Registration ID against the last ID that was sent in the >>> last RRP, if it is the same, the HA should allow the RRP to go >>> through. >> >> This is a modification to the HA implementation, isn't it? >> >> Alex >> >>> >>> I Hope this helps! >>> >>> Cheers! >>> >>> 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 12:21 PM To: Mobile IPv4 Mailing >>> List Subject: [Mip4] Does MIP support RegReq authentication >>> without having to do timekeeping? >>> >>> MIP4 participants, >>> >>> I would like to learn whether Mobile IPv4 spec supports an >>> authentication scheme for RegReq/RegRep which does not rely on >>> timekeeping. >>> >>> Let me explain why. >>> >>> We use a Mobile Router in a moving network that gets connected to >>> the Home Agent. The Mobile Router's power supply may be turned >>> off (its battery dies out after an extended period of inactivity, >>> like in a vehicle). At that point the MR looses its time. >>> >>> When it finally wakes up, it has to perform a Registration >>> Req/Rep with the HA, without assuming that its time is correct. >>> Or, the MIP4 regreq/regrep HA implementation that we use seems to >>> rely on having the right time, otherwise the registration fails. >>> >>> Under these conditions, is it possible to use an auth mechanism >>> which does not rely on timekeeping? >>> >>> Alex >>> >>> -- 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/ >> >> > > > > From alexandru.petrescu@gmail.com Thu Mar 14 12:40:25 2013 Return-Path: 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 985EB11E820F for ; Thu, 14 Mar 2013 12:40:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.917 X-Spam-Level: X-Spam-Status: No, score=-9.917 tagged_above=-999 required=5 tests=[AWL=0.332, 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 joevhJqYLw04 for ; Thu, 14 Mar 2013 12:40:25 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) by ietfa.amsl.com (Postfix) with ESMTP id CB28F11E81F4 for ; Thu, 14 Mar 2013 12:40:24 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id r2EJeNjJ001390 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 14 Mar 2013 20:40:23 +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 r2EJeNGm024648 for ; Thu, 14 Mar 2013 20:40:23 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.86.3]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r2EJeLPD020993 for ; Thu, 14 Mar 2013 20:40:23 +0100 Message-ID: <51422787.5060509@gmail.com> Date: Thu, 14 Mar 2013 20:39:51 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: mip4@ietf.org References: <514206FE.7050807@gmail.com> <3359F724933DFD458579D24EAC769098857A51DC@Redwood.usa.awardsolutions.com> <51421CB9.1080100@gmail.com> <514223C4.8010905@gmail.com> <514226A9.9020700@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2013 19:40:25 -0000 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 > > From amuhanna@awardsolutions.com Thu Mar 14 12:43:25 2013 Return-Path: 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 474C011E821C for ; Thu, 14 Mar 2013 12:43:25 -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 ogEWZTtWuVUa for ; Thu, 14 Mar 2013 12:43:24 -0700 (PDT) Received: from exprod8og114.obsmtp.com (exprod8og114.obsmtp.com [64.18.3.28]) by ietfa.amsl.com (Postfix) with ESMTP id A987411E8166 for ; Thu, 14 Mar 2013 12:43:23 -0700 (PDT) Received: from mail.awardsolutions.com ([66.142.250.98]) (using TLSv1) by exprod8ob114.postini.com ([64.18.7.12]) with SMTP ID DSNKUUIna5CF7j/xwtLFNXcxTB7JSa3sq+EX@postini.com; Thu, 14 Mar 2013 12:39:26 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 14:43:19 -0500 From: Ahmad Muhanna To: Alexandru Petrescu Thread-Topic: [Mip4] Does MIP support RegReq authentication without having to do timekeeping? Thread-Index: AQHOIOuD5IvDl6+vSUiwtmVfOnfckpillXyw Date: Thu, 14 Mar 2013 19:43:18 +0000 Message-ID: <3359F724933DFD458579D24EAC769098857A5312@Redwood.usa.awardsolutions.com> References: <514206FE.7050807@gmail.com> <3359F724933DFD458579D24EAC769098857A51DC@Redwood.usa.awardsolutions.com> <51421CB9.1080100@gmail.com> <514223C4.8010905@gmail.com> <3359F724933DFD458579D24EAC769098857A52C0@Redwood.usa.awardsolutions.com> <5142273A.3000406@gmail.com> In-Reply-To: <5142273A.3000406@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: "Kent Leung \(kleung\)" , Mobile IPv4 Mailing List 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2013 19:43:25 -0000 Yes. HA inserts its timestamp in the high 32 bits of the RRP ID for the MR to sy= nchronize itself. Since the MR timer failed, the MR can still use the timestamp returned in t= he RRP with code 133 and sends a second RRQ. It should succeed. May be you need to make sure that the MR implementation does not screw up b= ecause its time has failed. I do NOT believe there is any security issue in there.=20 The ID field is protected by the MN-HA Authentication Extension. Best Regards, Ahmad -----Original Message----- From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com]=20 Sent: Thursday, March 14, 2013 2:39 PM To: Ahmad Muhanna Cc: Kent Leung (kleung); Mobile IPv4 Mailing List Subject: Re: [Mip4] Does MIP support RegReq authentication without having t= o do timekeeping? Le 14/03/2013 20:36, Ahmad Muhanna a =E9crit : > Yep. I think what Kent said makes sense. MR will use the timestamp=20 > returned in the RRP with code 133 and the second RRQ should work just=20 > fine. Sorry for my naivity, but does the RREP contain a timestamp that the MR sho= uld put back in the RREQ? If yes - is that secure? Alex > > I guess no need to change anything then :-) > > Best Regards, Ahmad > > > -----Original Message----- From: Kent Leung (kleung)=20 > [mailto:kleung@cisco.com] Sent: Thursday, March 14, 2013 2:32 PM To: > Alexandru Petrescu Cc: Ahmad Muhanna; Mobile IPv4 Mailing List > Subject: RE: [Mip4] Does MIP support RegReq authentication without=20 > having to do timekeeping? > > I assumed that you had an MR that could do that. I'm not aware of any=20 > MR vendor that will maintain the timestamp state after recovering from=20 > a failure. > > On your original issue, wouldn't the re-registration succeed after the=20 > HA replies with code 133? It would take two registration messages from=20 > MR so it takes a little longer. > > Kent > > -----Original Message----- From: Alexandru Petrescu=20 > [mailto:alexandru.petrescu@gmail.com] Sent: Thursday, March 14, 2013 > 12:24 PM To: Kent Leung (kleung) Cc: Ahmad Muhanna; Mobile IPv4=20 > Mailing List Subject: Re: [Mip4] Does MIP support RegReq=20 > authentication without having to do timekeeping? > > Le 14/03/2013 20:20, Kent Leung (kleung) a =E9crit : >> Hi Alex. The nonce method is specified in the Mobile IP RFCs. But I'm=20 >> not sure if any vendor supports that. If #2 works, that should=20 >> address you issue. > > This is something we should implement on the MR side. Do you think=20 > the HA side already does it (I doubt?)? > > Alex > >> >> Kent >> >> -----Original Message----- From: mip4-bounces@ietf.org=20 >> [mailto:mip4-bounces@ietf.org] On Behalf Of Alexandru Petrescu >> Sent: Thursday, March 14, 2013 11:54 AM To: Ahmad Muhanna Cc: >> Mobile IPv4 Mailing List Subject: Re: [Mip4] Does MIP support RegReq=20 >> authentication without having to do timekeeping? >> >> Sounds reasonable to use timestamp as usual and if it fails then try=20 >> the nonce... but... >> >> Does this behaviour require modification of the HA? (we are not able=20 >> to modify it, but we can modify the MR). >> >> Le 14/03/2013 19:44, Ahmad Muhanna a =E9crit : >>> Hi Alex, >>> >>> As far as I recall, RFC2002 and all updates afterwards, allow the=20 >>> use of nonce. Basically like a challenge. >>> >>>> From implementation prospective; I would allow both to coexist as=20 >>>> follows: >>> 1. Both HA and MR uses timestamp as normal and no issue there. >> >> Yes. >> >>> 2. When the MR fails or start NOT to have a valid time, the MR=20 >>> should have remembered the last RRP ID which is based on timestamp =20 >>> and use that for Re-Registration. >> >> Ok, this could be done. >> >>> 3. At the HA, it should check timestamp first, if it passes then=20 >>> timestamp continues to work; if it fails, the HA should check the=20 >>> Re-Registration ID against the last ID that was sent in the last=20 >>> RRP, if it is the same, the HA should allow the RRP to go through. >> >> This is a modification to the HA implementation, isn't it? >> >> Alex >> >>> >>> I Hope this helps! >>> >>> Cheers! >>> >>> Best Regards, Ahmad >>> >>> -----Original Message----- From: mip4-bounces@ietf.org=20 >>> [mailto:mip4-bounces@ietf.org] On Behalf Of Alexandru Petrescu >>> Sent: Thursday, March 14, 2013 12:21 PM To: Mobile IPv4 Mailing List=20 >>> Subject: [Mip4] Does MIP support RegReq authentication without=20 >>> having to do timekeeping? >>> >>> MIP4 participants, >>> >>> I would like to learn whether Mobile IPv4 spec supports an=20 >>> authentication scheme for RegReq/RegRep which does not rely on=20 >>> timekeeping. >>> >>> Let me explain why. >>> >>> We use a Mobile Router in a moving network that gets connected to=20 >>> the Home Agent. The Mobile Router's power supply may be turned off=20 >>> (its battery dies out after an extended period of inactivity, like=20 >>> in a vehicle). At that point the MR looses its time. >>> >>> When it finally wakes up, it has to perform a Registration Req/Rep=20 >>> with the HA, without assuming that its time is correct. >>> Or, the MIP4 regreq/regrep HA implementation that we use seems to=20 >>> rely on having the right time, otherwise the registration fails. >>> >>> Under these conditions, is it possible to use an auth mechanism=20 >>> which does not rely on timekeeping? >>> >>> Alex >>> >>> -- 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/ >> >> > > > > From kleung@cisco.com Thu Mar 14 12:47:03 2013 Return-Path: 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 E488711E8231 for ; Thu, 14 Mar 2013 12:47:03 -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 TQcFGBCt4uJ2 for ; Thu, 14 Mar 2013 12:47:02 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 57E6611E819E for ; Thu, 14 Mar 2013 12:47:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1637; q=dns/txt; s=iport; t=1363290422; x=1364500022; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=W6Cghb6PTcgs5+5KZMB2p1Onm59EbyMrmGZNg8lAXT4=; b=fiwBHDIEtb7lnanBeEKIIXS0G3ZqxvEvujOePOJ4abvF1BKx/swoTBOq L+pfMNnbCIe1/3YejYJKbMEAbvdWGWmIzZb1X+qZOI53OuWkUv+2LsUHS vQbxHV4barzSiyPQgG8M41N12v1hVqfgiP3P5eGcevWyzh8qJAafX2hlv U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAE4oQlGtJV2a/2dsb2JhbABDxQKBZRZ0gisBAQEDAQEBAWsXBAIBCBEEAQELHQcnCxQJCAIEARIIAYgFBgzBao5lMwUGgllhA4g+nxyBVIE2gig X-IronPort-AV: E=Sophos;i="4.84,846,1355097600"; d="scan'208";a="187594976" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-8.cisco.com with ESMTP; 14 Mar 2013 19:47:01 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r2EJl1jX022229 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 14 Mar 2013 19:47:01 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.8]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.02.0318.004; Thu, 14 Mar 2013 14:47:01 -0500 From: "Kent Leung (kleung)" To: Alexandru Petrescu , "mip4@ietf.org" Thread-Topic: [Mip4] Does MIP support RegReq authentication without having to do timekeeping? Thread-Index: AQHOIOVj5IvDl6+vSUiwtmVfOnfckpilj5BAgABVXgD//6zD0IAAVrCA//+sqlCAAFRfgP//rJ+w Date: Thu, 14 Mar 2013 19:47:00 +0000 Message-ID: References: <514206FE.7050807@gmail.com> <3359F724933DFD458579D24EAC769098857A51DC@Redwood.usa.awardsolutions.com> <51421CB9.1080100@gmail.com> <514223C4.8010905@gmail.com> <514226A9.9020700@gmail.com> <51422787.5060509@gmail.com> In-Reply-To: <51422787.5060509@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 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2013 19:47:04 -0000 Hmm, I'm not clear with your response. Let's assume the following scenario. 1. MR sends initial RRQ1 (time=3Da) to HA 2. HA sends RRP1 (time=3Db) with code 133 3. MR sends RRQ2 (time=3Db+) 4. HA sends RRP2(time=3Db+) =3D> registration successful 5. After MR recovers from failure, MR sends RRQ3(time=3Dc) 6. HA sends RRP3(time=3Dd) with code 133 7. MR sends RRQ4(time=3Dd+) 8. HA sends RRP4(time=3Dd+) =3D> reregistration successful We would need to confirm if #6 happens properly for a specific vendor. :) B= ut 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 Ale= xandru Petrescu Sent: Thursday, March 14, 2013 12:40 PM To: mip4@ietf.org Subject: Re: [Mip4] Does MIP support RegReq authentication without having t= o do timekeeping? Le 14/03/2013 20:38, Kent Leung (kleung) a =E9crit : > > 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=20 > 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 197= 0. 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/ From alexandru.petrescu@gmail.com Thu Mar 14 12:55:10 2013 Return-Path: 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 1166211E825E for ; Thu, 14 Mar 2013 12:55:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.945 X-Spam-Level: X-Spam-Status: No, score=-9.945 tagged_above=-999 required=5 tests=[AWL=0.304, 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 7hfFdJkLNPhb for ; Thu, 14 Mar 2013 12:55:09 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) by ietfa.amsl.com (Postfix) with ESMTP id 4A85911E8245 for ; Thu, 14 Mar 2013 12:55:08 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id r2EJt2Mu005208 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 14 Mar 2013 20:55:02 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r2EJt2vo026236; Thu, 14 Mar 2013 20:55:02 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.86.3]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r2EJsxMj030272; Thu, 14 Mar 2013 20:55:01 +0100 Message-ID: <51422AF5.1080509@gmail.com> Date: Thu, 14 Mar 2013 20:54:29 +0100 From: Alexandru Petrescu 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 References: <514206FE.7050807@gmail.com> <3359F724933DFD458579D24EAC769098857A51DC@Redwood.usa.awardsolutions.com> <51421CB9.1080100@gmail.com> <514223C4.8010905@gmail.com> <3359F724933DFD458579D24EAC769098857A52C0@Redwood.usa.awardsolutions.com> In-Reply-To: <3359F724933DFD458579D24EAC769098857A52C0@Redwood.usa.awardsolutions.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "Kent Leung \(kleung\)" , Mobile IPv4 Mailing List 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2013 19:55:10 -0000 Le 14/03/2013 20:36, Ahmad Muhanna a écrit : > Yep. I think what Kent said makes sense. MR will use the timestamp > returned in the RRP with code 133 and the second RRQ should work just > fine. Is this timestamp in RREP the 'Identification' field shown by wireshark? Alex > > I guess no need to change anything then :-) > > Best Regards, Ahmad > > > -----Original Message----- From: Kent Leung (kleung) > [mailto:kleung@cisco.com] Sent: Thursday, March 14, 2013 2:32 PM To: > Alexandru Petrescu Cc: Ahmad Muhanna; Mobile IPv4 Mailing List > Subject: RE: [Mip4] Does MIP support RegReq authentication without > having to do timekeeping? > > I assumed that you had an MR that could do that. I'm not aware of any > MR vendor that will maintain the timestamp state after recovering > from a failure. > > On your original issue, wouldn't the re-registration succeed after > the HA replies with code 133? It would take two registration messages > from MR so it takes a little longer. > > Kent > > -----Original Message----- From: Alexandru Petrescu > [mailto:alexandru.petrescu@gmail.com] Sent: Thursday, March 14, 2013 > 12:24 PM To: Kent Leung (kleung) Cc: Ahmad Muhanna; Mobile IPv4 > Mailing List Subject: Re: [Mip4] Does MIP support RegReq > authentication without having to do timekeeping? > > Le 14/03/2013 20:20, Kent Leung (kleung) a écrit : >> Hi Alex. The nonce method is specified in the Mobile IP RFCs. But >> I'm not sure if any vendor supports that. If #2 works, that should >> address you issue. > > This is something we should implement on the MR side. Do you think > the HA side already does it (I doubt?)? > > Alex > >> >> Kent >> >> -----Original Message----- From: mip4-bounces@ietf.org >> [mailto:mip4-bounces@ietf.org] On Behalf Of Alexandru Petrescu >> Sent: Thursday, March 14, 2013 11:54 AM To: Ahmad Muhanna Cc: >> Mobile IPv4 Mailing List Subject: Re: [Mip4] Does MIP support >> RegReq authentication without having to do timekeeping? >> >> Sounds reasonable to use timestamp as usual and if it fails then >> try the nonce... but... >> >> Does this behaviour require modification of the HA? (we are not >> able to modify it, but we can modify the MR). >> >> Le 14/03/2013 19:44, Ahmad Muhanna a écrit : >>> Hi Alex, >>> >>> As far as I recall, RFC2002 and all updates afterwards, allow the >>> use of nonce. Basically like a challenge. >>> >>>> From implementation prospective; I would allow both to coexist >>>> as follows: >>> 1. Both HA and MR uses timestamp as normal and no issue there. >> >> Yes. >> >>> 2. When the MR fails or start NOT to have a valid time, the MR >>> should have remembered the last RRP ID which is based on >>> timestamp and use that for Re-Registration. >> >> Ok, this could be done. >> >>> 3. At the HA, it should check timestamp first, if it passes then >>> timestamp continues to work; if it fails, the HA should check >>> the Re-Registration ID against the last ID that was sent in the >>> last RRP, if it is the same, the HA should allow the RRP to go >>> through. >> >> This is a modification to the HA implementation, isn't it? >> >> Alex >> >>> >>> I Hope this helps! >>> >>> Cheers! >>> >>> 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 12:21 PM To: Mobile IPv4 Mailing >>> List Subject: [Mip4] Does MIP support RegReq authentication >>> without having to do timekeeping? >>> >>> MIP4 participants, >>> >>> I would like to learn whether Mobile IPv4 spec supports an >>> authentication scheme for RegReq/RegRep which does not rely on >>> timekeeping. >>> >>> Let me explain why. >>> >>> We use a Mobile Router in a moving network that gets connected to >>> the Home Agent. The Mobile Router's power supply may be turned >>> off (its battery dies out after an extended period of inactivity, >>> like in a vehicle). At that point the MR looses its time. >>> >>> When it finally wakes up, it has to perform a Registration >>> Req/Rep with the HA, without assuming that its time is correct. >>> Or, the MIP4 regreq/regrep HA implementation that we use seems to >>> rely on having the right time, otherwise the registration fails. >>> >>> Under these conditions, is it possible to use an auth mechanism >>> which does not rely on timekeeping? >>> >>> Alex >>> >>> -- 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/ >> >> > > > > From alexandru.petrescu@gmail.com Thu Mar 14 12:58:40 2013 Return-Path: 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 0D62F11E80F2 for ; Thu, 14 Mar 2013 12:58:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.968 X-Spam-Level: X-Spam-Status: No, score=-9.968 tagged_above=-999 required=5 tests=[AWL=0.281, 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 VthOvQxTIwdu for ; Thu, 14 Mar 2013 12:58:39 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) by ietfa.amsl.com (Postfix) with ESMTP id BB9D311E814D for ; Thu, 14 Mar 2013 12:58:38 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id r2EJwajm006154 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 14 Mar 2013 20:58:36 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r2EJwZor026624; Thu, 14 Mar 2013 20:58:35 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.86.3]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r2EJwXwf031152; Thu, 14 Mar 2013 20:58:35 +0100 Message-ID: <51422BCB.30409@gmail.com> Date: Thu, 14 Mar 2013 20:58:03 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: "Kent Leung (kleung)" References: <514206FE.7050807@gmail.com> <3359F724933DFD458579D24EAC769098857A51DC@Redwood.usa.awardsolutions.com> <51421CB9.1080100@gmail.com> <514223C4.8010905@gmail.com> <514226A9.9020700@gmail.com> <51422787.5060509@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2013 19:58:40 -0000 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/ > > From amuhanna@awardsolutions.com Thu Mar 14 12:59:29 2013 Return-Path: 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 7119F11E8173 for ; Thu, 14 Mar 2013 12:59:29 -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 BdC9tdEeq8Ne for ; Thu, 14 Mar 2013 12:59:28 -0700 (PDT) Received: from exprod8og117.obsmtp.com (exprod8og117.obsmtp.com [64.18.3.34]) by ietfa.amsl.com (Postfix) with ESMTP id 6085E11E8166 for ; Thu, 14 Mar 2013 12:59:28 -0700 (PDT) Received: from mail.awardsolutions.com ([66.142.250.98]) (using TLSv1) by exprod8ob117.postini.com ([64.18.7.12]) with SMTP ID DSNKUUIsHiBV2I4S3tnpYRpZ7X3q28mP9ktI@postini.com; Thu, 14 Mar 2013 12:59:28 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 14:59:26 -0500 From: Ahmad Muhanna To: Alexandru Petrescu Thread-Topic: [Mip4] Does MIP support RegReq authentication without having to do timekeeping? Thread-Index: AQHOIO3S7rndUjrH0UWKuVF8jTknMJilmiEw Date: Thu, 14 Mar 2013 19:59:24 +0000 Message-ID: <3359F724933DFD458579D24EAC769098857A537A@Redwood.usa.awardsolutions.com> References: <514206FE.7050807@gmail.com> <3359F724933DFD458579D24EAC769098857A51DC@Redwood.usa.awardsolutions.com> <51421CB9.1080100@gmail.com> <514223C4.8010905@gmail.com> <3359F724933DFD458579D24EAC769098857A52C0@Redwood.usa.awardsolutions.com> <51422AF5.1080509@gmail.com> In-Reply-To: <51422AF5.1080509@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: "Kent Leung \(kleung\)" , Mobile IPv4 Mailing List 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2013 19:59:29 -0000 Yes. This ID is 64 bits. The higher order 32 bits is the time in seconds and the lower 32 bits is th= e fraction of the second. However, some implementation uses JUST a random n= umber. In the Reply with code 133:=20 The HA inserts its timestamp in the higher order 32 bits of the RRP ID and = copies the lower 32 bits from the one in the RRQ. It has been a while but I believe that is correct! :-) Best Regards, Ahmad -----Original Message----- From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com]=20 Sent: Thursday, March 14, 2013 2:54 PM To: Ahmad Muhanna Cc: Kent Leung (kleung); Mobile IPv4 Mailing List Subject: Re: [Mip4] Does MIP support RegReq authentication without having t= o do timekeeping? Le 14/03/2013 20:36, Ahmad Muhanna a =E9crit : > Yep. I think what Kent said makes sense. MR will use the timestamp=20 > returned in the RRP with code 133 and the second RRQ should work just=20 > fine. Is this timestamp in RREP the 'Identification' field shown by wireshark? Alex > > I guess no need to change anything then :-) > > Best Regards, Ahmad > > > -----Original Message----- From: Kent Leung (kleung)=20 > [mailto:kleung@cisco.com] Sent: Thursday, March 14, 2013 2:32 PM To: > Alexandru Petrescu Cc: Ahmad Muhanna; Mobile IPv4 Mailing List > Subject: RE: [Mip4] Does MIP support RegReq authentication without=20 > having to do timekeeping? > > I assumed that you had an MR that could do that. I'm not aware of any=20 > MR vendor that will maintain the timestamp state after recovering from=20 > a failure. > > On your original issue, wouldn't the re-registration succeed after the=20 > HA replies with code 133? It would take two registration messages from=20 > MR so it takes a little longer. > > Kent > > -----Original Message----- From: Alexandru Petrescu=20 > [mailto:alexandru.petrescu@gmail.com] Sent: Thursday, March 14, 2013 > 12:24 PM To: Kent Leung (kleung) Cc: Ahmad Muhanna; Mobile IPv4=20 > Mailing List Subject: Re: [Mip4] Does MIP support RegReq=20 > authentication without having to do timekeeping? > > Le 14/03/2013 20:20, Kent Leung (kleung) a =E9crit : >> Hi Alex. The nonce method is specified in the Mobile IP RFCs. But I'm=20 >> not sure if any vendor supports that. If #2 works, that should=20 >> address you issue. > > This is something we should implement on the MR side. Do you think=20 > the HA side already does it (I doubt?)? > > Alex > >> >> Kent >> >> -----Original Message----- From: mip4-bounces@ietf.org=20 >> [mailto:mip4-bounces@ietf.org] On Behalf Of Alexandru Petrescu >> Sent: Thursday, March 14, 2013 11:54 AM To: Ahmad Muhanna Cc: >> Mobile IPv4 Mailing List Subject: Re: [Mip4] Does MIP support RegReq=20 >> authentication without having to do timekeeping? >> >> Sounds reasonable to use timestamp as usual and if it fails then try=20 >> the nonce... but... >> >> Does this behaviour require modification of the HA? (we are not able=20 >> to modify it, but we can modify the MR). >> >> Le 14/03/2013 19:44, Ahmad Muhanna a =E9crit : >>> Hi Alex, >>> >>> As far as I recall, RFC2002 and all updates afterwards, allow the=20 >>> use of nonce. Basically like a challenge. >>> >>>> From implementation prospective; I would allow both to coexist as=20 >>>> follows: >>> 1. Both HA and MR uses timestamp as normal and no issue there. >> >> Yes. >> >>> 2. When the MR fails or start NOT to have a valid time, the MR=20 >>> should have remembered the last RRP ID which is based on timestamp =20 >>> and use that for Re-Registration. >> >> Ok, this could be done. >> >>> 3. At the HA, it should check timestamp first, if it passes then=20 >>> timestamp continues to work; if it fails, the HA should check the=20 >>> Re-Registration ID against the last ID that was sent in the last=20 >>> RRP, if it is the same, the HA should allow the RRP to go through. >> >> This is a modification to the HA implementation, isn't it? >> >> Alex >> >>> >>> I Hope this helps! >>> >>> Cheers! >>> >>> Best Regards, Ahmad >>> >>> -----Original Message----- From: mip4-bounces@ietf.org=20 >>> [mailto:mip4-bounces@ietf.org] On Behalf Of Alexandru Petrescu >>> Sent: Thursday, March 14, 2013 12:21 PM To: Mobile IPv4 Mailing List=20 >>> Subject: [Mip4] Does MIP support RegReq authentication without=20 >>> having to do timekeeping? >>> >>> MIP4 participants, >>> >>> I would like to learn whether Mobile IPv4 spec supports an=20 >>> authentication scheme for RegReq/RegRep which does not rely on=20 >>> timekeeping. >>> >>> Let me explain why. >>> >>> We use a Mobile Router in a moving network that gets connected to=20 >>> the Home Agent. The Mobile Router's power supply may be turned off=20 >>> (its battery dies out after an extended period of inactivity, like=20 >>> in a vehicle). At that point the MR looses its time. >>> >>> When it finally wakes up, it has to perform a Registration Req/Rep=20 >>> with the HA, without assuming that its time is correct. >>> Or, the MIP4 regreq/regrep HA implementation that we use seems to=20 >>> rely on having the right time, otherwise the registration fails. >>> >>> Under these conditions, is it possible to use an auth mechanism=20 >>> which does not rely on timekeeping? >>> >>> Alex >>> >>> -- 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/ >> >> > > > > From kleung@cisco.com Thu Mar 14 12:59:42 2013 Return-Path: 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 B6DC711E8173 for ; Thu, 14 Mar 2013 12:59:42 -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 f+sZ2LbgsJre for ; Thu, 14 Mar 2013 12:59:42 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 8F28C11E8166 for ; Thu, 14 Mar 2013 12:59:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2372; q=dns/txt; s=iport; t=1363291181; x=1364500781; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Kygv0jrvdgJmV1fn0x7kvBGK5uApH0jmIZUOjARvSHE=; b=cAT95ho7gDpvNJ2NA8d6o+hW3Bo336LOwfFMU4oqGzKoAvsaUkM9Xq4M 9HvYeNGZPdqXCigE8yZ4E/rpfOCPYyKsYS0kGBiDy3m8zPtm7eRsQwL3w xrRkXKG4+OYbEK1+QY3rwR7xsa+yK5GUPN2N9+wXWWsUVNhwh8k+GXLj4 s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAHMrQlGtJV2Y/2dsb2JhbABDxQKBZRZ0gisBAQEDAQEBAWsLBQcEAgEIEQQBAQsdByEGCxQJCAIEDgUIAYd5AwkGDLgJDYlbjEyCGSYLAgUGgllhA4g+jDqNSIUagVSBNoIo X-IronPort-AV: E=Sophos;i="4.84,846,1355097600"; d="scan'208";a="184604309" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-9.cisco.com with ESMTP; 14 Mar 2013 19:59:41 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r2EJxfAC020968 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 14 Mar 2013 19:59:41 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.8]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.02.0318.004; Thu, 14 Mar 2013 14:59:40 -0500 From: "Kent Leung (kleung)" To: Alexandru Petrescu Thread-Topic: [Mip4] Does MIP support RegReq authentication without having to do timekeeping? Thread-Index: AQHOIOVj5IvDl6+vSUiwtmVfOnfckpilj5BAgABVXgD//6zD0IAAVrCA//+sqlCAAFRfgP//rJ+wAAsO3oAACm8KMA== Date: Thu, 14 Mar 2013 19:59:39 +0000 Message-ID: References: <514206FE.7050807@gmail.com> <3359F724933DFD458579D24EAC769098857A51DC@Redwood.usa.awardsolutions.com> <51421CB9.1080100@gmail.com> <514223C4.8010905@gmail.com> <514226A9.9020700@gmail.com> <51422787.5060509@gmail.com> <51422BCB.30409@gmail.com> In-Reply-To: <51422BCB.30409@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" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2013 19:59:42 -0000 The RRP1 cannot be faked since the MN-HA Auth Ext protects the message. Kent -----Original Message----- From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com]=20 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 t= o do timekeeping? Le 14/03/2013 20:47, Kent Leung (kleung) a =E9crit : > Hmm, I'm not clear with your response. > > Let's assume the following scenario. > > 1. MR sends initial RRQ1 (time=3Da) to HA 2. HA sends RRP1 (time=3Db) wit= h=20 > code 133 Ok. Do you think MR receiving this RRP1 will be able to safele verify it i= s legitimate? Or is it possible than an attacker HA fakes this RRP1 messag= e? > 3. MR sends RRQ2 (time=3Db+) > 4. HA sends RRP2(time=3Db+) =3D> registration successful 5. After MR=20 > recovers from failure, MR sends RRQ3(time=3Dc) 6. HA sends RRP3(time=3Dd)= =20 > with code 133 7. MR sends RRQ4(time=3Dd+) 8. HA sends RRP4(time=3Dd+) =3D= >=20 > 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=20 > 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 =E9crit : >> >> 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=20 >> 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 ti= me (vehicle in garage for several weeks in winter time). It now has year 1= 970. > > Alex > >> >> Kent >> >> > > > -- > Mip4 mailing list: Mip4@ietf.org > Web interface: https://www.ietf.org/mailman/listinfo/mip4 > Charter page:=20 > http://www.ietf.org/html.charters/mip4-charter.html > Supplemental site: http://www.mip4.org/ > > From alexandru.petrescu@gmail.com Thu Mar 14 13:03:56 2013 Return-Path: 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 E15D411E80D7 for ; Thu, 14 Mar 2013 13:03:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.988 X-Spam-Level: X-Spam-Status: No, score=-9.988 tagged_above=-999 required=5 tests=[AWL=0.261, 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 TtAf67zO+N1g for ; Thu, 14 Mar 2013 13:03:55 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) by ietfa.amsl.com (Postfix) with ESMTP id 5939111E80F2 for ; Thu, 14 Mar 2013 13:03:55 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id r2EK3p9s007683 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 14 Mar 2013 21:03:52 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r2EK3p7c027401; Thu, 14 Mar 2013 21:03:51 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.86.3]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r2EK3n2F032731; Thu, 14 Mar 2013 21:03:50 +0100 Message-ID: <51422D07.9070901@gmail.com> Date: Thu, 14 Mar 2013 21:03:19 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: "Kent Leung (kleung)" References: <514206FE.7050807@gmail.com> <3359F724933DFD458579D24EAC769098857A51DC@Redwood.usa.awardsolutions.com> <51421CB9.1080100@gmail.com> <514223C4.8010905@gmail.com> <514226A9.9020700@gmail.com> <51422787.5060509@gmail.com> <51422BCB.30409@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2013 20:03:57 -0000 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/ >> >> > > > > From kleung@cisco.com Thu Mar 14 13:07:21 2013 Return-Path: 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 3004911E81DC for ; Thu, 14 Mar 2013 13:07:21 -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 U2GkM-QJSiKg for ; Thu, 14 Mar 2013 13:07:20 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 32FB011E80D7 for ; Thu, 14 Mar 2013 13:07:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3325; q=dns/txt; s=iport; t=1363291640; x=1364501240; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=CnA5nEYtaxluIbEj2NzoouNPUTT3rGMgon0XyF5tigs=; b=aLvrsrCzPWnjghLJ724jikEN3qzfnv0aknWi7znJxdj2SMD1LQCQnERB EKtqfXYlyoVStxa07kH2ShRjfo6jqChd/8JKZYSHno2FZrpIBQVJpK3Gq nTVO+KIq+AVLBVfCeCpTIrz3KJ8BD17lLo0Fqy6c9clqaktm5LW7XAsWk 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAAItQlGtJV2c/2dsb2JhbABDxQKBZRZ0gisBAQEDAQEBAWQHCwwEAgEIEQQBAQsdByEGCxQJCAIEDgUIAYd5AwkGDLgMDYlbjEyCGSYLAgUGgllhA4g+jDqNSIUagVSBNoIo X-IronPort-AV: E=Sophos;i="4.84,846,1355097600"; d="scan'208";a="184607335" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-9.cisco.com with ESMTP; 14 Mar 2013 20:07:19 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r2EK7JCx011041 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 14 Mar 2013 20:07:19 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.8]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.02.0318.004; Thu, 14 Mar 2013 15:07:19 -0500 From: "Kent Leung (kleung)" To: Alexandru Petrescu Thread-Topic: [Mip4] Does MIP support RegReq authentication without having to do timekeeping? Thread-Index: AQHOIOVj5IvDl6+vSUiwtmVfOnfckpilj5BAgABVXgD//6zD0IAAVrCA//+sqlCAAFRfgP//rJ+wAAsO3oAACm8KMP//rgCAgABTfsA= Date: Thu, 14 Mar 2013 20:07:18 +0000 Message-ID: References: <514206FE.7050807@gmail.com> <3359F724933DFD458579D24EAC769098857A51DC@Redwood.usa.awardsolutions.com> <51421CB9.1080100@gmail.com> <514223C4.8010905@gmail.com> <514226A9.9020700@gmail.com> <51422787.5060509@gmail.com> <51422BCB.30409@gmail.com> <51422D07.9070901@gmail.com> In-Reply-To: <51422D07.9070901@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" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2013 20:07:21 -0000 The Authenticator value is different for RRQ vs RRP. The extension carries = different value based on the message. The way to calculate the value requir= es the shared key between MR and HA. So it's not easy for an attacker to kn= ow the key. Kent -----Original Message----- From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com]=20 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 t= o do timekeeping? Le 14/03/2013 20:59, Kent Leung (kleung) a =E9crit : > The RRP1 cannot be faked since the MN-HA Auth Ext protects the=20 > message. I strongly doubt that. Were it so, then the same extension could protect t= he first RRQ1 as well. I believe it is possible for an attacker HA to intercept the initial RRQ1(t= ime=3D1970), and the RRP1(time=3D2013) and fake a RREP towards the MR.=20 No? Alex > > Kent > > -----Original Message----- From: Alexandru Petrescu=20 > [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=20 > timekeeping? > > Le 14/03/2013 20:47, Kent Leung (kleung) a =E9crit : >> Hmm, I'm not clear with your response. >> >> Let's assume the following scenario. >> >> 1. MR sends initial RRQ1 (time=3Da) to HA 2. HA sends RRP1 (time=3Db)=20 >> with code 133 > > Ok. Do you think MR receiving this RRP1 will be able to safele verify=20 > it is legitimate? Or is it possible than an attacker HA fakes this=20 > RRP1 message? > >> 3. MR sends RRQ2 (time=3Db+) 4. HA sends RRP2(time=3Db+) =3D> registrati= on=20 >> successful 5. After MR recovers from failure, MR sends RRQ3(time=3Dc)=20 >> 6. HA sends RRP3(time=3Dd) with code 133 7. MR sends RRQ4(time=3Dd+) 8.= =20 >> HA sends RRP4(time=3Dd+) =3D> reregistration successful > > These latter steps 3-8 make sense. > > Alex > >> >> We would need to confirm if #6 happens properly for a specific=20 >> vendor. :) But I would expect #7 should happen if code 133 is=20 >> received. >> >> Kent >> >> -----Original Message----- From: mip4-bounces@ietf.org=20 >> [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=20 >> do timekeeping? >> >> Le 14/03/2013 20:38, Kent Leung (kleung) a =E9crit : >>> >>> 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=20 >>> messages). But the second message will also be refused by the HA=20 >>> 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=20 >> 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/ >> >> > > > > From alexandru.petrescu@gmail.com Thu Mar 14 13:12:56 2013 Return-Path: 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 4341011E8223 for ; Thu, 14 Mar 2013 13:12:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.993 X-Spam-Level: X-Spam-Status: No, score=-9.993 tagged_above=-999 required=5 tests=[AWL=0.256, 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 hid2A0rfoTMp for ; Thu, 14 Mar 2013 13:12:54 -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 33EBC21F8DF1 for ; Thu, 14 Mar 2013 13:12:53 -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 r2EKCjPF025170 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 14 Mar 2013 21:12:45 +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 r2EKCirq028583; Thu, 14 Mar 2013 21:12:45 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.86.3]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r2EKCgom028604; Thu, 14 Mar 2013 21:12:44 +0100 Message-ID: <51422F1C.7000705@gmail.com> Date: Thu, 14 Mar 2013 21:12:12 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: "Kent Leung (kleung)" References: <514206FE.7050807@gmail.com> <3359F724933DFD458579D24EAC769098857A51DC@Redwood.usa.awardsolutions.com> <51421CB9.1080100@gmail.com> <514223C4.8010905@gmail.com> <514226A9.9020700@gmail.com> <51422787.5060509@gmail.com> <51422BCB.30409@gmail.com> <51422D07.9070901@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2013 20:12:56 -0000 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/ >>> >>> >> >> >> >> > > > > From kleung@cisco.com Thu Mar 14 13:15:27 2013 Return-Path: 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 AC66A11E81B5 for ; Thu, 14 Mar 2013 13:15:27 -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 4UfgccY4StIC for ; Thu, 14 Mar 2013 13:15:26 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 9CAAB11E81A8 for ; Thu, 14 Mar 2013 13:15:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4202; q=dns/txt; s=iport; t=1363292126; x=1364501726; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=1jzkNj5RBhcYaCY2jH7PhL3hNwGwND+U0QhRibeY8kg=; b=nA/1Gjz3s04D7uxbc7Y1BlEES1nMNpt+NG66w01T4RdNKCm1vRiucVLJ gUN3AZo32pf0aiu+4JAYsbCsqHvY+7oOFE0KofUtTY75QKMLUH/f6yYO5 FtPTY7B+SWyuE/bPRX3nYZl044puueOTqTqPvG4/RglfwwGL52y6FVzvK U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAGsvQlGtJV2c/2dsb2JhbABDxQKBZRZ0gisBAQEDAQEBAWQHCwwEAgEIEQQBAQsdByEGCxQJCAIEDgUIAYd5AwkGDLgIDYlbjEyCGSYLAgUGgllhA4g+jDqNSIUagVSBNoIo X-IronPort-AV: E=Sophos;i="4.84,846,1355097600"; d="scan'208";a="187577049" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-2.cisco.com with ESMTP; 14 Mar 2013 20:15:07 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r2EKF6OC017660 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 14 Mar 2013 20:15:06 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.8]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.02.0318.004; Thu, 14 Mar 2013 15:15:06 -0500 From: "Kent Leung (kleung)" To: Alexandru Petrescu Thread-Topic: [Mip4] Does MIP support RegReq authentication without having to do timekeeping? Thread-Index: AQHOIOVj5IvDl6+vSUiwtmVfOnfckpilj5BAgABVXgD//6zD0IAAVrCA//+sqlCAAFRfgP//rJ+wAAsO3oAACm8KMP//rgCAgABTfsD//679AIAAU29A Date: Thu, 14 Mar 2013 20:15:06 +0000 Message-ID: References: <514206FE.7050807@gmail.com> <3359F724933DFD458579D24EAC769098857A51DC@Redwood.usa.awardsolutions.com> <51421CB9.1080100@gmail.com> <514223C4.8010905@gmail.com> <514226A9.9020700@gmail.com> <51422787.5060509@gmail.com> <51422BCB.30409@gmail.com> <51422D07.9070901@gmail.com> <51422F1C.7000705@gmail.com> In-Reply-To: <51422F1C.7000705@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" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2013 20:15:27 -0000 Timestamp is one of the fields in the message that is protected by key usin= g a hash function. Since we are at IETF, let's talk offline as this seems t= o need some clarification and hand waving. :) Kent=20 -----Original Message----- From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com]=20 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 t= o do timekeeping? Le 14/03/2013 21:07, Kent Leung (kleung) a =E9crit : > The Authenticator value is different for RRQ vs RRP. The extension=20 > carries different value based on the message. The way to calculate the=20 > value requires the shared key between MR and HA. So it's not easy for=20 > 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=20 > [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=20 > timekeeping? > > Le 14/03/2013 20:59, Kent Leung (kleung) a =E9crit : >> The RRP1 cannot be faked since the MN-HA Auth Ext protects the=20 >> message. > > I strongly doubt that. Were it so, then the same extension could=20 > protect the first RRQ1 as well. > > I believe it is possible for an attacker HA to intercept the initial=20 > RRQ1(time=3D1970), and the RRP1(time=3D2013) and fake a RREP towards the= =20 > MR. No? > > Alex > >> >> Kent >> >> -----Original Message----- From: Alexandru Petrescu=20 >> [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=20 >> do timekeeping? >> >> Le 14/03/2013 20:47, Kent Leung (kleung) a =E9crit : >>> Hmm, I'm not clear with your response. >>> >>> Let's assume the following scenario. >>> >>> 1. MR sends initial RRQ1 (time=3Da) to HA 2. HA sends RRP1 (time=3Db)=20 >>> with code 133 >> >> Ok. Do you think MR receiving this RRP1 will be able to safele=20 >> verify it is legitimate? Or is it possible than an attacker HA fakes=20 >> this RRP1 message? >> >>> 3. MR sends RRQ2 (time=3Db+) 4. HA sends RRP2(time=3Db+) =3D> registrat= ion=20 >>> successful 5. After MR recovers from failure, MR sends RRQ3(time=3Dc)=20 >>> 6. HA sends RRP3(time=3Dd) with code 133 7. MR sends RRQ4(time=3Dd+) 8.= =20 >>> HA sends RRP4(time=3Dd+) =3D> reregistration successful >> >> These latter steps 3-8 make sense. >> >> Alex >> >>> >>> We would need to confirm if #6 happens properly for a specific=20 >>> vendor. :) But I would expect #7 should happen if code 133 is=20 >>> received. >>> >>> Kent >>> >>> -----Original Message----- From: mip4-bounces@ietf.org=20 >>> [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=20 >>> having to do timekeeping? >>> >>> Le 14/03/2013 20:38, Kent Leung (kleung) a =E9crit : >>>> >>>> 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=20 >>>> messages). But the second message will also be refused by the HA=20 >>>> 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=20 >>> 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/ >>> >>> >> >> >> >> > > > > From amuhanna@awardsolutions.com Thu Mar 14 13:17:41 2013 Return-Path: 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 A41ED11E81A8 for ; Thu, 14 Mar 2013 13:17:41 -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=[AWL=0.000, 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 srDwTXU1ZVe4 for ; Thu, 14 Mar 2013 13:17:41 -0700 (PDT) Received: from exprod8og117.obsmtp.com (exprod8og117.obsmtp.com [64.18.3.34]) by ietfa.amsl.com (Postfix) with ESMTP id B3EDD11E8189 for ; Thu, 14 Mar 2013 13:17:40 -0700 (PDT) Received: from mail.awardsolutions.com ([66.142.250.98]) (using TLSv1) by exprod8ob117.postini.com ([64.18.7.12]) with SMTP ID DSNKUUIwYh8mHIeb9npjoaygpsZo3Ws+owfH@postini.com; Thu, 14 Mar 2013 13:17:40 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 15:17:38 -0500 From: Ahmad Muhanna To: "Kent Leung (kleung)" , Alexandru Petrescu Thread-Topic: [Mip4] Does MIP support RegReq authentication without having to do timekeeping? Thread-Index: AQHOIO747rndUjrH0UWKuVF8jTknMJil8QIA//+tHqA= Date: Thu, 14 Mar 2013 20:17:37 +0000 Message-ID: <3359F724933DFD458579D24EAC769098857A53E5@Redwood.usa.awardsolutions.com> References: <514206FE.7050807@gmail.com> <3359F724933DFD458579D24EAC769098857A51DC@Redwood.usa.awardsolutions.com> <51421CB9.1080100@gmail.com> <514223C4.8010905@gmail.com> <514226A9.9020700@gmail.com> <51422787.5060509@gmail.com> <51422BCB.30409@gmail.com> <51422D07.9070901@gmail.com> In-Reply-To: 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" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2013 20:17:41 -0000 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 p= ossible for modification. When the MR sends any RRQ, the MR MUST use a good random number generator a= nd 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 numb= er 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 t= he 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 RR= P ID field to the one that was used in the RRQ and they have to be equal. T= his 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 Ken= t 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 t= o 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 requir= es the shared key between MR and HA. So it's not easy for an attacker to kn= ow 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 t= o do timekeeping? Le 14/03/2013 20:59, Kent Leung (kleung) a =E9crit : > The RRP1 cannot be faked since the MN-HA Auth Ext protects the=20 > message. I strongly doubt that. Were it so, then the same extension could protect t= he first RRQ1 as well. I believe it is possible for an attacker HA to intercept the initial RRQ1(t= ime=3D1970), and the RRP1(time=3D2013) and fake a RREP towards the MR.=20 No? Alex > > Kent > > -----Original Message----- From: Alexandru Petrescu=20 > [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=20 > timekeeping? > > Le 14/03/2013 20:47, Kent Leung (kleung) a =E9crit : >> Hmm, I'm not clear with your response. >> >> Let's assume the following scenario. >> >> 1. MR sends initial RRQ1 (time=3Da) to HA 2. HA sends RRP1 (time=3Db)=20 >> with code 133 > > Ok. Do you think MR receiving this RRP1 will be able to safele verify=20 > it is legitimate? Or is it possible than an attacker HA fakes this > RRP1 message? > >> 3. MR sends RRQ2 (time=3Db+) 4. HA sends RRP2(time=3Db+) =3D> registrati= on=20 >> successful 5. After MR recovers from failure, MR sends RRQ3(time=3Dc)=20 >> 6. HA sends RRP3(time=3Dd) with code 133 7. MR sends RRQ4(time=3Dd+) 8. >> HA sends RRP4(time=3Dd+) =3D> reregistration successful > > These latter steps 3-8 make sense. > > Alex > >> >> We would need to confirm if #6 happens properly for a specific=20 >> vendor. :) But I would expect #7 should happen if code 133 is=20 >> received. >> >> Kent >> >> -----Original Message----- From: mip4-bounces@ietf.org=20 >> [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=20 >> do timekeeping? >> >> Le 14/03/2013 20:38, Kent Leung (kleung) a =E9crit : >>> >>> 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=20 >>> messages). But the second message will also be refused by the HA=20 >>> 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=20 >> 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/ From alexandru.petrescu@gmail.com Thu Mar 14 14:41:16 2013 Return-Path: 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 617CD21F8D35 for ; Thu, 14 Mar 2013 14:41:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.008 X-Spam-Level: X-Spam-Status: No, score=-10.008 tagged_above=-999 required=5 tests=[AWL=0.241, 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 Rz2AfAahcKrZ for ; Thu, 14 Mar 2013 14:41:15 -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 6B85E11E812A for ; Thu, 14 Mar 2013 14:41:14 -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 r2ELfBiT015733 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 14 Mar 2013 22:41:11 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r2ELfB7n007070; Thu, 14 Mar 2013 22:41:11 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.86.10]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r2ELf2hR020812; Thu, 14 Mar 2013 22:41:10 +0100 Message-ID: <514243D0.2090309@gmail.com> Date: Thu, 14 Mar 2013 22:40:32 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: "Kent Leung (kleung)" References: <514206FE.7050807@gmail.com> <3359F724933DFD458579D24EAC769098857A51DC@Redwood.usa.awardsolutions.com> <51421CB9.1080100@gmail.com> <514223C4.8010905@gmail.com> <514226A9.9020700@gmail.com> <51422787.5060509@gmail.com> <51422BCB.30409@gmail.com> <51422D07.9070901@gmail.com> <51422F1C.7000705@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2013 21:41:16 -0000 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/ >>>> >>>> >>> >>> >>> >>> >> >> >> >> > > > > From alexandru.petrescu@gmail.com Thu Mar 14 14:46:24 2013 Return-Path: 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 E9AC81F0D11 for ; Thu, 14 Mar 2013 14:46:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.021 X-Spam-Level: X-Spam-Status: No, score=-10.021 tagged_above=-999 required=5 tests=[AWL=0.228, 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 Pqs5k0qP4bAA for ; Thu, 14 Mar 2013 14:46:24 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) by ietfa.amsl.com (Postfix) with ESMTP id BB1111F0D09 for ; Thu, 14 Mar 2013 14:46:23 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id r2ELkM4F029924 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 14 Mar 2013 22:46:22 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r2ELkMqi007628 for ; Thu, 14 Mar 2013 22:46:22 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.86.10]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r2ELkKJ3021734 for ; Thu, 14 Mar 2013 22:46:22 +0100 Message-ID: <5142450E.7010803@gmail.com> Date: Thu, 14 Mar 2013 22:45:50 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: mip4@ietf.org References: <514206FE.7050807@gmail.com> <3359F724933DFD458579D24EAC769098857A51DC@Redwood.usa.awardsolutions.com> <51421CB9.1080100@gmail.com> <514223C4.8010905@gmail.com> <514226A9.9020700@gmail.com> <51422787.5060509@gmail.com> <51422BCB.30409@gmail.com> <51422D07.9070901@gmail.com> <3359F724933DFD458579D24EAC769098857A53E5@Redwood.usa.awardsolutions.com> In-Reply-To: <3359F724933DFD458579D24EAC769098857A53E5@Redwood.usa.awardsolutions.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2013 21:46:25 -0000 I think yes, it may be possible to come up with something that may be more secure, and without reliance on timestamps. I have to read the sequence below better. I know that in AH of IPsec for Mobile IPv6, the registration works ok (BU/BAck) without need of timestamps. IIRC. Alex Le 14/03/2013 21:17, Ahmad Muhanna a écrit : > 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/ > From kleung@cisco.com Thu Mar 14 14:47:00 2013 Return-Path: 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 ; 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 ; 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 ; 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)" To: Alexandru Petrescu 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: References: <514206FE.7050807@gmail.com> <3359F724933DFD458579D24EAC769098857A51DC@Redwood.usa.awardsolutions.com> <51421CB9.1080100@gmail.com> <514223C4.8010905@gmail.com> <514226A9.9020700@gmail.com> <51422787.5060509@gmail.com> <51422BCB.30409@gmail.com> <51422D07.9070901@gmail.com> <51422F1C.7000705@gmail.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" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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]=20 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 t= o 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 RRE= Q containing the Id copied from the RREP. Reads more like a warning to tak= e 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 M= N 13.8.9.3 with Lifetime 40, Home Address 13.8.9.3, Home Agent 13.8.9.4 Cod= e 133 " Alex Le 14/03/2013 21:15, Kent Leung (kleung) a =E9crit : > Timestamp is one of the fields in the message that is protected by key=20 > using a hash function. Since we are at IETF, let's talk offline as=20 > this seems to need some clarification and hand waving. :) > > Kent > > -----Original Message----- From: Alexandru Petrescu=20 > [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=20 > timekeeping? > > Le 14/03/2013 21:07, Kent Leung (kleung) a =E9crit : >> The Authenticator value is different for RRQ vs RRP. The extension =20 >> carries different value based on the message. The way to calculate=20 >> the value requires the shared key between MR and HA. So it's not easy=20 >> 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=20 > in the first place, for the first RREQ, without timestamp? > > Alex > >> >> Kent >> >> -----Original Message----- From: Alexandru Petrescu=20 >> [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=20 >> timekeeping? >> >> Le 14/03/2013 20:59, Kent Leung (kleung) a =E9crit : >>> The RRP1 cannot be faked since the MN-HA Auth Ext protects the=20 >>> message. >> >> I strongly doubt that. Were it so, then the same extension could=20 >> protect the first RRQ1 as well. >> >> I believe it is possible for an attacker HA to intercept the initial=20 >> RRQ1(time=3D1970), and the RRP1(time=3D2013) and fake a RREP towards the= =20 >> MR. No? >> >> Alex >> >>> >>> Kent >>> >>> -----Original Message----- From: Alexandru Petrescu=20 >>> [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=20 >>> do timekeeping? >>> >>> Le 14/03/2013 20:47, Kent Leung (kleung) a =E9crit : >>>> Hmm, I'm not clear with your response. >>>> >>>> Let's assume the following scenario. >>>> >>>> 1. MR sends initial RRQ1 (time=3Da) to HA 2. HA sends RRP1 >>>> (time=3Db) with code 133 >>> >>> Ok. Do you think MR receiving this RRP1 will be able to safele=20 >>> verify it is legitimate? Or is it possible than an attacker HA=20 >>> fakes this RRP1 message? >>> >>>> 3. MR sends RRQ2 (time=3Db+) 4. HA sends RRP2(time=3Db+) =3D>=20 >>>> registration successful 5. After MR recovers from failure, MR sends=20 >>>> RRQ3(time=3Dc) 6. HA sends RRP3(time=3Dd) with code 133 7. >>>> MR sends RRQ4(time=3Dd+) 8. HA sends RRP4(time=3Dd+) =3D> reregistrati= on=20 >>>> successful >>> >>> These latter steps 3-8 make sense. >>> >>> Alex >>> >>>> >>>> We would need to confirm if #6 happens properly for a specific =20 >>>> vendor. :) But I would expect #7 should happen if code 133 is =20 >>>> received. >>>> >>>> Kent >>>> >>>> -----Original Message----- From: mip4-bounces@ietf.org=20 >>>> [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=20 >>>> having to do timekeeping? >>>> >>>> Le 14/03/2013 20:38, Kent Leung (kleung) a =E9crit : >>>>> >>>>> It needs to have the time, even if it does second registration.=20 >>>>> It's not a problem it takes longer (we can send easily two=20 >>>>> messages). But the second message will also be refused by the HA=20 >>>>> 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=20 >>>> long time (vehicle in garage for several weeks in winter time). It=20 >>>> 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/ >>>> >>>> >>> >>> >>> >>> >> >> >> >> > > > > From alexandru.petrescu@gmail.com Thu Mar 14 14:49:04 2013 Return-Path: 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 A6C811F0D11 for ; Thu, 14 Mar 2013 14:49:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.033 X-Spam-Level: X-Spam-Status: No, score=-10.033 tagged_above=-999 required=5 tests=[AWL=0.216, 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 6oI-4isJcxDt for ; Thu, 14 Mar 2013 14:49:03 -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 CFA601F0D0F for ; Thu, 14 Mar 2013 14:49:02 -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 r2ELn1x8019758 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 14 Mar 2013 22:49:02 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r2ELn1La007869 for ; Thu, 14 Mar 2013 22:49:01 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.86.10]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r2ELmxYD022229 for ; Thu, 14 Mar 2013 22:49:01 +0100 Message-ID: <514245AE.8060809@gmail.com> Date: Thu, 14 Mar 2013 22:48:30 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: mip4@ietf.org References: <514206FE.7050807@gmail.com> <3359F724933DFD458579D24EAC769098857A51DC@Redwood.usa.awardsolutions.com> <51421CB9.1080100@gmail.com> <514223C4.8010905@gmail.com> <514226A9.9020700@gmail.com> <51422787.5060509@gmail.com> <51422BCB.30409@gmail.com> <51422D07.9070901@gmail.com> <51422F1C.7000705@gmail.com> <514243D0.2090309@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2013 21:49:04 -0000 Le 14/03/2013 22:46, Kent Leung (kleung) a écrit : > 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. Ok... is there a section in the RFC5944 which explains how to do this? Alex > > 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/ >>>>> >>>>> >>>> >>>> >>>> >>>> >>> >>> >>> >>> >> >> >> >> > > From amuhanna@awardsolutions.com Thu Mar 14 15:14:51 2013 Return-Path: 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 ; 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 ; 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 ; 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 To: Alexandru Petrescu , "Kent Leung (kleung)" 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> <514223C4.8010905@gmail.com> <514226A9.9020700@gmail.com> <51422787.5060509@gmail.com> <51422BCB.30409@gmail.com> <51422D07.9070901@gmail.com> <51422F1C.7000705@gmail.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" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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= .=20 There was a reason for the MN to send a Re-Registration, most probably exte= nds its registration lifetime, for example.=20 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 tim= e stamp is NOT in synch with the HA.=20 Usually, the Mobile node will adjust its timestamp according to what is com= ing 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 Ale= xandru 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 t= o 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 RRE= Q containing the Id copied from the RREP. Reads more like a warning to tak= e 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 M= N 13.8.9.3 with Lifetime 40, Home Address 13.8.9.3, Home Agent 13.8.9.4 Cod= e 133 " Alex Le 14/03/2013 21:15, Kent Leung (kleung) a =E9crit : > Timestamp is one of the fields in the message that is protected by key=20 > using a hash function. Since we are at IETF, let's talk offline as=20 > this seems to need some clarification and hand waving. :) > > Kent > > -----Original Message----- From: Alexandru Petrescu=20 > [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=20 > timekeeping? > > Le 14/03/2013 21:07, Kent Leung (kleung) a =E9crit : >> The Authenticator value is different for RRQ vs RRP. The extension =20 >> carries different value based on the message. The way to calculate=20 >> the value requires the shared key between MR and HA. So it's not easy=20 >> 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=20 > in the first place, for the first RREQ, without timestamp? > > Alex > >> >> Kent >> >> -----Original Message----- From: Alexandru Petrescu=20 >> [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=20 >> timekeeping? >> >> Le 14/03/2013 20:59, Kent Leung (kleung) a =E9crit : >>> The RRP1 cannot be faked since the MN-HA Auth Ext protects the=20 >>> message. >> >> I strongly doubt that. Were it so, then the same extension could=20 >> protect the first RRQ1 as well. >> >> I believe it is possible for an attacker HA to intercept the initial=20 >> RRQ1(time=3D1970), and the RRP1(time=3D2013) and fake a RREP towards the= =20 >> MR. No? >> >> Alex >> >>> >>> Kent >>> >>> -----Original Message----- From: Alexandru Petrescu=20 >>> [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=20 >>> do timekeeping? >>> >>> Le 14/03/2013 20:47, Kent Leung (kleung) a =E9crit : >>>> Hmm, I'm not clear with your response. >>>> >>>> Let's assume the following scenario. >>>> >>>> 1. MR sends initial RRQ1 (time=3Da) to HA 2. HA sends RRP1 >>>> (time=3Db) with code 133 >>> >>> Ok. Do you think MR receiving this RRP1 will be able to safele=20 >>> verify it is legitimate? Or is it possible than an attacker HA=20 >>> fakes this RRP1 message? >>> >>>> 3. MR sends RRQ2 (time=3Db+) 4. HA sends RRP2(time=3Db+) =3D>=20 >>>> registration successful 5. After MR recovers from failure, MR sends=20 >>>> RRQ3(time=3Dc) 6. HA sends RRP3(time=3Dd) with code 133 7. >>>> MR sends RRQ4(time=3Dd+) 8. HA sends RRP4(time=3Dd+) =3D> reregistrati= on=20 >>>> successful >>> >>> These latter steps 3-8 make sense. >>> >>> Alex >>> >>>> >>>> We would need to confirm if #6 happens properly for a specific =20 >>>> vendor. :) But I would expect #7 should happen if code 133 is =20 >>>> received. >>>> >>>> Kent >>>> >>>> -----Original Message----- From: mip4-bounces@ietf.org=20 >>>> [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=20 >>>> having to do timekeeping? >>>> >>>> Le 14/03/2013 20:38, Kent Leung (kleung) a =E9crit : >>>>> >>>>> It needs to have the time, even if it does second registration.=20 >>>>> It's not a problem it takes longer (we can send easily two=20 >>>>> messages). But the second message will also be refused by the HA=20 >>>>> 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=20 >>>> long time (vehicle in garage for several weeks in winter time). It=20 >>>> 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/ From filip.idzikowski@tu-berlin.de Tue Mar 19 01:04:19 2013 Return-Path: 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 3901B21F868B for ; Tue, 19 Mar 2013 01:04:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.914 X-Spam-Level: X-Spam-Status: No, score=-5.914 tagged_above=-999 required=5 tests=[AWL=0.335, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 wjcoqiTo957V for ; Tue, 19 Mar 2013 01:04:17 -0700 (PDT) Received: from mail.tu-berlin.de (mail.tu-berlin.de [130.149.7.33]) by ietfa.amsl.com (Postfix) with ESMTP id 2E28021F8653 for ; Tue, 19 Mar 2013 01:04:17 -0700 (PDT) X-tubIT-Incoming-IP: 37.182.177.244 Received: from [37.182.177.244] (helo=[192.168.43.45]) by mail.tu-berlin.de (exim-4.75/mailfrontend-4) with esmtpsa [TLSv1:AES128-SHA:128] for id 1UHrWh-00034v-An; Tue, 19 Mar 2013 09:04:07 +0100 From: Filip Idzikowski Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Date: Tue, 19 Mar 2013 09:04:03 +0100 Message-Id: <6974BD4D-BAA8-4FB7-B07F-8C7CDA97EDEA@mailbox.tu-berlin.de> To: mip4@ietf.org Mime-Version: 1.0 (Apple Message framework v1085) X-Mailer: Apple Mail (2.1085) X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.3.19.75416 X-PMX-Spam: Gauge=IIIIIII, Probability=0%, Report='' Subject: [Mip4] CfP: OnlineGreenComm 2013 X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Mar 2013 08:04:19 -0000 Dear All, Apologies if you receive multiple copies of this announcement. We would like to draw your attention to the Third IEEE Online Conference = on Green Communications OnlineGreenComm. The submission deadline is on = May 10, 2013. We are looking forward to your submission. Best regards, Nelson Fonseca, University of Campinas, Brazil Feifei Gao, Tsinghua University, China Filip Idzikowski, Technical University of Berlin, Germany on behalf of the Executive Committee ------------------------------------------------------------------------ CALL FOR PAPERS IEEE OnlineGreenComm 2013 The Third IEEE Online Conference on =20 Green Communications 29-31 October 2013 http://www.ieee-OnlineGreenComm.org/ ------------------------------------------------------------------------ The worldwide growing energy demands together with the increasing = depletion of fossil fuels have been recognized as a major challenge that = needs to be urgently addressed by society in order to have a sustainable = future. According to the U.S. Energy Department, worldwide energy = consumption is forecasted to increase by 53% from 2008 to 2035 if = nothing is done to change the current trends. The Information and = Communications Technology sector (ICT) is one of the sectors with the = highest potential to reduce the growing worldwide electricity = consumption if appropriate measures are taken in a timely manner. In this context, IEEE OnlineGreenComm 2013, the third edition of IEEE = Communications Society=92s Online Conference on Green Communications = solicits original, unpublished research papers both from academy and = industry reporting on substantial results in the green communications = area enabling significant future energy savings. Topics of interest = include, but are not limited to: Green Solutions for Communications Technologies - Energy-efficient networking and protocols - Energy-efficient communications management - Energy-efficiency in wired networks - Energy-efficiency in wireless networks - Energy-efficiency in vehicular networks - Energy-efficiency in data centers - Energy-efficiency in content delivery networks - Energy-efficient secure networking - Measurement & profiling of energy consumption - Standardization efforts Green Society Solutions based on Communications Technologies - Smart Cities - Smart Sensing - e-Health - Energy-efficient buildings - Energy harvesting - Industrial automation - Machine-to-Machine communications (M2M) - Intelligent Transport Systems (ITS) - Standardization efforts Smart Grid Communications - Advanced metering infrastructure and smart meter technologies - Wide-area monitoring and control - Demand-response management - Distributed generation and storage - Operations of renewable energy generation - Management & control of distributed energy storage - Grid-to-vehicle and vehicle-to-grid=20 - Micro-grids - Standardization efforts Surveys and Tutorials on any of the above topics are welcomed. Important Dates: Paper Submission Deadline: May 10, 2013=20 Acceptance Notification: July 26, 2013 Camera Ready Version Due: September 6, 2013 Conference Dates: October 29-31, 2013 Conference Website: http://www.ieee-OnlineGreenComm.org/ General Co-Chairs: Albert Banchs, IMDEA Networks, Spain Michela Meo, Politecnico di Torino, Italy Technical Program Committee Co-Chairs: Xavier Costa Perez, NEC Laboratories Europe, Germany Jinsong Wu, Bell Laboratories, China Anthony Ephremides, University of Maryland, USA =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D Filip Idzikowski Telecommunication Networks Group (TKN) Technical University of Berlin Einsteinufer 25, 10587 Berlin e-mail: filip.idzikowski@tu-berlin.de Tel: +49 30 314 29244 From alexandru.petrescu@gmail.com Thu Mar 21 08:30:51 2013 Return-Path: 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 ; 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 ; 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 ; 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 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 References: <514206FE.7050807@gmail.com> <3359F724933DFD458579D24EAC769098857A51DC@Redwood.usa.awardsolutions.com> <51421CB9.1080100@gmail.com> <514223C4.8010905@gmail.com> <514226A9.9020700@gmail.com> <51422787.5060509@gmail.com> <51422BCB.30409@gmail.com> <51422D07.9070901@gmail.com> <51422F1C.7000705@gmail.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\)" , "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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/ > > From alexandru.petrescu@gmail.com Thu Mar 21 08:51:59 2013 Return-Path: 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 E375821F9128 for ; Thu, 21 Mar 2013 08:51:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.188 X-Spam-Level: X-Spam-Status: No, score=-10.188 tagged_above=-999 required=5 tests=[AWL=0.061, 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 GASUDp7FcVN5 for ; Thu, 21 Mar 2013 08:51:58 -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 28EAB21F910E for ; Thu, 21 Mar 2013 08:51:57 -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 r2LFpvVb012936 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 21 Mar 2013 16:51:57 +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 r2LFpvmS013802 for ; Thu, 21 Mar 2013 16:51:57 +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 r2LFprdc016888 for ; Thu, 21 Mar 2013 16:51:56 +0100 Message-ID: <514B2C6E.5020803@gmail.com> Date: Thu, 21 Mar 2013 16:51:10 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Mobile IPv4 Mailing List Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: [Mip4] One implementation of RREQ/RREP time synchronization X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 15:51:59 -0000 The specification RFC 5944 "Mobile IPv4" has a textual description about an error Code 133 'Denied by home agent, registration Identification mismatch'. This is sent by the HA to MR when the MR's time is way back (or ahead) in time, like after having lost power. However, the spec doesn't say that the MR SHOULD send a new RREQ to the HA, and not neither does it say what to put in that RREQ. We wrote an implementation of a method to realize this: MR receive Code 133, update its time, send a new RREQ; this method is based on the discussion in this email list MIP4. This code is executed in MR: t0 = time (); obtain time of this computer ID1 = t0; Send to HA RREQ containing ID1; Receive RREP Code-133, and extract ID2=RREP.Identification; t1 = time (); set local time on MR to be time()+(ID2-ID1)-(t1-t0)/2; send RREQ to HA containing updated time; receive RREP with Code = 0 (successful). This interoperates ok with a Home Agent from manufacturer. Remark there is a speculation at the calculation of time (t1-t0)/2 which means half of the total RTT. But never an RTT is precisely half-half. We are not sure it is a good thing to synchronize time this way (rather than say NTP), and we are not sure either whether it is secure enough. Alex From charliep@computer.org Thu Mar 21 09:28:59 2013 Return-Path: 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 B337721F8168 for ; Thu, 21 Mar 2013 09:28:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 I4+r7AzOCjsi for ; Thu, 21 Mar 2013 09:28:58 -0700 (PDT) Received: from elasmtp-junco.atl.sa.earthlink.net (elasmtp-junco.atl.sa.earthlink.net [209.86.89.63]) by ietfa.amsl.com (Postfix) with ESMTP id 7751121F8DFA for ; Thu, 21 Mar 2013 09:28:54 -0700 (PDT) Received: from [130.129.48.15] (helo=[172.16.1.120]) by elasmtp-junco.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1UIiMH-0000er-RZ; Thu, 21 Mar 2013 11:28:53 -0500 Message-ID: <514B4335.2040107@computer.org> Date: Thu, 21 Mar 2013 10:28:21 -0700 From: "Charles E. Perkins" Organization: Saratoga Blue Skies User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Alexandru Petrescu References: <514B2C6E.5020803@gmail.com> In-Reply-To: <514B2C6E.5020803@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad8667053d3e88eed8c45142e65f6c0e5214350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 130.129.48.15 Cc: Mobile IPv4 Mailing List Subject: Re: [Mip4] One implementation of RREQ/RREP time synchronization X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 16:28:59 -0000 Hello Alexandru, The existing specification does not require NTP. I think that it's not required for replay protection, and that your suggested method should be fine. I don't think there should be any additional protocol mandates placed on MIPv4, especially after so much time, and that it would cause many existing implementations to become non-compliant. Regards, Charlie P. On 3/21/2013 8:51 AM, Alexandru Petrescu wrote: > The specification RFC 5944 "Mobile IPv4" has a textual description about > an error Code 133 'Denied by home agent, registration Identification > mismatch'. This is sent by the HA to MR when the MR's time is way back > (or ahead) in time, like after having lost power. > > However, the spec doesn't say that the MR SHOULD send a new RREQ to the > HA, and not neither does it say what to put in that RREQ. > > We wrote an implementation of a method to realize this: MR receive Code > 133, update its time, send a new RREQ; this method is based on the > discussion in this email list MIP4. > > This code is executed in MR: > t0 = time (); obtain time of this computer > ID1 = t0; > Send to HA RREQ containing ID1; > Receive RREP Code-133, and extract ID2=RREP.Identification; > t1 = time (); > set local time on MR to be time()+(ID2-ID1)-(t1-t0)/2; > send RREQ to HA containing updated time; > receive RREP with Code = 0 (successful). > > This interoperates ok with a Home Agent from manufacturer. > > Remark there is a speculation at the calculation of time (t1-t0)/2 which > means half of the total RTT. But never an RTT is precisely half-half. > > We are not sure it is a good thing to synchronize time this way (rather > than say NTP), and we are not sure either whether it is secure enough. > > Alex > -- Regards, Charlie P. From amuhanna@awardsolutions.com Thu Mar 21 09:32:04 2013 Return-Path: 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 36E3E21F8BBC for ; Thu, 21 Mar 2013 09:32:04 -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=[AWL=0.000, 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 yLe79WV2Aq2T for ; Thu, 21 Mar 2013 09:32:03 -0700 (PDT) Received: from exprod8og118.obsmtp.com (exprod8og118.obsmtp.com [64.18.3.36]) by ietfa.amsl.com (Postfix) with ESMTP id 6BFDC21F8554 for ; Thu, 21 Mar 2013 09:32:02 -0700 (PDT) Received: from mail.awardsolutions.com ([66.142.250.98]) (using TLSv1) by exprod8ob118.postini.com ([64.18.7.12]) with SMTP ID DSNKUUs2AM/byO7xsYzOPBKOUaP/GHvJsa0v@postini.com; Thu, 21 Mar 2013 09:32:02 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, 21 Mar 2013 11:31:59 -0500 From: Ahmad Muhanna To: Alexandru Petrescu Thread-Topic: [Mip4] Does MIP support RegReq authentication without having to do timekeeping? Thread-Index: AQHOJkkPwvslkbtpqEmtRlv9v24h05iwVB/A Date: Thu, 21 Mar 2013 16:31:58 +0000 Message-ID: <3359F724933DFD458579D24EAC769098857BF8EF@Redwood.usa.awardsolutions.com> References: <514206FE.7050807@gmail.com> <3359F724933DFD458579D24EAC769098857A51DC@Redwood.usa.awardsolutions.com> <51421CB9.1080100@gmail.com> <514223C4.8010905@gmail.com> <514226A9.9020700@gmail.com> <51422787.5060509@gmail.com> <51422BCB.30409@gmail.com> <51422D07.9070901@gmail.com> <51422F1C.7000705@gmail.com> <514243D0.2090309@gmail.com> <3359F724933DFD458579D24EAC769098857A54B0@Redwood.usa.awardsolutions.com> <514B2771.9080504@gmail.com> In-Reply-To: <514B2771.9080504@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.25.208.97] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Kent Leung \(kleung\)" , "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 16:32:04 -0000 Alex, Just to close on the issue that the specification does NOT have anything wh= ich requires the MN to synchronizes and send a new RREQ, Here what the specification says: " 3.6.2.3. Registration Request Denied If the Code field indicates that service is being denied, the mobile node SHOULD log the error. In certain cases, the mobile node may be able to "repair" the error. These include: ..... ..... 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. " The specification leaves that to the implementation. However, the specifica= tion describe what the MN can do to fix the error. As I said, it is the res= ponsibility of the MN to keep its registration alive at the Home Agent. What does this mean:=20 It is GIVEN: If the MN would like to continue to being served by its Home A= gent using the Home address that was allocated to the MN, the MN MUST re-re= gister before lifetime expires. I assume we agree on this. OK. If the MN while re-registering receives an error code 133, the MN has a= choice: 1. Ignore the RRP and do nothing and consequently loses its connection to t= he internet and for sure will NOT be able to use its allocated home address= , OR 2. The MN uses section 3.6.2.3. of how to correct the 133 error and maintai= n its connectivity. I hope this makes sense. I will respond to your detailed procedure shortly. Cheers! Best Regards, Ahmad -----Original Message----- From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com]=20 Sent: Thursday, March 21, 2013 10:30 AM To: Ahmad Muhanna Cc: Kent Leung (kleung); mip4@ietf.org Subject: Re: [Mip4] Does MIP support RegReq authentication without having t= o do timekeeping? Le 14/03/2013 23:14, Ahmad Muhanna a =E9crit : > 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=20 > 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=20 > extends its registration lifetime, for example. If the Reply is NOT=20 > successful, the MN can NOT assume its registration has been extended=20 > 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=20 > its time stamp is NOT in synch with the HA. Usually, the Mobile node =20 > will adjust its timestamp according to what is coming from the HA. I =20 > have seen this a lot!! :-) Ok. So we now do it as well. Our implementation of MR works with the HA f= rom that manufacturarer - synchronizes time. I will post separately the pr= ocedure. Alex > > Anyhow; enjoy your IETF meeting! > > Best Regards, Ahmad > > -----Original Message----- From: mip4-bounces@ietf.org=20 > [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=20 > authentication without having to do timekeeping? > > Kent, > > Thanks for the discussion and clarification. Thanks for the pointer =20 > 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=20 > contain a value that allows the mobile node to synchronize with the=20 > home agent, based upon the style of replay protection in effect=20 > (Section 5.7). The mobile node MUST adjust the parameters it uses to=20 > compute the Identification field based upon the information in the=20 > Registration Reply, before issuing any future Registration Requests." > > When we read this last phrase we didnt see an incentive to send=20 > another RREQ containing the Id copied from the RREP. Reads more like=20 > a warning to take care next time, but it doesnt explicitely say that=20 > the HA expects a RREQ in the immediate, and that the MR should send=20 > it. > > We could only rely on the error log in the HA, which doesnt invite to=20 > 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=20 > 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 =E9crit : >> Timestamp is one of the fields in the message that is protected by =20 >> key using a hash function. Since we are at IETF, let's talk offline=20 >> as this seems to need some clarification and hand waving. >> :) >> >> Kent >> >> -----Original Message----- From: Alexandru Petrescu=20 >> [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=20 >> do timekeeping? >> >> Le 14/03/2013 21:07, Kent Leung (kleung) a =E9crit : >>> The Authenticator value is different for RRQ vs RRP. The extension=20 >>> carries different value based on the message. The way to calculate=20 >>> 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=20 >> in the first place, for the first RREQ, without timestamp? >> >> Alex >> >>> >>> Kent >>> >>> -----Original Message----- From: Alexandru Petrescu=20 >>> [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=20 >>> do timekeeping? >>> >>> Le 14/03/2013 20:59, Kent Leung (kleung) a =E9crit : >>>> The RRP1 cannot be faked since the MN-HA Auth Ext protects the=20 >>>> message. >>> >>> I strongly doubt that. Were it so, then the same extension could=20 >>> protect the first RRQ1 as well. >>> >>> I believe it is possible for an attacker HA to intercept the initial=20 >>> RRQ1(time=3D1970), and the RRP1(time=3D2013) and fake a RREP towards=20 >>> the MR. No? >>> >>> Alex >>> >>>> >>>> Kent >>>> >>>> -----Original Message----- From: Alexandru Petrescu=20 >>>> [mailto:alexandru.petrescu@gmail.com] Sent: Thursday, March 14,=20 >>>> 2013 12:58 PM To: Kent Leung (kleung) Cc: mip4@ietf.org >>>> Subject: Re: [Mip4] Does MIP support RegReq authentication without=20 >>>> having to do timekeeping? >>>> >>>> Le 14/03/2013 20:47, Kent Leung (kleung) a =E9crit : >>>>> Hmm, I'm not clear with your response. >>>>> >>>>> Let's assume the following scenario. >>>>> >>>>> 1. MR sends initial RRQ1 (time=3Da) to HA 2. HA sends RRP1 >>>>> (time=3Db) with code 133 >>>> >>>> Ok. Do you think MR receiving this RRP1 will be able to safele=20 >>>> verify it is legitimate? Or is it possible than an attacker HA=20 >>>> fakes this RRP1 message? >>>> >>>>> 3. MR sends RRQ2 (time=3Db+) 4. HA sends RRP2(time=3Db+) =3D>=20 >>>>> registration successful 5. After MR recovers from failure, MR=20 >>>>> sends RRQ3(time=3Dc) 6. HA sends RRP3(time=3Dd) with code 133 7. >>>>> MR sends RRQ4(time=3Dd+) 8. HA sends RRP4(time=3Dd+) =3D> reregistrat= ion=20 >>>>> successful >>>> >>>> These latter steps 3-8 make sense. >>>> >>>> Alex >>>> >>>>> >>>>> We would need to confirm if #6 happens properly for a specific=20 >>>>> vendor. :) But I would expect #7 should happen if code 133 is=20 >>>>> received. >>>>> >>>>> Kent >>>>> >>>>> -----Original Message----- From: mip4-bounces@ietf.org=20 >>>>> [mailto:mip4-bounces@ietf.org] On Behalf Of Alexandru Petrescu=20 >>>>> Sent: Thursday, March 14, 2013 12:40 PM To: >>>>> mip4@ietf.org Subject: Re: [Mip4] Does MIP support RegReq=20 >>>>> authentication without having to do timekeeping? >>>>> >>>>> Le 14/03/2013 20:38, Kent Leung (kleung) a =E9crit : >>>>>> >>>>>> It needs to have the time, even if it does second registration.=20 >>>>>> It's not a problem it takes longer (we can send easily two=20 >>>>>> messages). But the second message will also be refused by the HA=20 >>>>>> 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=20 >>>>> long time (vehicle in garage for several weeks in winter time). It=20 >>>>> 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/ > > From alexandru.petrescu@gmail.com Thu Mar 21 09:39:39 2013 Return-Path: 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 67C9E21F8DEA for ; Thu, 21 Mar 2013 09:39:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.18 X-Spam-Level: X-Spam-Status: No, score=-10.18 tagged_above=-999 required=5 tests=[AWL=0.069, 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 Dfczp3RGJkPp for ; Thu, 21 Mar 2013 09:39:38 -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 30CBB21F8DE9 for ; Thu, 21 Mar 2013 09:39:37 -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 r2LGdP65008155 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 21 Mar 2013 17:39:25 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r2LGdP2E031293; Thu, 21 Mar 2013 17:39:25 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r2LGdLNT008009; Thu, 21 Mar 2013 17:39:25 +0100 Message-ID: <514B378F.302@gmail.com> Date: Thu, 21 Mar 2013 17:38:39 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: "Charles E. Perkins" References: <514B2C6E.5020803@gmail.com> <514B4335.2040107@computer.org> In-Reply-To: <514B4335.2040107@computer.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: Mobile IPv4 Mailing List Subject: Re: [Mip4] One implementation of RREQ/RREP time synchronization X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 16:39:39 -0000 Charles, Thanks for the reply. Le 21/03/2013 18:28, Charles E. Perkins a écrit : > > Hello Alexandru, > > The existing specification does not require NTP. Right. But one implementation of that specification requires that the MR has good timekeeping otherwise the Registration fails. So how could one have good timekeeping on the Mobile Router? Maybe NTP? Maybe synchronize the time by using RegReq/Rep? Maybe GPS/Galileo? All these are unspecified in the MIP4 RFC. I am not requesting it modified, I am just saying how it is. > I think that it's not required for replay protection, How else to do replay protection than with timespamps? > and that your suggested method should be fine. I don't think there > should be any additional protocol mandates placed on MIPv4, > especially after so much time, and that it would cause many existing > implementations to become non-compliant. Right. No new mandate. Just exposed some operational problem. Alex > > Regards, Charlie P. > > > On 3/21/2013 8:51 AM, Alexandru Petrescu wrote: >> The specification RFC 5944 "Mobile IPv4" has a textual description >> about an error Code 133 'Denied by home agent, registration >> Identification mismatch'. This is sent by the HA to MR when the >> MR's time is way back (or ahead) in time, like after having lost >> power. >> >> However, the spec doesn't say that the MR SHOULD send a new RREQ >> to the HA, and not neither does it say what to put in that RREQ. >> >> We wrote an implementation of a method to realize this: MR receive >> Code 133, update its time, send a new RREQ; this method is based >> on the discussion in this email list MIP4. >> >> This code is executed in MR: t0 = time (); obtain time of this >> computer ID1 = t0; Send to HA RREQ containing ID1; Receive RREP >> Code-133, and extract ID2=RREP.Identification; t1 = time (); set >> local time on MR to be time()+(ID2-ID1)-(t1-t0)/2; send RREQ to HA >> containing updated time; receive RREP with Code = 0 (successful). >> >> This interoperates ok with a Home Agent from manufacturer. >> >> Remark there is a speculation at the calculation of time (t1-t0)/2 >> which means half of the total RTT. But never an RTT is precisely >> half-half. >> >> We are not sure it is a good thing to synchronize time this way >> (rather than say NTP), and we are not sure either whether it is >> secure enough. >> >> Alex >> > > From amuhanna@awardsolutions.com Thu Mar 21 09:44:00 2013 Return-Path: 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 AB4F921F8E57 for ; Thu, 21 Mar 2013 09:44:00 -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 aAONJYqV1Ui7 for ; Thu, 21 Mar 2013 09:43:59 -0700 (PDT) Received: from exprod8og116.obsmtp.com (exprod8og116.obsmtp.com [64.18.3.32]) by ietfa.amsl.com (Postfix) with ESMTP id 617E821F8CF9 for ; Thu, 21 Mar 2013 09:43:59 -0700 (PDT) Received: from mail.awardsolutions.com ([66.142.250.98]) (using TLSv1) by exprod8ob116.postini.com ([64.18.7.12]) with SMTP ID DSNKUUs4zG9yYB5wsWIXALtMen9+rDMgIJFd@postini.com; Thu, 21 Mar 2013 09:43:59 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, 21 Mar 2013 11:43:56 -0500 From: Ahmad Muhanna To: "Charles E. Perkins" , Alexandru Petrescu Thread-Topic: [Mip4] One implementation of RREQ/RREP time synchronization Thread-Index: AQHOJkwGJ0hYhYSpQ02WtFAVfQ+vZ5iwujGA//+cvUA= Date: Thu, 21 Mar 2013 16:43:55 +0000 Message-ID: <3359F724933DFD458579D24EAC769098857BF91A@Redwood.usa.awardsolutions.com> References: <514B2C6E.5020803@gmail.com> <514B4335.2040107@computer.org> In-Reply-To: <514B4335.2040107@computer.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.25.208.97] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Mobile IPv4 Mailing List Subject: Re: [Mip4] One implementation of RREQ/RREP time synchronization X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 16:44:00 -0000 Hi Alex, I agree with Charlie, No need to change anything. Your proposed procedure is what many implementation has been using for a lo= ng time. In addition, I have the following comments: 1. Adjusting the MR timer considering the half the trip time is a good idea= and implementation specific. If I remember correctly, I believe the HA all= ows for a difference of 7 seconds and that's a lot of time. 2. Since you started by saying that the MR lost its time, I would suggest t= hat when you build the Identification field of the RRG to use a good random= number generator for the 32 lower bits of the Identification ID. If that r= andom number generator is expensive for such MR, then you can have the MR u= ses just a counter and keep track of that counter so it does not send a RRQ= with the same counter twice; unless the 32 lower bits rolls and if that ev= er happens, it will take a very looooong time before ever happened. =20 This simple implementation will for sure eliminate any fear of replay prote= ction. Best Regards, Ahmad -----Original Message----- From: mip4-bounces@ietf.org [mailto:mip4-bounces@ietf.org] On Behalf Of Cha= rles E. Perkins Sent: Thursday, March 21, 2013 12:28 PM To: Alexandru Petrescu Cc: Mobile IPv4 Mailing List Subject: Re: [Mip4] One implementation of RREQ/RREP time synchronization Hello Alexandru, The existing specification does not require NTP. I think that it's not req= uired for replay protection, and that your suggested method should be fine.= I don't think there should be any additional protocol mandates placed on = MIPv4, especially after so much time, and that it would cause many existing= implementations to become non-compliant. Regards, Charlie P. On 3/21/2013 8:51 AM, Alexandru Petrescu wrote: > The specification RFC 5944 "Mobile IPv4" has a textual description=20 > about an error Code 133 'Denied by home agent, registration=20 > Identification mismatch'. This is sent by the HA to MR when the MR's=20 > time is way back (or ahead) in time, like after having lost power. > > However, the spec doesn't say that the MR SHOULD send a new RREQ to=20 > the HA, and not neither does it say what to put in that RREQ. > > We wrote an implementation of a method to realize this: MR receive=20 > Code 133, update its time, send a new RREQ; this method is based on=20 > the discussion in this email list MIP4. > > This code is executed in MR: > t0 =3D time (); obtain time of this computer > ID1 =3D t0; > Send to HA RREQ containing ID1; > Receive RREP Code-133, and extract ID2=3DRREP.Identification; > t1 =3D time (); > set local time on MR to be time()+(ID2-ID1)-(t1-t0)/2; > send RREQ to HA containing updated time; > receive RREP with Code =3D 0 (successful). > > This interoperates ok with a Home Agent from manufacturer. > > Remark there is a speculation at the calculation of time (t1-t0)/2=20 > which means half of the total RTT. But never an RTT is precisely half-ha= lf. > > We are not sure it is a good thing to synchronize time this way=20 > (rather than say NTP), and we are not sure either whether it is secure en= ough. > > Alex > -- Regards, Charlie P. -- 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/ From sensys@cfpmail.info Thu Mar 28 11:51:29 2013 Return-Path: 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 13FAB21F8DC9 for ; Thu, 28 Mar 2013 11:51:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.377 X-Spam-Level: X-Spam-Status: No, score=-0.377 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] 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 qxJxepjgn6nK for ; Thu, 28 Mar 2013 11:51:25 -0700 (PDT) Received: from mail-vc0-f181.google.com (mail-vc0-f181.google.com [209.85.220.181]) by ietfa.amsl.com (Postfix) with ESMTP id BCBD321F8D0E for ; Thu, 28 Mar 2013 11:51:04 -0700 (PDT) Received: by mail-vc0-f181.google.com with SMTP id hv10so7923915vcb.40 for ; Thu, 28 Mar 2013 11:51:04 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding:x-gm-message-state; bh=1cGxO+NOdSqN2mVI/6ycen3750miX2etmvUG1y7hMfc=; b=ivteH0vMcbXYMTWELfw5HNZGhxSYozhj+dqRVbPsdyJpsJ+R0YX3Kkx69TZZU/em03 HsLWXIPReD8GFed6yFB+5HqIVNQJrKYAY2RqcHv+Mqi7WZUZ8WPfddLCJBlvU3K9UMog V/dU72hjBDwn5I7HmZhBD9Waa+IKx+iCdOjS10A+S4L1egZgoOo3OH9WnHzFxkjLL8Pm iy7hK5x0P7KEsRic7b6Cuuz52rTk6xv8jdgcwbVDjtT6JF7H8Hmh9APBP9dz8Rr5QZzK RcQCn2cD2qXzhjj5gZTwTZiXsILCI7ZHfnvIifI7Gj/wwU1SdvpcOo7yKt+7P2oCovyY dE+Q== MIME-Version: 1.0 X-Received: by 10.52.249.105 with SMTP id yt9mr20887647vdc.86.1364496664177; Thu, 28 Mar 2013 11:51:04 -0700 (PDT) Received: by 10.52.160.104 with HTTP; Thu, 28 Mar 2013 11:51:04 -0700 (PDT) X-Originating-IP: [71.195.166.116] In-Reply-To: References: Date: Thu, 28 Mar 2013 11:51:04 -0700 Message-ID: From: "SenSys'13 Publicity" To: MIP4 IETF Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQm+rcZ5NAU+9T//FDuLod2GcghgX9k9YGvLQ/kgZRMDt52AFPkiHBj5M2lcJXO549PpiXkb Subject: [Mip4] CFP: SenSys 2013 -- The 11th ACM Conference on Embedded Networked Sensor Systems X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Mar 2013 18:51:29 -0000 [Apologies in advance for any cross-postings] Dear colleagues. There are only 2 DAYS! remaining for abstract registration. ***************************************************************************= ************************ Call For Papers SenSys 2013---The 11th ACM Conference on Embedded Networked Sensor Systems November 11-15, 2013 Rome, Italy ***************************************************************************= ************************* Sensing systems are changing the way computers interact with the physical world -- and are driving a host of new issues in computer system design, implementation, and performance. SenSys 2013 is the premier venue to discuss system issues raised by emerging trends in sensing systems =96 broadly defined to include mobile sensing, body sensing, Kinect, camera networks, RFID, and many others. We solicit technical papers describing original ideas, ground breaking results and/or quantified system experiences involving sensor systems. The conference values papers that take a broad systems perspective rather than a narrow focus on individual components. Of particular interest are technical contributions that enable new and compelling sensing applications. Topics of interest include, but are not limited to, the following: * Experience with real-world applications * Innovative sensing applications (e.g., mobile healthcare, transportation, buildings) * New models of sensor usage (e.g., mobile sensing, body sensing, RFIDs, ro= bots) * Sensor data quality, integrity, and trustworthiness * Challenges for =93Big Sensor Data=94 * Sensor data storage, retrieval, processing and management * Data reduction, inference, and signal processing * Fault-tolerance and reliability * Provable correctness and performance guarantees * Support for integrated sensing, actuation and control * Wireless communication systems and protocols * Energy management and energy harvesting * Resource management and OS support * Programming paradigms for sensing systems * Security and privacy in sensor networks * Time and location estimation and management Detailed submission instructions can be found at http://sensys.acm.org/2013/submissions/ Key Dates These are hard deadlines: No extensions will be granted. * Paper Registration: March 30, 2013, 11:59 pm EST. * Paper Submission Deadline: April 6, 2013, 11:59 pm EST. * Notification of Paper Acceptance: July 15, 2013. General Chair Chiara Petrioli (University of Rome 'La Sapienza') Program Chairs Landon Cox (Duke University) Kamin Whitehouse (University of Virginia) Poster Chair Chenyang Lu (Washington University in St. Louis) Luca Mottola (Politecnico di Milano and Swedish Institute of Computer Scien= ce) Demo Chairs Emiliano Miliuzzo (AT&T Labs) Amy Murphy (FBK) Local Arrangements Chairs Francesca Cuomo, Gaia Maselli, Andrea Vitaletti (University of Rome 'La Sapienza') Finance Chair Rasit Eskicioglu (University of Manitoba) Publicity Chairs Stefano Basagni (Northeastern University) Alberto Cerpa (University of California, Merced) Salil Kanhere (University of New South Wales) Mike Chieh-Jan Liang (Microsoft Research Asia) Publicaton Chair Wendi Heizelman (University of Rochester) Workshop Chairs Luca Benini (ETHZ & University of Bologna) Deepak Ganesan (UMASS Amherst) Industrial Liaison Chairs Jie Liu (Microsoft Research) Adam Wolisz (Technische Universitat Berlin) N2Women Chair Niki Trigoni (University of Oxford) Doctoral Colloquium Chair Cecilia Mascolo (University of Cambridge) Student Travel Award Chair Pedro Marron (University of Duisburg-Essen) Radu Stoleru (Texas A&M University) Web Site Chair David Boyle (Imperial College London) Technical Program Committee Yuvraj Agarwal (University of California, San Diego) Jan Beutel (Swiss Federal Institute of Technology, Zurich) Geoffrey Challen (University at Buffalo) Tanzeem Choudhary (Cornell University) David Chu (Microsoft Research, Redmond) Deborah Estrin (Cornell Tech) Wen Hu (CSIRO, Australia) Fred Jiang (Intel Labs, China) Nic Lane (Microsoft Research, Asia) Jie Liu (Microsoft Research, Redmond) Pedro Jose Marron (University of Duisburg Essen) Cecilia Mascolo (University of Cambridge) Luca Mottola (Politecnico di Milano and Swedish Institute of Computer Scien= ce) Lama Nachman (Intel Labs) Gian Pietro Picco (University of Trento) Raj Rajkumar (Carnegie Mellon University) Anthony Rowe (Carnegie Mellon University) Romit Roy Choudhury (Duke University) Silvia Santini (Technische Universitat Darmstadt) Mahadev Satyanarayanan (Carnegie Mellon University) Thomas Schmid (University of Utah) Junehwa Song (Korean Advanced Institute of Science and Technology) Niki Trigoni (University of Oxford) Lin Zhong (Rice University)