Hi Scott,
OK, I see your point (no pun intended). Regarding ECDH secret reuse, can
you please review http://tools.ietf.org/html/rfc5996#section-2.12. That
section was supposed to cover the relevant security considerations. In
fact I think your attack is alluded to in the paper we reference from
that section (see Sec. 5, first paragraph).
If this needs to become a MUST requirement for IKEv2 peers using ECDH,
it needs to be spelled out and not left as an exercise to the reader.
But we have to understand whether this is a general requirement, or it
only applies to peers that are reusing ECDH private keys for multiple
IKE sessions.
Thanks,
Yaron
On 12/01/2012 08:44 PM, Scott Fluhrer (sfluhrer) wrote:
I would humbly disagree. A peer might try to send us an invalid KE, with a
bogus point that acts as if it were of small order with our implementation; let
us call this bogus point P, and its small order n. We would then generate sk's
based on the point (e mod n)P (where e is the value of our ECDH secret);
because n is small, that allows the attacker to recover the value (e mod n).
If we reuse the same ECDH secret for multiple exchanges (which is normally
safe), this allows someone who controls some of the peers we talk to to recover
the secret value for exchanges he does not control; this is not good.
Hence, we need to either mandate checking the point we receive, or forbid ECDH
secret reuse.
-----Original Message-----
From: Yaron Sheffer [mailto:[email protected]]
Sent: Saturday, December 01, 2012 5:32 AM
To: Scott Fluhrer (sfluhrer)
Cc: Yoav Nir; Johannes Merkle; IPsecme WG; Manfred Lochter; Sean P. Turner; Dan
Harkins; [email protected]
Subject: Re: [IPsec] I-D on Using the ECC Brainpool Curves for IKEv2 Key
Exchange
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: [email protected] [mailto:[email protected]] 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;
[email protected]
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 <[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
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
