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

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 14 Mar 2013 18:21:02 +0100

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: Ahmad Muhanna <[email-masked]>
Date: Thu, 14 Mar 2013 18:44:34 +0000

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.
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 HA should allow the RRP to go through.

I Hope this helps!

Cheers!

Best Regards,
Ahmad

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 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: [email-masked]
    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 <[email-masked]>
Date: Thu, 14 Mar 2013 19:53:45 +0100

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

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: [email-masked]
> [mailto:[email-masked]] On Behalf Of Alexandru Petrescu Sent:
> Thursday, March 14, 2013 12:21 PM To: Mobile IPv4 Mailing List
> 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.
>
> -- Mip4 mailing list: [email-masked] 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: "Kent Leung (kleung)" <[email-masked]>
Date: Thu, 14 Mar 2013 19:20:16 +0000

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.

Kent

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 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.
>

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.

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

Alex

---

From: Ahmad Muhanna <[email-masked]>
Date: Thu, 14 Mar 2013 19:24:24 +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 while 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 the 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 what I am thinking. :-)

Best Regards,
Ahmad

-----Original Message-----
From: Alexandru Petrescu [mailto:[email-masked]] 
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 to do timekeeping?

Yes.

Ok, this could be done.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 14 Mar 2013 20:23:48 +0100

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

>  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?
>
>> [mailto:[email-masked]] 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,
>>
>> (its battery dies out after an extended period of inactivity, like
>> in a vehicle).  At that point the MR looses its time.
>>

---

From: "Kent Leung (kleung)" <[email-masked]>
Date: Thu, 14 Mar 2013 19:31:30 +0000

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:[email-masked]] 
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 :
> 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

>> Sent: Thursday, March 14, 2013 12:21 PM To: Mobile IPv4 Mailing List

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 14 Mar 2013 20:36:09 +0100

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:[email-masked]] Sent: Thursday, March 14, 2013
> 12:24 PM To: Kent Leung (kleung) Cc: Ahmad Muhanna; Mobile IPv4
>> 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.
>
>> 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?
>>
>> Does this behaviour require modification of the HA? (we are not
>> able to modify it, but we can modify the MR).
>>
>>> As far as I recall, RFC2002 and all updates afterwards, allow
>>> the use of nonce. Basically like a challenge.
>>>
>>> should have remembered the last RRP ID which is based on
>>> timestamp  and use that for Re-Registration.
>>
>> Ok, this could be done.
>>
>>>  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.
>>
>>> List Subject: [Mip4] Does MIP support RegReq authentication
>>> without having to do timekeeping?
>>>
>>> MIP4 participants,
>>>
>>> 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.
>>>

---

From: Ahmad Muhanna <[email-masked]>
Date: Thu, 14 Mar 2013 19:36:45 +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. 

I guess no need to change anything then :-)

Best Regards,
Ahmad

-----Original Message-----
From: Kent Leung (kleung) [mailto:[email-masked]] 
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?

Kent

-----Original Message-----
From: Alexandru Petrescu [mailto:[email-masked]]
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?

Alex

---

From: "Kent Leung (kleung)" <[email-masked]>
Date: Thu, 14 Mar 2013 19:38:43 +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 <[email-masked]>
Date: Thu, 14 Mar 2013 20:38:34 +0100

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

> -----Original Message----- From: Kent Leung (kleung)
> [mailto:[email-masked]] Sent: Thursday, March 14, 2013 2:32 PM To:
> Alexandru Petrescu Cc: Ahmad Muhanna; Mobile IPv4 Mailing List
> 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.
>
> the HA replies with code 133? It would take two registration messages
> from MR so it takes a little longer.
>
> Kent
>
>>> 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.
>>>
>>> Or, the MIP4 regreq/regrep HA implementation that we use seems to
>>> rely on having the right time, otherwise the registration fails.
>>>

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 14 Mar 2013 20:39:51 +0100

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

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

---

From: Ahmad Muhanna <[email-masked]>
Date: Thu, 14 Mar 2013 19:43:18 +0000

Yes.

HA inserts its timestamp in the high 32 bits of the RRP ID for the MR to synchronize itself.
Since the MR timer failed, the MR can still use the timestamp returned in the 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 because its time has failed.

I do NOT believe there is any security issue in there. 
The ID field is protected by the MN-HA Authentication Extension.

Best Regards,
Ahmad

-----Original Message-----
From: Alexandru Petrescu [mailto:[email-masked]] 
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 to do timekeeping?

> returned in the RRP with code 133 and the second RRQ should work just 

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

> 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
>
>> Mobile IPv4 Mailing List Subject: Re: [Mip4] Does MIP support RegReq 
>>> with the HA, without assuming that its time is correct.

---

From: "Kent Leung (kleung)" <[email-masked]>
Date: Thu, 14 Mar 2013 19:47:00 +0000

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

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: [email-masked] [mailto:[email-masked]] On Behalf Of Alexandru Petrescu
Sent: Thursday, March 14, 2013 12:40 PM
To: [email-masked]
Subject: Re: [Mip4] Does MIP support RegReq authentication without having to do timekeeping?

