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

Tero Kivinen wrote:
> Pasi.Eronen@nokia.com 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
Ipsec@ietf.org
https://www1.ietf.org/mailman/listinfo/ipsec