Subject: [Ipsec] Key length attribute (was: Important changes in draft-hoffman-rfc3664bis; please review)

From: [email-masked]
Date: Thu, 13 Oct 2005 16:52:29 +0300

Tero Kivinen wrote:
> [email-masked] writes:
> > The text should also say that for the purpose of algorithm
> > negotiation, this PRF has a fixed key length.  In other words,
> > the "key length" attribute is not included in the SA payloads.
> 
> I was about the send the same comment earlier, but noticed that the
> Key Lenght attribute is defined to be used with Encryption algorithm,
> not with PRFs, so there is not really specified way to tell what is
> the PRF key lenght (i.e. the key length is taken from the actual
> keying material fed to the PRF). 

Hmm... that's true.
 
> > BTW, there's text in IKEv2 -17 that has this wrong. Section 3.3.5
> > says that
> > 
> >    "The only algorithms defined in this document that accept
> >    attributes are the AES based encryption, integrity, and
> >    pseudo-random functions, which require a single attribute
> >    specifying key width."
> > 
> > Only ENCR_AES_CBC and ENCR_AES_CTR accept different key lengths; 
> > and since there's no specified default key length, the key length
> > attribute MUST be included.
> > 
> > But AUTH_AES_XCBC_96 [RFC3566] always uses 128-bit keys, and
> > PRF_AES128_CBC always uses 128-bit AES internally (even 
> with 3664bis).
> 
> That text in the IKEv2 has always confused me, is it so that for
> example ENCR_CAST or ENCR_BLOWFISH cannot be used with any other key
> length than the default, or is it so that key length is not needed if
> it is default, but it can be given?
> 
> The text says that only algorithms defined that accept attributes are
> AES, so that would indicate BLOWFISH or CAST cannot use Key length
> attribute. I think the original text should have said that only
> algorithms that REQUIRE key lengths attributes are the AES based,
> others can use it but it is not required.

Yes, I think the intention was not to prohibit variable-length
keys with e.g. Blowfish. Here's proposed text for the clarifications
document:

   Section 3.3.5 says that "The only algorithms defined in this
   document that accept attributes are the AES based encryption,
   integrity, and pseudo-random functions, which require a single
   attribute specifying key width."

   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).

   For encryption algorithms, the situation is slightly more complex
   since there are three different types of algorithms:

   o  The key length attribute is never used with algorithms that 
      use a fixed length key, such as DES, 3DES and IDEA.
 
   o  The key length attribute is always included for the currently
      defined AES-based algorithms (CBC, CTR, CCM and GCM).  Omitting
      the key length attribute is not allowed; if the proposal does
      not contain it, it has to be rejected.

   o  For other algorithms, the key length attribute can be included
      but is not mandatory. These algorithms include, e.g., RC5, CAST
      and BLOWFISH.  If the key length attribute is not included, the 
      default value specified in [RFC2451] is used.

Does this look right to you?

Best regards,
Pasi

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

---

From: Dan McDonald <[email-masked]>
Date: Thu, 13 Oct 2005 09:59:17 -0400

So glad this thread came up!

> Does this look right to you?

Except for one thing, yes it does.

That one thing:

	- IKE is supposed to be algorithm-agile.  Let's say some grinning
          weirdo comes up with a better-than-AES algorithm, or worse, some
          other grinning weirdo breaks AES and we NEED a new cipher.

	  How will we handle ciphers in the future?

There are two ways to solve this:

	1.) All algorithms must have a default key length that is used when
	    no key-length attribute is present.  This means picking a default
	    size for AES.

	2.) All new algorithms with variable-sized keys are treated like AES,
	    and MUST include a key-length attribute.

I don't care which one of those two is picked, but one of them must be used
to maintain algorithm-agility.

Dan

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 13 Oct 2005 13:25:44 -0700

>to maintain algorithm-agility.

I strongly support the second one. Default key lengths are of no use 
to the user, and are easy to mis-implement, particularly many years 
from now when the vogue may change.

--Paul Hoffman, Director
--VPN Consortium

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 14 Oct 2005 10:55:44 +0300

> Does this look right to you?

Looks perfect for me.
-- 
[email-masked]