IKEv2, AES, and Diffie-Hellman groups - a few remarks, a question and a clarification request
Mark Winstead <Mark.Winstead@NetOctave.com> Tue, 27 November 2001 22:04 UTC
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fARM4x800850; Tue, 27 Nov 2001 14:04:59 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA04360 Tue, 27 Nov 2001 16:09:00 -0500 (EST)
Message-ID: <49B96FCC784BC54F9675A6B558C3464E5D0CCD@MAIL.NetOctave.com>
From: Mark Winstead <Mark.Winstead@NetOctave.com>
To: "IPSEC (E-mail)" <ipsec@lists.tislabs.com>
Subject: IKEv2, AES, and Diffie-Hellman groups - a few remarks, a question and a clarification request
Date: Tue, 27 Nov 2001 16:18:23 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C17789.0C22AE0A"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
I finally got to reading IKEv2. I join many in the community in thanking the authors for their efforts. Some comments, et al: Comment 1: There is an inconsistency in security between the "MUST" implement AES and "MUST" implement the 1536 bit group 5 --- In paragraph 7.3.4, the only mandatory encryption algorithm is AES, which has smallest key size of 128 bits. To properly support a 128 bit key with a Diffie Hellman group, one must use a modp group of size between ~2000 bits and ~3100 bits (depending on whose analysis you believe). Yet the only mandatory support for Diffie Hellman groups is the fifth group, described in paragraph 8.5. This is a 1536 bit group, too small by all evaluations I know about. See www.ietf.org/internet-drafts/draft-ietf-ipsec-ike-modp-groups-03.txt <http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ike-modp-groups-03.txt > for more discussion on this point. Comment 2: Diffie-Hellman groups three (8.3) and four (8.4) have a characteristic considered vulnerable by many EC cryptographic experts. Group 3 is a EC2N group with field size 155, and Group 4 is a EC2N group with field size 185. Fields of composite size (size not a prime number) can be decomposed into a field extension of an extension, considered a structural feature vulnerable to cryptographic attacks. This is why it is widely considered wise to pick EC2N groups over fields of prime size. See http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ike-ecc-groups-03.txt <http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ike-ecc-groups-03.txt> for more discussion of the problems with groups three and four Comment 2a: No Diffie-Hellman group in the IKEv2 draft is sufficient for AES. Commonly cited values for key exchanges Symmetric | EC2N | MODP (AES) 128 | 283 | 3072 (AES) 192 | 409 | 7680 (AES) 256 | 571 | 15360 The largest modp group cited is 1536 bits, and the largest EC2N group is 185 It seems to me that there should be some MUST and SHOULD implement pre-defined groups that support the mandatory to be implemented AES. More over, groups in section 8.3 and 8.4 probably should be changed to MAY implement from SHOULD, and group five in 8.5 should be a SHOULD or MAY group, but not a MUST group. Comment 3: No reference to AES in bibliography AES is mandatory, but there is no pointer to a description of it. Comment 4: Shouldn't ECDSA be included among authentication methods (7.3.2, Transform Type 3)? This is essentially DSS (method 2) done with either an EC2N group or a ECP group rather than an MODP group. If Diffie-Hellman groups include EC2N and ECP groups, it seems logical to me that DSS should include them. See http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ike-auth-ecdsa-02.txt <http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ike-auth-ecdsa-02.txt> . Comment 5: In appendix A, in the description class for Diffie-Hellman groups, while a "complete" generator two is not needed, it is insufficient to have simply the definition of a curve and the x coordinate. There are still two possibilities given an x coordinate and a curve -- but all it takes is a single bit to determine which of the two to use. And actually, which y coordinate (generator two) only matters for ECDSA, but not for a Diffie-Hellman exchange (the x coordinate, used for the secret value, will be the same regardless of the y coordinate chosen). A question: Why no pre-defined ECP groups (section 8)? Generally speaking, EC2N groups are considered faster in hardware than ECP, but ECP is much easier to program into software (and some claim faster in software than EC2N) and understand by more novice crypto programmers (even most more seasoned programmers). A request for clarification: AES (as defined in the FIPS draft) comes in three flavors -- 128 bit keys, 192 bit keys, and 256 bit keys. IKEv2 only says AES is mandatory. I would suggest that if it is meant that all 3 key sizes must be supported, then say so. And actually I would suggest only 128 bit keys be mandatory, and that 192 bit and 256 bit keys may be supported. I believe that would be consistent with http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ciph-aes-cbc-02.txt <http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ciph-aes-cbc-02.txt> . Mark Winstead Senior Mathematician NetOctave, Inc. P.O. Box 14824 RTP, NC 27709 919.463.9903 x328 mark.winstead@netoctave.com <mailto:mark.winstead@netoctave.com>
- IKEv2, AES, and Diffie-Hellman groups - a few rem… Mark Winstead