Re: [STDS-802-16-MOBILE] [security] Revised Security Adhoc Document includes Replay protection
I agree with DJ.
One of the major requirement for PKMv2 is minizing crpyto primitives and AES OMAC is IPR free efficient NIST recommended MAC algorithm.
Regards,
JH SONG
----- Original Message -----
From: "Johnston, Dj" <dj.johnston@INTEL.COM>
To: <STDS-802-16-MOBILE@listserv.ieee.org>
Sent: Tuesday, June 22, 2004 11:54 AM
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
> >
>
>