Re: [Ipsec] Revising RFC 3664 (AES-XCBC-PRF-128)

Fukumoto Atsushi <atsushi.fukumoto@toshiba.co.jp> Thu, 31 March 2005 04:36 UTC

Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA06097 for <ipsec-archive@lists.ietf.org>; Wed, 30 Mar 2005 23:36:50 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGrNK-0007gR-OB; Wed, 30 Mar 2005 23:33:46 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGrNC-0007gM-BG for ipsec@megatron.ietf.org; Wed, 30 Mar 2005 23:33:38 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA05664 for <ipsec@ietf.org>; Wed, 30 Mar 2005 23:33:35 -0500 (EST)
Received: from inet-tsb5.toshiba.co.jp ([202.33.96.24]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DGrU8-0008Um-RF for ipsec@ietf.org; Wed, 30 Mar 2005 23:40:55 -0500
Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb5.toshiba.co.jp with ESMTP id j2V4WtOD028309; Thu, 31 Mar 2005 13:32:55 +0900 (JST)
Received: (from root@localhost) by tsb-wall.toshiba.co.jp id j2V4WtQX012898; Thu, 31 Mar 2005 13:32:55 +0900 (JST)
Received: from ovp1.toshiba.co.jp [133.199.192.124] by tsb-wall.toshiba.co.jp with SMTP id PAA12891 ; Thu, 31 Mar 2005 13:32:55 +0900
Received: from mx.toshiba.co.jp (localhost [127.0.0.1]) by ovp1.toshiba.co.jp with ESMTP id j2V4WsPX005254; Thu, 31 Mar 2005 13:32:54 +0900 (JST)
Received: by toshiba.co.jp id j2V4WpnA002122; Thu, 31 Mar 2005 13:32:51 +0900 (JST)
Message-Id: <200503310432.j2V4WpnA002122@toshiba.co.jp>
To: Paul Hoffman <paul.hoffman@vpnc.org>
Subject: Re: [Ipsec] Revising RFC 3664 (AES-XCBC-PRF-128)
In-reply-to: paul.hoffman's message of "Wed, 30 Mar 2005 13:41:21 PST." <p0621022bbe70cbebcf34@[10.20.30.249]>
Date: Thu, 31 Mar 2005 13:32:50 +0900
From: Fukumoto Atsushi <atsushi.fukumoto@toshiba.co.jp>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 79899194edc4f33a41f49410777972f8
Cc: IPsec WG <ipsec@ietf.org>
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IP Security <ipsec.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
Sender: ipsec-bounces@ietf.org
Errors-To: ipsec-bounces@ietf.org

draft-hoffman-rfc3664bis-00.txt states:
   o  The key length restriction of exactly 128 bits in [AES-XCBC-MAC]
      is changed.  The key for the AES-XCBC-PRF-128 algorithm is created
      using the formula in [HMAC-definition].  This brings
      AES-XCBC-PRF-128 in alignment with HMAC-SHA1 and HMAC-MD5 when
      used as PRFs in IKE.

I didn't understand which formula in [HMAC-definition] (RFC2104) this
is refering to.  RFC2104 states:
   The authentication key K can be of any length up to B, the
   block length of the hash function.  Applications that use keys longer
   than B bytes will first hash the key using H and then use the
   resultant L byte string as the actual key to HMAC.

But this assumes H to accept an arbitrary length of octets as its only
input.  What is the H for the case of AES-XCBC-PRF-128?


					FUKUMOTO Atsushi
					atsushi.fukumoto@toshiba.co.jp

_______________________________________________
Ipsec mailing list
Ipsec@ietf.org
https://www1.ietf.org/mailman/listinfo/ipsec