Re: [STDS-802-16-MOBILE] [security] Revised Security Adhoc Document includes Replay protection
Hello All,
I would like to remind you that the TGe is an amendment to the TGd
draft, and as such, I don’t think that modes can be removed from the
standard.
I think that better approach is to have the three options (HMAC-SHA1,
RSA and AES-CBC-MAC) and say that for MSS supporting PKMv2, the relevant
options are the last two.
The base scenario for such decisions should be the mixed one, in which
TGe BS works with TGd SS, or vice versa.
In addition, such decisions of replacement of modes, or similar ones
probably should be accompanied with technical motivation (i.e. some
technical reference which provides justification to the decision), but
since I'm aware of the constellation of the group, I'm probably naïve in
this approach.
Regards,
Itzik.
-----Original Message-----
From: owner-stds-802-16-mobile@listserv.ieee.org
[mailto:owner-stds-802-16-mobile@listserv.ieee.org] On Behalf Of
Johnston, Dj
Sent: Tuesday, June 22, 2004 4:54 AM
To: STDS-802-16-MOBILE@listserv.ieee.org
Subject: Re: [STDS-802-16-MOBILE] [security] Revised Security Adhoc
Document includes Replay protection
Seong,
You are correct. However there is more than one option and there may be
a more optimal solution.
There is a desire (on at least my part) to minimize the number of
underlaying crypto primitives to just RSA and AES. So replacing
HMAC-SHA1 with an AES base MAC is a requirement to achieve this. This
will limit the amount of hardware crypto acceleration blocks required in
silicon implementations.
AES-CBC-MAC achieves its objectives, with some restrictions on how it
may be safely used with messages of varying sizes. To use it, the
appropriate padding and IV rules would need to be incorporated.
NIST are converging on OMAC as the FIPS approved AES MAC.
OMAC is similar to CBC, except that it requires one more round of AES
and it is safe to use with varying size messages.
So in summary:
AES-CBC-MAC AES Based Not FIPS Message length
sensitive Compute efficient
AES-OMAC AES Based FIPS Message length
insensitive Slightly less compute efficient
I will be submitting a proposal for AES-OMAC before the 25th.
We have discussed this a little at the handover adhoc today, since there
is some iteraction with new messages that invoke the HMAC tuple.
DJ
-----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
>