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

[Yoav Nir <[e-mail]>]

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 <[e-mail]> 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.