Subject: RE: [mobile-ip] MIPv6: RR replay detection

From: "Greg O'Shea" <[email-masked]>
Date: Thu, 5 Dec 2002 09:21:55 -0000

If people want to live with #2 that's up to them. But consider:

DestroyRemoteNonces( CN )
{
   RunRR(CN)          // Get nonces.
   SendBU(CN,HoA,CoA) // Bind using nonces.
   SendBU(CN,HoA,HoA) // Invalidate all nonces on CN.
}

To save round trips the attacker can replace the two SendBU with a
single SendBU(CN,HoA,CoA,life=1sec)

Anyone can do this. If the CN is a mobile phone it probably doesn't
matter, but if the CN is a stonking great web-farm it probably does
matter.

Maybe replace this:
"The correspondent node can ... index too often."
with something like this:
"Alternatively, if memory constrained, then whenever a binding
authenticated using a nonce of a given age expires or is deleted then
the correspondent MAY invalidate all nonces of equal or greater age. Any
delay in doing so leaves an opportunity for replay attack in the
interim, so any such delay SHOULD be configurable."

The replay opportunity is somewhat limited because the real MN may have
registered, or be about to register, a new binding with a higher SeqNo.

With #1 I guess you could run out of memory, but the same could happen
with active bindings. Therefore the CN should reuse a "ghost" binding if
it gets a valid BU for the same HoA.

Greg
>-----Original Message-----
>From: Jari Arkko [mailto:[email-masked]] 
>Sent: 04 December 2002 20:04
>To: Greg O'Shea
>Cc: Mobile IPv6 mailling list; Charles E. Perkins
>Subject: Re: [mobile-ip] MIPv6: RR replay detection
>
>
>
>Greg,
>
>We have to make sure that a replay attack can't be launched. 
>There's two potential ways of achieving this:
>
>   1) Keeping a 'ghost' BCE entry around even after deletion so that we
>      can make sure the same tokens are not reused. This 
>requires memory.
>
>   2) Letting nonce indices expire sooner. Yes, these could be 
>quite recent
>      as you point out, so this would hurt the MNs trying to 
>send BUs at this
>      time. OTOH, no memory is needed.
>
>What 5.2.8 tries to suggest is the two potential techniques 
>above. While you (and me) do not like deleting too recent 
>nonces, perhaps you can live with the CN's freedom to choose 
>either technique? Or would you like to require only the first 
>technique to be used?
>
>If you can live with both techniques then we need a 
>clarification of the text in 5.2.8. The current text seems to 
>say only the second technique is appropriate. If I change 
>"can, for instance, change the nonce" to "could also change 
>the nonce", would that be better?
>
>Jari
>
>
>

---

From: Charlie Perkins <[email-masked]>
Date: Fri, 06 Dec 2002 01:23:56 -0800

Hello Jari,

The nonce expiry can be handled in such a way as to not
affect any other mobile nodes.  In fact, there are many
suitable ways to implement the nonce handling.  If we
specify that nonce invalidation MUST happen on at least
a per-mobile basis, then various implementations can take
care of the invalidation on a finer or coarser granularity,
depending on system requirements.  For example, invaliding
nonces for ALL mobiles is pretty coarse granularity, but
satisfies the requirement.  The cost is reduced performance
from the point of view of unfortunate mobile nodes, but that
penalty should happen only infrequently.

Regards,
Charlie P.

Jari Arkko wrote:

> Greg O'Shea wrote:
> (Well, one or two nonces per BU.)
>
> Agreed.
> Let's think about this.
> Strictly speaking, the ghost entries don't require any new memory as such
> and can use the same memory that the original binding used. However, you
> could fill your whole cache with such entries, so invalidating some nonces
> would free up some memory in the cache. With the expense of potentially
> rejecting any BUs that are on their way to you.
>
> I'd prefer not to leave it open for the implementor to protect against
> replays.
>
> So where does this leave us? I think we agree about the potentially
> harmful effects. Perhaps we should just indicate that the early
> expiry of nonces MAY be used and say what the harmful effects are.
> Editing your text further:
>
>     "Alternatively, if memory is very constrained, the correspondent
>     MAY invalidate all nonces as old or older than the ones used for
>     the binding being deleted. This may, however, impact the ability
>     to accept Binding Updates from mobile nodes that have recently
>     received keygen tokens. This alternative is therefore recommended
>     only as a last measure."
>
> Jari

---

From: Jari Arkko <[email-masked]>
Date: Fri, 06 Dec 2002 12:41:35 +0200

Charlie Perkins wrote:

> satisfies the requirement. 

I see what you are saying. We don't want to mandate specifically
invalidating all nonces of older than T. We do need to say that
the ones used for the creation of this binding have to be invalidated,
however (for the alternative that is discussed now). How about

  "Alternatively, if memory is very constrained, the correspondent
   node MAY invalidate the nonces that were used for the binding
   being deleted (or some larger group of nonces that they belong to).
   This may, however, impact the ability to accept Binding Updates
   from mobile nodes that have recently received keygen tokens.
   This alternative is therefore recommended only as a last measure."

Jari