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

Re: [STDS-802-16-MOBILE] [security] Revised Security Adhoc Document includes Replay protection



Aditya,

I agree with the general need for coming up with a single solution. In
fact it's a five criteria commitment the group made.

We have 2 PKM versions, 1 and 2. Version 2 contributions are being
actively worked on. I hope that when we achieve resolution on what v2
looks like, it will, within its own scope, have not much optionality. In
the broader scope of v1 and v2, we cannot really limit the optionality.
But constraints along the lines of.. 'If you negotiate PKMv2, then you
shall use the follow algorithms' seem like a good way of simplifying the
spec.

DJ


-----Original Message-----
From: owner-stds-802-16-mobile@LISTSERV.IEEE.ORG
[mailto:owner-stds-802-16-mobile@LISTSERV.IEEE.ORG] On Behalf Of Aditya
Agrawal
Sent: Monday, June 21, 2004 10:30 PM
To: STDS-802-16-MOBILE@LISTSERV.IEEE.ORG
Subject: Re: [STDS-802-16-MOBILE] [security] Revised Security Adhoc
Document includes Replay protection


From a complexity and interoperability point of view, I would discourage
having many optional modes for security. In the end after evaluating the
various options, if the security experts in the group can arrive at
consensus and decide which method is the best, I think there are likely
many people in the WG that would gladly accept that one method. Just my
2 cents ...

Aditya

-----Original Message-----
From: owner-stds-802-16-mobile@listserv.ieee.org
[mailto:owner-stds-802-16-mobile@listserv.ieee.org] On Behalf Of On
behalf of Seong Choon Lee
Sent: Monday, June 21, 2004 7:39 PM
To: STDS-802-16-MOBILE@listserv.ieee.org
Subject: Re: [STDS-802-16-MOBILE] [security] Revised Security Adhoc
Document includes Replay protection

Hi all

I think that we may use AES in the CBC-MAC(Cipher Block chaining-Message
Authentication Code) mode to compute integrity for MAC management
messages.

According to the paper("Performance Comparison of MAC Algorithms for the
IPSEC", http://www.engr.mun.ca/~howard/PAPERS/necec_2003b.pdf), the
timing performance of HMAC-SHA-1 and CBC-MAC-AES do not have significant
difference.

HMAC based on secure hash algorithm (HMAC-SHA) has been recommended for
message authentication in several network security protocols. The key
reasons behind this are the free availability, flexibility of changing
the hash function and reasonable speed, among others.

Therefore, I think that the HMAC-SHA is used to compute integrity for
MAC management messages (if CBC-MAC-AES is required, it will be
optional). And, AES-CCM(Counter with CBC-MAC) is applied in data
messages( not in MAC management messages) because it can provide the
confidentiality(counter mode) and integrity(CBC-MAC mode).

What do other people think about AES-MAC ?

Thanks

- Seong Choon Lee, (Young Man Park)
  KT



----- Original Message -----
From: "Jeff Mandin" <jmandin@STREETWAVES-NETWORKS.COM>
To: <STDS-802-16-MOBILE@listserv.ieee.org>
Sent: Friday, June 18, 2004 12:01 PM
Subject: [STDS-802-16-MOBILE] [security] Revised Security Adhoc Document
includes Replay protection


> The latest revision of the Security Adhoc working document includes
> revisions for Replay protection.
>
> I made the following changes to JunHyuk's text:
>
> 1.  Binding of the Frame Number in the HMAC (ie. "cryptosynchronized")

> must always be performed in PKMv2.  So it doesn't need to be an option

> in SBC-REQ/RSP.
>
> 2.  The HMAC function can accept an arbitrarily long text, so we might

> as well prepend the PHY Sync field  to the message text (rather than
> applying XOR).
>
> Comments.are invited.  There is also some initial text about AES-MAC
> which I invite people to review.
>
> - Jeff Mandin
> Security Adhoc chair
>