Re: [STDS-802-16-MOBILE] [security] Replay protection
Jeff,
Comment is inlined,
> 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).
It will be difficult to add TLV to almost every MAC message that need Message Authentication Code.
It is not just Privacy Sublayer change.
> 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.
>
Actually, another way is using AES-CCM on management MAC message.
It will cause bandwidth expansion, but it comes with its own Counter.
What do you think?
My two cents,
JH SONG
> So what do you (and other people) think? Do we want solution a),
> solution b), or some third solution?
>
> - Jeff
>
>