Re: [IPsec] I-D Action: draft-ietf-ipsecme-dh-checks-03.txt

> 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: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf
>> Of Johannes Merkle
>> Sent: Tuesday, April 23, 2013 1:41 PM
>> To: ipsec@ietf.org
>> 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
>>> IPsec@ietf.org
>>> https://www.ietf.org/mailman/listinfo/ipsec
>>>
>>
>