Le 14/03/2013 20:38, Kent Leung (kleung) a écrit :
> But the second message will also be refused by the HA because it still 
> has the wrong time.
>

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

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 14 Mar 2013 20:54:29 +0100

> returned in the RRP with code 133 and the second RRQ should work just

Is this timestamp in RREP the 'Identification' field shown by wireshark?

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 14 Mar 2013 20:58:03 +0100

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

> 8. HA sends RRP4(time=d+) => reregistration successful

These latter steps 3-8 make sense.

Alex

---

From: Ahmad Muhanna <[email-masked]>
Date: Thu, 14 Mar 2013 19:59:24 +0000

Yes. This ID is 64 bits.

The higher order 32 bits is the time in seconds and the lower 32 bits is the fraction of the second. However, some implementation uses JUST a random number.

In the Reply with code 133: 
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:[email-masked]] 
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 to do timekeeping?

Alex

---

From: "Kent Leung (kleung)" <[email-masked]>
Date: Thu, 14 Mar 2013 19:59:39 +0000

The RRP1 cannot be faked since the MN-HA Auth Ext protects the message.

Kent

-----Original Message-----
From: Alexandru Petrescu [mailto:[email-masked]] 
Sent: Thursday, March 14, 2013 12:58 PM
To: Kent Leung (kleung)
Cc: [email-masked]
Subject: Re: [Mip4] Does MIP support RegReq authentication without having to do timekeeping?

Le 14/03/2013 20:47, Kent Leung (kleung) a écrit :
> 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?

> 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

Alex

>       Charter page: 
> http://www.ietf.org/html.charters/mip4-charter.html

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 14 Mar 2013 21:03:19 +0100

> The RRP1 cannot be faked since the MN-HA Auth Ext protects the

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

> 12:58 PM To: Kent Leung (kleung) Cc: [email-masked] Subject: Re:
> [Mip4] Does MIP support RegReq authentication without having to do
> timekeeping?
>
>> 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
>
>> 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
>>
>> Sent: Thursday, March 14, 2013 12:40 PM To: [email-masked] Subject:
>> Re: [Mip4] Does MIP support RegReq authentication without having
>> to do timekeeping?
>>
>>> 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.
>>>
>> 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: "Kent Leung (kleung)" <[email-masked]>
Date: Thu, 14 Mar 2013 20:07:18 +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 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:[email-masked]] 
Sent: Thursday, March 14, 2013 1:03 PM
To: Kent Leung (kleung)
Cc: [email-masked]
Subject: Re: [Mip4] Does MIP support RegReq authentication without having to do timekeeping?

> The RRP1 cannot be faked since the MN-HA Auth Ext protects the 

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

> 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
>
>> Re: [Mip4] Does MIP support RegReq authentication without having to 
>> do timekeeping?
>>

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 14 Mar 2013 21:12:12 +0100

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

> 1:03 PM To: Kent Leung (kleung) Cc: [email-masked] Subject: Re:
> RRQ1(time=1970), and the RRP1(time=2013) and fake a RREP towards the
> MR. No?
>
> Alex
>
>>
>> Kent
>>
>> [mailto:[email-masked]] Sent: Thursday, March 14,
>> 2013 12:58 PM To: Kent Leung (kleung) Cc: [email-masked] Subject:
>>> Sent: Thursday, March 14, 2013 12:40 PM To: [email-masked]
>>>> messages). But the second message will also be refused by the
>>>> HA because it still has the wrong time.
>>>>

---

From: "Kent Leung (kleung)" <[email-masked]>
Date: Thu, 14 Mar 2013 20:15:06 +0000

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:[email-masked]] 
Sent: Thursday, March 14, 2013 1:12 PM
To: Kent Leung (kleung)
Cc: [email-masked]
Subject: Re: [Mip4] Does MIP support RegReq authentication without having to do timekeeping?

Le 14/03/2013 21:07, Kent Leung (kleung) a écrit :
> 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.

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

>> verify it is legitimate?  Or is it possible than an attacker HA fakes 
>> this RRP1 message?
>>

---

From: Ahmad Muhanna <[email-masked]>
Date: Thu, 14 Mar 2013 20:17:37 +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 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: [email-masked] [mailto:[email-masked]] On Behalf Of Kent Leung (kleung)
Sent: Thursday, March 14, 2013 3:07 PM
To: Alexandru Petrescu
Cc: [email-masked]
Subject: Re: [Mip4] Does MIP support RegReq authentication without having to do timekeeping?

Kent

