Subject: Re: [Ipsec] AES Algorithm Negotiation in IKE

From: Tero Kivinen <[email-masked]>
Date: Mon, 1 Nov 2004 11:25:18 +0200

Paul Koning writes:
> Similarly, ICV length for the combined algorithms should be another
> parameter just like the key length -- not encoded in the algorithm
> ID.  

Note, that the transform attributes are AND'ed together, i.e. there
must not be multiple transform attributes in one transform,  and all
of them must be selected. I.e. if you want to propose 128, 192 bit AES
with 8 and 12 octect ICVs you have following proposals:

(with transform attributes):

proposal #1, ID = ESP, SPI size = 4, # of transforms = 5, SPI = 0x12345678
	trasform type = ENCR, ID = ENCR_AES_CCM, len = 16
		transform attribute: type = key length, value = 128
		transform attribute: type = ICV length, value = 8
	trasform type = ENCR, ID = ENCR_AES_CCM, len = 16
		transform attribute: type = key length, value = 128
		transform attribute: type = ICV length, value = 12
	trasform type = ENCR, ID = ENCR_AES_CCM, len = 16
		transform attribute: type = key length, value = 192
		transform attribute: type = ICV length, value = 8
	trasform type = ENCR, ID = ENCR_AES_CCM, len = 16
		transform attribute: type = key length, value = 192
		transform attribute: type = ICV length, value = 12
	trasform type = INTEG, ID = AUTH_HMAC_SHA1_96, len = 8

or with the ICV included in the ID, and still using the key length
defined in the IKEv2 draft:

proposal #1, ID = ESP, SPI size = 4, # of transforms = 5, SPI = 0x12345678
	trasform type = ENCR, ID = ENCR_AES_CCM_ICV_8, len = 12
		transform attribute: type = key length, value = 128
	trasform type = ENCR, ID = ENCR_AES_CCM_ICV_12, len = 12
		transform attribute: type = key length, value = 128
	trasform type = ENCR, ID = ENCR_AES_CCM_ICV_8, len = 12
		transform attribute: type = key length, value = 192
	trasform type = ENCR, ID = ENCR_AES_CCM_ICV_12, len = 12
		transform attribute: type = key length, value = 192
	trasform type = INTEG, ID = AUTH_HMAC_SHA1_96, len = 8

and if we remove the key length parameter for the AES too:

proposal #1, ID = ESP, SPI size = 4, # of transforms = 5, SPI = 0x12345678
	trasform type = ENCR, ID = ENCR_AES_CCM_128_ICV_8, len = 8
	trasform type = ENCR, ID = ENCR_AES_CCM_128_ICV_12, len = 8
	trasform type = ENCR, ID = ENCR_AES_CCM_128_ICV_8, len = 8
	trasform type = ENCR, ID = ENCR_AES_CCM_128_ICV_12, len = 8
	trasform type = INTEG, ID = AUTH_HMAC_SHA1_96, len = 8

The total lenght of SA payloads will be 88, 72 and 56 bytes.

The real benefit from using the transform attributes comes only when
there is lots of different valid values. If there is only 3 different
values (8, 12, and 16 byte ICV), I think using multiple transform IDs
is better. If there is much more like there actually could be for the
key lengths (at least 40, 64, 80, 128, 160, 192, 256, 384, 448, 512
bits have been used), then it is better to use transform attributes.

So my suggestion is that we continue using the key length attribute
for key lengths, but for that kind of parametrized ciphers, where
there is only few (less than 5) possible choices for the parameter, we
encode the parameter inside transform ID.

Note, that it does not matter whether there is multiple or one
parameter, as we need to list all possible combinations of them in all
cases, i.e. if we add another parameter say block length above, we
need to double the number of ENCR transform payloads in all the cases
above, so using transform attribute only wastes bytes on the packet,
but saves it from the IANA registry.

There is one more option which can be used if we really have some new
parameter which we do not want to allocate from the transform
attributes or from the transform ids. We can we create new transform
type for it, i.e:

proposal #1, ID = ESP, SPI size = 4, # of transforms = 5, SPI = 0x12345678
	trasform type = ENCR, ID = ENCR_AES_CCM, len = 12
		transform attribute: type = key length, value = 128
	trasform type = ENCR, ID = ENCR_AES_CCM, len = 12
		transform attribute: type = key length, value = 192
	trasform type = INTEG, ID = AUTH_HMAC_SHA1_96, len = 8
	trasform type = ICV_LEN, ID = ICV_LEN_8, len = 8
	trasform type = ICV_LEN, ID = ICV_LEN_12, len = 8

(this is not really for this case, but I am listing it so people
remember this option too, when making extensions later...)
-- 
[email-masked]

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

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 1 Nov 2004 11:31:14 +0200

Paul Hoffman / VPNC writes:
> Let me push back on this and ask for real-world implementers: do you 
> agree here? That it would be better to create a new 
> algorithm-specific parameter and use the current parameter system 
> rather than two additional algorithms IDs for CCM and zero additional 
> algorithm IDs for GCM?

I would rather see them included in the ID than to create new
transform attributes (I actually already do this same for the key
lengths in my implementation, i.e. I take the key length from the
transform attributes, and encode it to the cipher name I will be
using..., I can do the same for the ICV lengths, but it will result
bigger packets on the wire). 
-- 
[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 1 Nov 2004 11:42:31 +0200

Paul Hoffman / VPNC writes:
> Except that it wasn't used for many years after the spec was 
> implemented because there wasn't a commonly-used encryption algorithm 
> that needed it until AES. I can't say exactly what people had 
> problems with, but I can say that I had at least two implementers who 
> said "we got it wrong the first time we tried" (and that they had 
> fixed the problem before it got to the VPNC interop testing).

Most of the problems were in the form like "including key length
attribute for the fixed key length cipher" or "assume the default of
128 bits for the key lenght if no key length attribute given" etc.

And also having policy which allows only exactly 224 bit blowfish
keys, and the other end proposed 256, thus no proposal chosen.

BTW, key length and ICV length are not really comparable, as there is
much more valid values for the key length than there is for the ICVs.
Especially if you consider ciphers like blowfish.

ICV is not really variable length, there is only very few valid values
for that defined in the drafts.
-- 
[email-masked]