Subject: [Ipsec] Integrity and key length

From: [email-masked]
Date: Thu, 13 Oct 2005 20:46:57 -0400

Pasi,

>    This is incorrect. The AES-based integrity and pseudo-random
>    functions defined in this document always use a 128-bit key.  In
>    fact, there are currently no integrity or PRF algorithms that use
>    the key length attribute (and we recommend that they should not
>    be defined in the future either).

Hmm ... draft-mcgrew-aes-gmac-esp-00.txt is using AES with a variable
key length in a MAC and is using the key length attribute.  This didn't
come up with the AES XCBC MAC (RFC 3566) because its AES key length is
fixed at 128 bits.  If the key length attribute is really a bad idea
for integrity algorithms, this draft will need to be certain to allocate
3 transform identifiers for the possible 128 bit, 192 bit and 256 bit
key lengths.

I thought I'd check here before sending the authors a strong suggestion
to allocate 3 transform identifiers (although they seem to be already
halfway there, if one compares Sections 9.3 and 13 of the draft).

Thanks,
--David
----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
[email-masked]        Mobile: +1 (978) 394-7754
----------------------------------------------------

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

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 14 Oct 2005 13:40:40 +0300

> halfway there, if one compares Sections 9.3 and 13 of the draft).

If we read the key length attribute description from the ikev2 draft,
it says:
----------------------------------------------------------------------
   - Key Length

      When using an Encryption Algorithm that has a variable length key,
      this attribute specifies the key length in bits. (MUST use network
      byte order). This attribute MUST NOT be used when the specified
      Encryption Algorithm uses a fixed length key.
----------------------------------------------------------------------

That seems to indicate it is only for encryption algorithm, not for
MACs or PRFs. I would actually think it would be best to only select
ONE key length to be used in the GMAC, similarly what was done RFC
3566. Is there really need to support other key lengths than 128 now?
If so why was it enough to support only that in RFC3566?

So my proposal would be that draft-mcgrew-aes-gmac-esp-00.txt is
modified so that it DOES NOT use key lenght attribute, and it uses
fixed 128 bit key for the AES.

The output of the MAC is always 128 bits anyways, so I do not think we
gain anything (provided AES is secure) by using longer keylenghts for
the AES MACs.
-- 
[email-masked]