Pasi.Eronen@xxxxxxxxx wrote:
Paul Hoffman wrote:
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".
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.
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.)
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
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf