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