Subject: [Ipsec] draft-ietf-ipsec-ike-ecp-groups-02.txt / ecc-groups-08.txt

From: Tero Kivinen <[email-masked]>
Date: Thu, 16 Feb 2006 18:10:22 +0200

Some comments to the ECP/ECC group drafts.

The ECP and ECC drafts are inconsistent in the way they describe the
actual format of the final secrets and KE payloads. Note, that IKEv2
(RFC4306) does NOT specify any format for the KE payloads nor the
secrets generated for the elliptic curves. The RFC4306 only defines
those formats for MODP groups.

The ECP draft does not define what format should be used, but it still
uses some format in the test vectors. IKEv1 RFC 2409 does not specify
any format for the ECP group key exchange payloads either. The ECP
draft needs a section explaining what is put to the KE payloads of the
IKEv1 and IKEv2 protocols (Note, that the IKEv1 and IKEv2 uses
different KE payload format). It also needs to specify what is the
final shared secret generated.

>From the test vectors it seems that at least in the IKEv2 the KEi and
KEr payloads are filled with the concatenation of the gix and giy, but
it does not specify what kind of padding (if any) is done when those
values are concatenated to the KE payload. The IKEv2 document does say
that for MODP Diffie-Hellman "The length of the Diffie-Hellman public
value MUST be equal to the length of the prime modulus over which the
exponentiation was performed, prepending zero bits to the value if
necessary." Something similar is required for the ECP groups too.

Also the shared secret value for the ECP groups is not defined
anywhere. The IKEv2 RFC does not specify it, and the ECP draft simply
gives test vector which makes g^ir by combining girx and giry
together. Again no mention about the padding or similar is not given.

Also as far as I understand the giry value does not really add that
much to the shared secret as for each solution girx there is 2
possible y coordinates, thus adding that to the shared secret only
adds one bit of entropy to the shared secret.

The IKEv1 RFC actually omitted to mention how the g^xy is used in the
elliptic curve groups, i.e. whether the both x and y coordinates where
used and whether they were padded or not.

The IKEv2 RFC only says that the "g^ir is the shared secret from
ephemeral Diffie-Hellman exchange. g^ir is represented as a string of
octets in big endian order padded with zeros if necessary to make it
the length of the modulus."

The ecc-groups draft defines format for the KE payload saying:

    	For elliptic curve groups, the data in the KE payload when
	using this group is the octet string representation specified
	in ANSI X9.62, ANSI X9.63, FIPS 186-2, and IEEE P1363 of the
	point on the curve chosen by taking the randomly chosen secret
	Ka and computing Ka*G, where * is the repetition of the group
	addition.

I do not know what ANSI X9.62, ANSI X9.63, FIPS 186-2 or IEEE P1363
say about the octet string representation, but I would think we should
specify the format here, not to refer some external document which is
not available in general (for example the FIPS-182-2 url returns
error).

The ecc-groups also defines format for the secret:

	If the initiator chooses secret i and the responder chooses
	secret r, then the KEi is i*G and KEr is r*G. The raw shared
	secret is the x-coordinate (only) of (ir)*G.

The IKEv1 defines that the format of the KE payload of EC2N groups is:

   The data in the KE payload when using this group is the value x from
   the solution (x,y), the point on the curve chosen by taking the
   randomly chosen secret Ka and computing Ka*P, where * is the
   repetition of the group addition and double operations, P is the
   curve point with x coordinate equal to generator 1 and the y
   coordinate determined from the defining equation. The equation of
   curve is implicitly known by the Group Type and the A and B
   coefficients. There are two possible values for the y coordinate;
   either one can be used successfully (the two parties need not agree
   on the selection).

thus only value of x from the solution. If ecc-groups draft tries to
be compatible with the IKEv1 then at least for IKEv1 that format
should be used (don't know if it is used, as it does not define it but
refers to external documents).

On the other hand I do not know why would be using different format
for ECP and EC2N groups for the KE and shared secret, i.e. for ECP
include both X and Y and for EC2N only include the X. If there is
patent or other reasons not to use one version then we should use that
other version in both cases at least for IKEv2 (where backward
compatibility is not an issue).

Another generic comment for both of these drafts is that they do not
take account that the IKEv1 and IKEv2 IANA registries are separate. To
allocate numbers for both of those you need to allocate the numbers
from both of them. Actually the ecc-groups draft is missing the IANA
considerations section completely. 

For the IKEv2 the correct IANA registry is "Internet Key Exchange
Version 2 (IKEv2) Parameters - Diffie-Hellman Transform Ids".

For the IKEv1 the correct IANA registry is "Internet Key Exchange
(IKE) Attributes - IKE Attributes - Group Description".

Currently the allocated points in both have same values, but for
example the IKEv2 - Diffie-Hellman Transform Ids registry do not have
any values for any of the elliptic curve groups, only for the MODP
groups.

Because of this it might be better not to define any numbers here in
the text, but simply give a group names (like RFC3524 used 1536-bit
MODP group etc) and leave the actual registry work (i.e. which number
matches which named group) to the IANA.

I.e. instead of sections "2.1 Nineteenth Group" change it to section
"2.1 256-bit Random Curve Group" and "2.2 Seventh Group" to "2.2
Koblitz Curve Group Over GF[2^163]" or similar. 

Some other comments to the ecc-groups draft:

The ecc-groups draft have strength estimates which are not taking
account the memory space required to run the algorithms, i.e. it gives
way too big requirements for the DH/DSA/RSA groups. See
http://www.rsasecurity.com/rsalabs/node.asp?id=2088 for more
information (or the strength estimates from the RFC3526)

If talking the space cost in the calculations the 1620 bit RSA key has
the same strength than 256 bit elliptic curve and 128 bit symmetric
key, compared to the 3072 given by the ecc-groups draft.

The ecc-groups draft has also using the non-ietf way when talking
about the 3DES, calling it TDES (for example in section 2), and also
talking about the TDES with key lengths of 168 and 112 bits. The key
length for 3DES used in IPsec is always 168 bits, thus talking about
2-key version of TDES here is just misleading. 

Also the group definitions have very long lines, that should be
breaked up to the shorter, and perhaps adding spaces every 8 hex-digit
as done in RFC 3526 would make the numbers more readable. 
-- 
[email-masked]

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

---

From: Daniel Brown <[email-masked]>
Date: Thu, 16 Feb 2006 11:37:25 -0500

Hi,

> ...

Very helpful comments, so I'll prepare an ECC-09 to address them. 

Thanks,

Dan Brown
(905) 501-3857
http://www.certicom.com