[IPsec] Re: test vectors for IKEv2 SKEYSEED derivation

Michael Richardson writes:
> Part A
> The problem is that I didn't know what the key size for MD5 and SHA1 is.
> As far as I knew, it was open --- I can use any key size, since
> HMAC just prepends the key to the data.  This for me meant that I should
> have no problems concatenating Ni|Nr

Depends what HMAC-MD5 / HMAC-SHA1 you talk about. For the
AUTH_HMAC_MD5_96, and AUTH_MHAC_SHA1_96 the RFCs 2403 and 2404 clearly
specify that the input key size is 128 bits and 160 bits, and no other
key lengths are supported. For the PRF_HMAC_MD5 and PRF_HMAC_SHA1 the
RFC2104 does NOT specify the key lenght, but says any key lenght is
acceptable.

> Part B
> However, in order to know how much keying material to generate, and how much 
> is going to be SK_d, SK_ai, SK_ar, I need to know how big each one is going 
> to be.  For *ESP* the key size of integrity algorithms is MD5,SHA1 = (16 
> bytes, 20 bytes).

That same applies to the SK_ai, and SK_ar, as they use
AUTH_HMAC_MD5_96 / AUTH_HMAC_SHA1_96.

The only problem is the SK_d, i.e. how many bytes of keying material
needs to be generated for the SK_d.

> SK_d is used in prf+ as specified in 2.17. As that is based upon
> prf, I might assume that the "keysize" for prf is like for ESP, i.e.
> 16 and 20 bytes.

That is what implementations do now, and I think that should be
specified in the future documents. 

> Go back to Part A. If md5 has a 16-byte keysize, then if I provide two 
> 16-byte nonces (the smallest allowable), then I should take 8 bytes from Ni, 
> and 8 bytes from Nr.  Tero's vector clearly didn't do that --- it had 32 
> bytes of input, 16 from each nonce.

No.

Even when we have some key size associated with the PRF to specify how
many bytes we need to generate when generating key to be used for the
PRF, that does not make the PRF to require fixed size key. It can
still take variable size of key, thus no truncation is done, and full
Ni and Nr are used. 

> As I am writing this, I am inserting text from RFC4306, such as below:
> 
> This concerns RFC4306 sections 2.13/2.14.
> 
> 2.13: says:
> 
>     We assume that each encryption algorithm and integrity protection
>     algorithm uses a fixed-size key and that any randomly chosen value of
>     that fixed size can serve as an appropriate key.  For algorithms that
>     accept a variable length key, a fixed key size MUST be specified as
>     part of the cryptographic transform negotiated.
> 
> I understood this to apply to things like AES.

It does not apply to AES, which is encryption algorithm. It applies to
the RPF_AES128_XCBC which is PRF function. And note there is some
problems with that already (RFC4434 vs RFC 3664). 

> Does this *ALSO* apply to MD5 and SHA1?

No.

> Are these considered to be variable length, and we need to include a keysize 
> attribute for the *PRF* and *INTEGRITY* options for the PARENT SA?

No. For integrity the key size is fixed by the RFC2403 and RFC2404.
For the PRF the key size is whatever is given to the PRF. The only
thing we should define is the length of the SK_d. 

> Section 3.3.5 "Key Length" says that it applies to Encryption
> Algorithms only.

Yes.

> (Also is it just me, or has the table in 3.3.5, Attribute Type/Value/Format
> been word wrapped on us?)

Yes seems to be, should be:

         Attribute Type                 Value        Attribute Format
      --------------------------------------------------------------
      RESERVED                           0-13
      Key Length (in bits)               14                 TV
      RESERVED                           15-17
      RESERVED TO IANA                   18-16383
      PRIVATE USE                        16384-32767
-- 
kivinen@safenet-inc.com

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