MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <18252.10747.455107.780676@fireball.kivinen.iki.fi>
Date: Tue, 27 Nov 2007 16:30:19 +0200
From: Tero Kivinen <kivinen@iki.fi>
To: Michael Richardson <mcr@sandelman.ca>
Subject: [IPsec] Re: test vectors for IKEv2 SKEYSEED derivation
In-Reply-To: <fig8ap$do5$1@ger.gmane.org>
References: <fhe1bp$7h0$1@ger.gmane.org> <fia7cq$t93$1@ger.gmane.org>
 <18250.58764.542898.587852@fireball.kivinen.iki.fi>
 <fig8ap$do5$1@ger.gmane.org>
Cc: ipsec@lists.ietf.org
Precedence: list
Errors-To: ipsec-bounces@ietf.org

Michael Richardson writes:
> Well, the statement does apply to encryption algorithms (it says say that),
> but here, I understand you..

Oh, sorry, I didn't check the where you cut & pasted that text, I
assumed it was from 2.14 i.e. about SKEYSEED generation, but that was
from 2.13 i.e. from generating key material. So that text applies to
all of the things generated out from the SKEYSEED, i.e SK_d, SK_ai,
SK_ar, SK_ei, SK_er, SK_pi, and SK_pr.

> if we negotiated PRF_AES128_XCBC, then are you 
> saying that there would have had to be an attribute of "keysize=128" 
> included?  It seems that "128" is included in the name of the PRF?

No, we do not need keysize (and cannot have it) in that case, as the
PRF_AES128_XCBC is fixed key length algorith, that only accepts keys
of length of 128 bits, as defined in the section 4.1 of the RFC 3566
referenced from the section 2 of the RFC 3664 referenced from section
3.3.2 transform type 2 table of the RFC 4306.

Note, that it is not whether the underlaying algorithm can accept
variable length keys, it is whether the algorithm used in the IKE can
be used with variable lenght keys. 
-- 
kivinen@safenet-inc.com


_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www1.ietf.org/mailman/listinfo/ipsec