[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
IKEv2, AES, and Diffie-Hellman groups - a few remarks, a question and a clarification request
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
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 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.
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.
Mark Winstead
Senior
Mathematician
NetOctave, Inc.
P.O. Box 14824
RTP, NC 27709
919.463.9903 x328
mark.winstead@netoctave.com