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

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