Right. I cut-and-pasted and didn't notice that it said "shared secret". Never mind.
On Dec 1, 2012, at 12:00 AM, Scott Fluhrer (sfluhrer) <sfluh...@cisco.com> wrote: > 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 > > Email secured by Check Point _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
