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

From: [email-masked]
Date: Mon, 22 Apr 2013 11:47:45 -0700

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/

---

From: Johannes Merkle <[email-masked]>
Date: Tue, 23 Apr 2013 19:41:13 +0200

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

> _______________________________________________
> IPsec mailing list
> [email-masked]
> 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
[email-masked]
www.secunet.com

---

From: Dan Brown <[email-masked]>
Date: Tue, 23 Apr 2013 18:34:31 +0000

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: [email-masked] [mailto:[email-masked]] On Behalf
> Of Johannes Merkle
> Sent: Tuesday, April 23, 2013 1:41 PM
> To: [email-masked]
> Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-dh-checks-03.txt
> 
> 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

---------------------------------------------------------------------
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.

---

From: Johannes Merkle <[email-masked]>
Date: Thu, 25 Apr 2013 14:43:48 +0200

> 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

 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

---

From: Yaron Sheffer <[email-masked]>
Date: Thu, 25 Apr 2013 15:49:39 +0300

I agree. I will implement the change when Sean completes his AD review 
of the draft.

Thanks,
	Yaron