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

Johannes,

Good catch. This probably requires a clarification.

I would suggest that the existing formats (x,y) of the correct length imply a point in the finite plane, and in particular not the point at infinity.  In other words, whatever length-checking that peers currently use probably suffices to check for this condition of not being the point-at-infinity.

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.

Elliptic curves exist, e.g. y^2 = x^3 + x, for which (0,0) is a point on the curve, but the point (0,0) would have order two, so would normally be considered invalid (excluded by a cofactor check etc.).

In the SEC1 format that you mention, which is similar to the IEEE and ANSI format, the 00 encoding occupies the initial octet position.  This first octet acts like a tag, and takes a non-zero value when the point is on the finite plane.  It seems that IKE does not use this tag octet.

Best regards,

Dan

> -----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
> >
> 
> 
> --
> 
> Mit freundlichen Grüßen,
> Dr. Johannes Merkle
> Principal Beratung, Elektronische Identitäten
> Public Sector
> secunet Security Networks AG
> Mergenthaler Allee 77
> 65760 Eschborn
> Germany
> Telefon +49 201 54 54-3091
> Telefax +49 201 54 54-1325
> Mobil   +49 175 2224439
> johannes.merkle@secunet.com
> www.secunet.com
> _______________________________________________
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.