Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: [STDS-802-16-MOBILE] [security] Replay protection

JunHyuk,

JunHyuk Song wrote:

>
>[JM]: Another thing is that most of the 24 bits are "wasted".  What I mean by this is that within a particular cycle of the Frame Number, only a few values will be used to protect a particular MAC management message type.
>
>I cannot agree you on that.  frame number is incremented sequentially in every 5 msec, it means that same value will be only repeated in every 4 hours.
>
>
>
Except that as you said:  AK lifetime is likely to be longer than 4 hours.

So that if the MSS hasn't moved, an attacker can replay an old frame
when the (publicly available) Frame Number comes around again.

>[JM]: Alternative Suggestion:  Substitute a specialized Counter rather than using the Frame Number.
>
>That is one way, we can prevent replay attack.
>My concern is synchronization of the counter between MSS and BS.
>It will be very difficult to re-synchronize counter between MSS and BS.
>We can use window approach, but it will cause extra signaling message when MSS and BS loss synchronization.  Moreover it will impact on existing MAC generic header
>
>
>
Yes, I agree that we don't want the overhead of counter
synchronization.   We shouldn't change the generic MAC header either -
but I think we can create a Window-based approach without much extra
signalling and without changing the generic header (ie. we just use TLVs).

Let me try to summarize where we are in this discussion:

    1.  The most natural way to prevent Replayed messages is use the
Frame Number as an input to the HMAC, since the Frame Number proves
irrefutably whether a message is current or not.

     2.  In practice however, the Frame Number repeats within an AK
lifetime.  So an attacker can replay a message from the last time that
this Frame Number was used.

     3.  Potential solutions are:

            a) Require that a new AK be established before the Frame
Number begins to repeat

             b) Use a Counter that isn't tied to Frame Number, and use
an IPSEC-style sliding window to decide whether or not the message is
"current".

I'm trying to think of a third solution that would use the Frame Number
together with some extra bits.  But it still eventually comes down to
requiring a sliding window.

So what do you (and other people) think?   Do we want solution a),
solution b), or some third solution?

- Jeff