Subject: RE: [Ipsec] IKEv2: AUTH_AES_XCBC_96

From: "Charlie Kaufman" <[email-masked]>
Date: Sat, 17 Jul 2004 23:45:25 -0700

It is changed back in the pending draft.

	--Charlie

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Kevin Li
Sent: Friday, July 16, 2004 9:30 AM
To: Dondeti, Lakshminath
Cc: [email-masked]
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 it

> belongs 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
.txt 
> seems 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 to
negotiate
>> AUTH_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
>> [email-masked]
>> https://www1.ietf.org/mailman/listinfo/ipsec
>>
>
>

_______________________________________________
Ipsec mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipsec

_______________________________________________
Ipsec mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipsec

---

From: Kevin Li <[email-masked]>
Date: Wed, 21 Jul 2004 10:08:52 -0700

Hi,

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:

--Charlie

-----Original Message-----

Thanks.

Kevin

seems to have it right!

regards,
Lakshminath

Kevin Li wrote:

Hi,

negotiate

Thanks.

Kevin
Cisco Systems