With ECDH, there are two separate EC points that are output by the algorithm:
- There's the public value xG (where x is our secret); this is passed in the KE payload - There's the shared secret value xyG (where x is our shared secret, and y is the peer's secret); this is used in the key derivation function. What RFC5903 says is: - The public value xG will be expressed as explicit x, y coordinates. - The shared secret value xyG (that is, the value we give to the sk generation function) will be only the x coordinate; the y coordinate will not be used. Yes, this implies that doing point compression on the shared secret value doesn't make much sense (as point compression discards all but one bit of y -- the format that RFC5903 chooses already discards all the bits of y). However, the argument about point compression was never about the shared secret value; instead, it was about the repesentation that appeared in the KE payload (that is, the one that is specified to have both the x and y coordinates). As for Dan's question, it was about whether we should validate the public value we get from the peer, well, the public value does have explicit x and y coordinates, and so it makes sense to check them. -----Original Message----- From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of Yoav Nir Sent: Friday, November 30, 2012 4:39 PM To: Johannes Merkle Cc: IPsecme WG; Manfred Lochter; Sean P. Turner; Dan Harkins; rfc-...@rfc-editor.org Subject: Re: [IPsec] I-D on Using the ECC Brainpool Curves for IKEv2 Key Exchange Hi Johannes, Dan't question made me realise something I hadn't noticed before. In section 2.3, the draft says: For the encoding of the key exchange payload and the derivation of the shared secret, the methods specified in [RFC5903] are adopted. In an ECP key exchange in IKEv2, the Diffie-Hellman public value passed in a KE payload consists of two components, x and y, However, according to RFC 5903: The Diffie-Hellman shared secret value consists of the x value of the Diffie-Hellman common value. In fact RFC 5903 replaced 4753 just to say that the encoding consists only of x, not both x and y. This also relates to Dan't question. If the y value is missing, what is there to verify? Yoav On Nov 30, 2012, at 7:57 PM, Dan Harkins <dhark...@lounge.org> wrote: > > Hi Johannes, > > On Fri, November 30, 2012 4:11 am, Johannes Merkle wrote: >> We have submitted a new revision of the Internet Draft on Using the >> ECC Brainpool Curves (defined in RFC 5639) for IKEv2 Key Exchange >> https://datatracker.ietf.org/doc/draft-merkle-ikev2-ke-brainpool/ >> >> Since there was considerable objection to the point compression >> method in the WG, we have removed this option altogether and define >> only the uncompressed KE payload format, which is in full accordance >> with RFC 5903. >> >> >> Any feedback is welcome. > > I see that there is a requirement that an implementation MUST verify > that the D-H common value is not the point-at-infinity. Do you think > there should also be a requirement that an implementation MUST verify > that the x- and y-coordinates received from a peer satisfy the > equation of the negotiated curve (and abort the exchange if not)? > > regards, > > Dan. _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
