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: ipsec-boun...@ietf.org [mailto:ipsec-boun...@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-...@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 <dhark...@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
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
