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
