I would humbly disagree. A peer might try to send us an invalid KE, with a bogus point that acts as if it were of small order with our implementation; let us call this bogus point P, and its small order n. We would then generate sk's based on the point (e mod n)P (where e is the value of our ECDH secret); because n is small, that allows the attacker to recover the value (e mod n).
If we reuse the same ECDH secret for multiple exchanges (which is normally safe), this allows someone who controls some of the peers we talk to to recover the secret value for exchanges he does not control; this is not good. Hence, we need to either mandate checking the point we receive, or forbid ECDH secret reuse. -----Original Message----- From: Yaron Sheffer [mailto:[email protected]] Sent: Saturday, December 01, 2012 5:32 AM To: Scott Fluhrer (sfluhrer) Cc: Yoav Nir; Johannes Merkle; IPsecme WG; Manfred Lochter; Sean P. Turner; Dan Harkins; [email protected] Subject: Re: [IPsec] I-D on Using the ECC Brainpool Curves for IKEv2 Key Exchange Actually, I think we have it wrong. There is no reason for a *valid* peer to send an incorrect KE. And IKEv2 already protects against a MITM doing such a thing. As we all know, the protocol assumes that messages #3 and #4 can be observed by an attacker, and protects against malicious changes to any of the 4 messages, including the KE value. In other words, I would say this is a QA-level test that MAY be performed by the sender. Not one that MUST be performed by the recipient. By the way, there are related protocols that need this test for their security and do include it: SPSK, and my own RFC 6631 (IKEv2 with PACE). See e.g. https://tools.ietf.org/html/rfc6631#section-3.4. Thanks, Yaron On 12/01/2012 12:00 AM, Scott Fluhrer (sfluhrer) 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: [email protected] [mailto:[email protected]] 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; > [email protected] > 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 <[email protected]> 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 > [email protected] > https://www.ietf.org/mailman/listinfo/ipsec > _______________________________________________ > IPsec mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/ipsec > _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