-----Original Message-----
From: Alexandru Petrescu [mailto:[email-masked]]
Sent: Thursday, March 14, 2013 1:03 PM
To: Kent Leung (kleung)
Cc: [email-masked]
Subject: Re: [Mip4] Does MIP support RegReq authentication without having to do timekeeping?

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 14 Mar 2013 22:40:32 +0100

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
>
> 1:12 PM To: Kent Leung (kleung) Cc: [email-masked] Subject: Re:
>>  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.
>
> 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
>>
>> 2013 1:03 PM To: Kent Leung (kleung) Cc: [email-masked] Subject: Re:
>> 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
>>>
>>>  Re: [Mip4] Does MIP support RegReq authentication without
>>>> 1. MR sends initial RRQ1 (time=a) to HA 2. HA sends RRP1
>>>> (time=b) with code 133
>>>
>>>> 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+) =>
>>>>> 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.
>>>>>
>>>> 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: Alexandru Petrescu <[email-masked]>
Date: Thu, 14 Mar 2013 22:45:50 +0100

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

---

From: "Kent Leung (kleung)" <[email-masked]>
Date: Thu, 14 Mar 2013 21:46:58 +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:[email-masked]] 
Sent: Thursday, March 14, 2013 2:41 PM
To: Kent Leung (kleung)
Cc: [email-masked]
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:

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
>
>> the value requires the shared key between MR and HA. So it's not easy 
>> for an attacker to know the key.
>
>>>> 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
>>>
>>>> long time (vehicle in garage for several weeks in winter time). It 
>>>> now has year 1970.
>>>>
>>>> Alex
>>>>
>>>>>
>>>>> Kent
>>>>>
>>>>>
>>>>
>>>>

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 14 Mar 2013 22:48:30 +0100

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

> 2:41 PM To: Kent Leung (kleung) Cc: [email-masked] Subject: Re: [Mip4]
> Does MIP support RegReq authentication without having to do
> timekeeping?
>
> Kent,
>
> 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.
>
> "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
>
>> 2013 1:12 PM To: Kent Leung (kleung) Cc: [email-masked] Subject:
>>> 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.
>>
>> 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
>>>
>>> 2013 1:03 PM To: Kent Leung (kleung) Cc: [email-masked] Subject:
>>>> [mailto:[email-masked]] Sent: Thursday, March
>>>> 14, 2013 12:58 PM To: Kent Leung (kleung) Cc: [email-masked]
>>>> 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?
>>>>
>>>>> 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
>>>>>
>>>>> [mailto:[email-masked]] On Behalf Of Alexandru
>>>>> Petrescu Sent: Thursday, March 14, 2013 12:40 PM To:
>>>>> [email-masked] Subject: Re: [Mip4] Does MIP support RegReq

---

From: Ahmad Muhanna <[email-masked]>
Date: Thu, 14 Mar 2013 22:14:43 +0000

Alex,

The MN/MR needs to send another RRQ; It is not just a warning.
Otherwise, its Registration will timeout and the HA will delete its binding. 

There was a reason for the MN to send a Re-Registration, most probably extends its registration lifetime, for example. 
If the Reply is NOT successful, the MN can NOT assume its registration has been extended successfully. Thus, the MN/MR needs to send another RRP. This uis the behavior I have seen many times of very popular MIP4 MNs.

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

Anyhow; enjoy your IETF meeting!

Best Regards,
Ahmad

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Alexandru Petrescu
Sent: Thursday, March 14, 2013 4:41 PM
To: Kent Leung (kleung)
Cc: [email-masked]
Subject: Re: [Mip4] Does MIP support RegReq authentication without having to do timekeeping?

Kent,

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 21 Mar 2013 16:29:53 +0100

> Otherwise, its Registration will timeout and the HA will delete its

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

>  Thursday, March 14, 2013 4:41 PM To: Kent Leung (kleung) Cc:
>>  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
>>

---

From: Ahmad Muhanna <[email-masked]>
Date: Thu, 21 Mar 2013 16:31:58 +0000

Alex,

Just to close on the issue that the specification does NOT have anything which 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)

      Registration Requests.

"

The specification leaves that to the implementation. However, the specification describe what the MN can do to fix the error. As I said, it is the responsibility of the MN to keep its registration alive at the Home Agent.

What does this mean: 
It is GIVEN: If the MN would like to continue to being served by its Home Agent using the Home address that was allocated to the MN, the MN MUST re-register 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 the 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 maintain 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:[email-masked]] 
Sent: Thursday, March 21, 2013 10:30 AM
To: Ahmad Muhanna
Cc: Kent Leung (kleung); [email-masked]
Subject: Re: [Mip4] Does MIP support RegReq authentication without having to do timekeeping?

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

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

> Registration Reply, before issuing any future Registration Requests."
>
>>> the value requires the shared key between MR and HA.
>>> RRQ1(time=1970), and the RRP1(time=2013) and fake a RREP  towards 
>>> the MR. No?
>>>
>>> Alex
>>>
>>>>
>>>> Kent
>>>>
>>>> 2013 12:58 PM To: Kent Leung (kleung) Cc: [email-masked]
>>>>> Sent: Thursday, March 14, 2013 12:40 PM To: