Subject: Last call comments for draft-lepinski-dh-groups-01

From: <[email-masked]>
Date: Tue, 9 Oct 2007 13:32:27 +0300

Two comments about the IPsec-related parts:

1) Section 1 says:

   "Sixteen additional groups subsequently have been defined and
   assigned values by IANA for use with IKE (v1 and v2).  All of
   these additional groups are optional in the IKE context.  Of
   the twenty-one groups defined so far, eight are MODP groups
   (exponentiation groups modulo a prime), ten are EC2N groups
   (elliptic curve groups over GF[2^N]) and three are ECP groups
   (elliptic curve groups over GF[P]).

This is not totally correct. As of this writing, no EC2N groups
have been assigned values for use with IKEv2.  Also, eight of the
ten EC2N groups for IKEv1 are not documented in any RFC. (And yes,
I'm aware of draft-ietf-ipsec-ike-ecc-groups -- but that hasn't
been approved yet, and requires changes before approval.)

2) For IKEv1/IKEv2, the document should explicitly specify how 
ECC points are converted to octet strings (for KE payloads 
and resulting shared secret value). Currently, there are at 
least three incompatible options (RFC 4753, RFC 2409, and 
draft-ietf-ipsec-ike-ecc-groups-10 drafts). I'd suggest just
saying "the same way as in RFC 4753".

Best regards,
Pasi

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

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 10 Oct 2007 10:22:53 -0400

>been approved yet, and requires changes before approval.)

draft-lepinski-dh-groups needs to track 
draft-ietf-ipsec-ike-ecc-groups very carefully. If there is any 
mis-match, we will have interoperability problems in the future.

>saying "the same way as in RFC 4753".

This bodes really poorly for interoperability. 
draft-lepinski-dh-groups needs to be revised to specify one of the 
methods, and that needs to be discussed on the IPsec mailing list. I 
would not assume that implementers would prefer RFC 4753 over 
draft-ietf-ipsec-ike-ecc-groups.

--Paul Hoffman, Director
--VPN Consortium

---

From: <[email-masked]>
Date: Thu, 11 Oct 2007 10:38:30 +0300

Paul Hoffman wrote:

> methods, and that needs to be discussed on the IPsec mailing list. 
> I would not assume that implementers would prefer RFC 4753 over 

I suggested "the same way as in RFC 4753" not because I particularly
prefer that point-to-octet-string conversion method, but because I
would prefer not having three different methods (two is bad enough).

(Note that the current ecc-groups-10 draft actually tries to 
modify the definitions of groups 19/20/21 from RFC 4753: it
reuses the same numbers but with different point-to-octet-string
conversion method.)

Best regards,
Pasi

---

From: Chinh Nguyen <[email-masked]>
Date: Mon, 15 Oct 2007 09:54:28 -0400

> reuses the same numbers but with different point-to-octet-string

Note that interoperability issues involve more than the representation 
of the ECC point (KE payload in IKE). The shared secret is also 
different between RFC 4753 (x + y) and draft-ietf-ipsec-ike-ecc-groups 
(x only). This has implications for the generation of the symmetric keys.

I believe that the representation in draft-ietf-ipsec-ike-ecc-groups is 
more widely used including other standards such as SEC, FIPS 186-2, IEEE 
1363, and ANSI X9.62.

D. Brown at Certicom is writing an update to 
draft-ietf-ipsec-ike-ecc-groups which attempts to resolve this 
interoperability issue. In a nutshell, both formats are supported. 
Practically speaking when it comes to IKE, the responder supports both 
format and chooses the format based on the one chosen by the initiator.

Regards,

Chinh

--
http://www.certicom.com