Re: [IPsec] I-D on Using the ECC Brainpool Curves for IKEv2 Key Exchange

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) <sfluhrer@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-bounces@ietf.org [mailto:ipsec-bounces@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-ise@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 <dharkins@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