Re: [Ipsec] IKEv2: AUTH_AES_XCBC_96
Kevin Li <kli@cisco.com> Wed, 21 July 2004 17:13 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 NAA04384 for <ipsec-archive@lists.ietf.org>; Wed, 21 Jul 2004 13:13:21 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BnKbv-0003pu-7C; Wed, 21 Jul 2004 13:10:31 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BnKav-0003YK-I1 for ipsec@megatron.ietf.org; Wed, 21 Jul 2004 13:09:29 -0400
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 NAA04204 for <ipsec@ietf.org>; Wed, 21 Jul 2004 13:09:26 -0400 (EDT)
Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BnKbI-0005nr-Cm for ipsec@ietf.org; Wed, 21 Jul 2004 13:09:53 -0400
Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 21 Jul 2004 10:12:06 +0000
X-BrightmailFiltered: true
Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i6LH8sIV009257 for <ipsec@ietf.org>; Wed, 21 Jul 2004 10:08:55 -0700 (PDT)
Received: from [171.71.49.148] (dhcp-171-71-49-148.cisco.com [171.71.49.148]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with ESMTP id AVN20994; Wed, 21 Jul 2004 10:07:43 -0700 (PDT)
Message-ID: <40FEA324.9090700@cisco.com>
Date: Wed, 21 Jul 2004 10:08:52 -0700
From: Kevin Li <kli@cisco.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040616
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: ipsec@ietf.org
Subject: Re: [Ipsec] IKEv2: AUTH_AES_XCBC_96
References: <F5F4EC6358916448A81370AF56F211A503504382@RED-MSG-51.redmond.corp.microsoft.com>
In-Reply-To: <F5F4EC6358916448A81370AF56F211A503504382@RED-MSG-51.redmond.corp.microsoft.com>
X-Spam-Score: 1.1 (+)
X-Scan-Signature: 0ff9c467ad7f19c2a6d058acd7faaec8
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>
Content-Type: multipart/mixed; boundary="===============0526824573=="
Sender: ipsec-bounces@ietf.org
Errors-To: ipsec-bounces@ietf.org
Is IKEv2's algorithm type assignment (e.g now 5 for AUTH_AES_XCBC_MAC_96) supposed to be the same as IANA assignment for the same algorithm (9 for AES-XCBC-MAC) in IPSEC/IKEv1?
Or IANA for IKEv2 algorithms is independent of IANA for IKEv1/IPSEC? Then the IKEv2 needs to convert the number to the one actually used by IPSEC.
Thanks.
-Kevin
==============
Need clarification on TS also:
TS is mandatory in IKE_AUTH exchange but optional in CREATE_CHILD_SA exchange.
HDR, SK {IDi, [CERT,] [CERTREQ,] [IDr,]
AUTH, SAi2, TSi, TSr} -->
vs
HDR, SK {[N], SA, Ni, [KEi],
[TSi, TSr]} -->
Charlie Kaufman wrote:
midF5F4EC6358916448A81370AF56F211A503504382@RED-MSG-51.redmond.corp.microsoft.com" type="cite">It is changed back in the pending draft. --Charlie -----Original Message----- From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Kevin Li Sent: Friday, July 16, 2004 9:30 AM To: Dondeti, Lakshminath Cc: ipsec@ietf.org Subject: Re: [Ipsec] IKEv2: AUTH_AES_XCBC_96 I would agree that AUTH_AES_PRF_128 should change back to AUTH_AES_XCBC_MAC_96 for Transform Type 3 in IKEv2. But to avoid interop issue later, we would like to see that to be standardized in IKEv2. BTW, draft-ietf-ipsec-ikev2-algorithms-05.txt is using the number from older draft of IKEv2. Thanks. Kevin Dondeti, Lakshminath wrote:Yes, it is confusing! The reference, RFC 3664 names it AES-XCBC-PRF-128; it is a PRF, not an integrity algorithm. Perhaps itbelongs in the PRF list corresponding to Transform Type 2. Perhaps AES-XCBC-MAC-96 defined in RFC 3566 might be "AUTH_AES_XCBC_MAC_96" and is the correct #5 in Transform Type 3.http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ikev2-algorithms-05" rel="nofollow">http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ikev2-algorithms-05 .txtseems to have it right! regards, Lakshminath Kevin Li wrote:Hi, The latest draft (IKEv2-14) changed the AUTH_AES_XCBC_96 to AUTH_AES_PRF_128. Since AUTH_AES_XCBC_96 is gone in IKEv2, how are we going tonegotiateAUTH_AES_XCBC_96 which ipsec might request for? Is there a new number for AUTH_AES_XCBC_96? Thanks. Kevin Cisco Systems _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec" rel="nofollow">https://www1.ietf.org/mailman/listinfo/ipsec
_______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec
- [Ipsec] IKEv2: AUTH_AES_XCBC_96 Kevin Li
- Re: [Ipsec] IKEv2: AUTH_AES_XCBC_96 Dondeti, Lakshminath
- Re: [Ipsec] IKEv2: AUTH_AES_XCBC_96 Kevin Li
- RE: [Ipsec] IKEv2: AUTH_AES_XCBC_96 Charlie Kaufman
- Re: [Ipsec] IKEv2: AUTH_AES_XCBC_96 Kevin Li