> 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
