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

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

Jeff,

By the way, I am okay with using PHY SYNC field with MAC key with short lifetime (> 4 hours)


Thanks,
JH SONG

----- Original Message -----
From: "JunHyuk Song" <junhyuk.song@samsung.com>
To: <STDS-802-16-MOBILE@listserv.ieee.org>
Sent: Wednesday, June 16, 2004 7:19 PM
Subject: 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
> >
> >
>
>