I agree. I will implement the change when Sean completes his AD review
of the draft.
Thanks,
Yaron
On 2013-04-25 15:43, Johannes Merkle wrote:
I disagree that (x,y)=(0,0) should be interpreted as the point-at-infinity. I
advise against a separate check for this, and instead to rely on the
length-check and the curve equation-check.
I agree. As no encoding is defined for the point-at-infinity in IKEv2, there
can be no check for it.
Section 2.3 should be changed from
A receiving peer MUST check
that its peer's public value is valid; that is, it is not the point-
at-infinity, and that the x and y parameters from the peer's public
value satisfy the curve equation, that is, y**2 = x**3 + ax + b mod p
to
A receiving peer MUST check
that its peer's public value is valid; that is, the x and y parameters
from the peer's public value satisfy the curve equation, that is,
y**2 = x**3 + ax + b mod p
And a note should be added explaining, why a check for the point-at-infinity,
as suggested by other standards, is not
applicable for IKE.
Johannes
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf
Of Johannes Merkle
Sent: Tuesday, April 23, 2013 1:41 PM
To: [email protected]
Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-dh-checks-03.txt
I hope I am not too late as the document write-up has already been sent
out.
Section 2.3 specifies:
A receiving peer MUST check
that its peer's public value is valid; that is, it is not the point-
at-infinity, and that the x and y parameters from the peer's public
value satisfy the curve equation, that is, y**2 = x**3 + ax + b mod
p
How can a peer check this? I am not aware of any encoding rule for the
point-at-infinity in RFC 5903 or RFC 5114. Does
the encoding of SEC1 apply, where the point-at-infinity is encoded to
0x00? According to RFC 5903 this would be padded
with zeros, so that the decoding algorithm of the receiving peer would
obtain x=0 and y=0. These do certainly not
fulfill the curve equation as the discriminant -16*(4*a^3 + 27*b^2)
must be non-zero.
So isn't the requirement to check that the value it is not the point-
at-infinity confusing and redundant?
Johannes
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the IP Security Maintenance and
Extensions Working Group of the IETF.
Title : Additional Diffie-Hellman Tests for IKEv2
Author(s) : Yaron Sheffer
Scott Fluhrer
Filename : draft-ietf-ipsecme-dh-checks-03.txt
Pages : 11
Date : 2013-04-22
Abstract:
This document adds a small number of mandatory tests required for
the
secure operation of IKEv2 with elliptic curve groups. No change
is
required to IKE implementations that use modular exponential
groups,
other than a few rarely used so-called DSA groups. This document
updates the IKEv2 protocol, RFC 5996.
The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-ipsecme-dh-checks
There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-ipsecme-dh-checks-03
A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-dh-checks-03
Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/
_______________________________________________
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
