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

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



Title:
JunHyuk Song wrote:
Jeff,

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


  
I'm OK with that also.  What's left then is to define precisely how the key will be refreshed and what happens when the refresh fails.  It's probably not a problem to establish a new AK (ie. with PKM-Establish-Key handshake) without doing a full reauthentication.

I was hoping that someone would say something about AES MAC as I had been looking for info.  But we need to protect the case of SHA-based HMAC anyway.

- Jeff
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