[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: LAST CALL: IKE
Stephen Kent writes:
> >As a separate matter, I had requested a few months ago that we allow
> >IKE peers to negotiate use of groups other than the set defined in
> >Oakley. I see that there is a provision to negotiate other choices
> >for P, but not for G. I apologize for not noticing this sooner. I
> >would like to see the negotiation made more general, so that both
> >the generator as well as the exponent are values that peers can
> This is a request to make the IKE parameter space negotiation more
> flexible. there would be no requirement that a conforming
> implementation support other groups than the ones defined in the
> separate IKE algorithms spec. But it would allow user communities to
> specify other groups for their own use. I thought we agreed on this a
> while ago, but I didn't check closely enough to realize that the
> current IKE version allows only the exponent, not the generator, to
> be specified. My intent had been to allow both to be specified.
This is one of the features of the IKEv1 that I would really like to
be removed from IKEv2. The problem with private diffie-hellman groups
is that you do now know how the group was generated, and is it safe.
If you try to do online checks for the groups it takes time and adds
more code to the ipsec, causing more bugs.
I do know this, as I did implement that feature in the IKEv1.
We do have 16-bit number for groups. We do have private use space for
groups to be used. I suggest we remove the options to negotiate any
group parameters inside the IKE, and say that if you want to use other
groups, you either
1) write a document describing the groups, and allocate
proper number for them from IANA.
2) Define the group parameters in both ends and take number
from private use space and use that ine IKE.
In that case the adminstrator can do all verifications it wants when
allowing the group to be used.
If someone really wants to have new groups to be automatically
generated every day and use them in the IKE, they can defined their
own protocol how to move those group descriptions from one IKE peer to
the other, before starting the use them in IKE (i.e http-post of
signed group description config file :-)
Ups, the transform ID field is now only 8-bits, thus we can only have
255 different groups, but there is 16-bits of RESERVED before that,
thus we could very easily extend it to the 24-bit number, thus having
definately enough different groups...
So, my suggestion is to:
1) modify the Transform ID field to be 16-bits.
2) Remove Transform type 4 (Diffie-Hellman Group) Transform
ID numbers 201-203, and the text describing anything about
3) Fix the text in the 3.3.5 saying that only thing that use
attributes are when we define our own Diffie-Hellman
groups, to say that only thing that actually uses the
attributes are the ciphers having different key lengths
4) Remove all "Group *" attribute types, and also the Field
Size attribute type.
5) Remove text in the 3.3.6 Attribute Negotiation about the
defining the groups on the fly.
6) Extend the DH Group # in the Key exchange payload to be 16
or 24 bites as the Transform ID also is made bigger.
SSH Communications Security http://www.ssh.fi/
SSH IPSEC Toolkit http://www.ssh.fi/ipsec/