[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: LAST CALL: IKE
We have mandated no management interface for any other feature so it would
seem extremely inconsistent to me to do this here.
Stephen Kent wrote:
At 8:11 PM +0300 6/24/03, Tero Kivinen wrote:
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 agree with your observation that it would be unsafe to accept such a
group simply as a result of negotiation. What I want is the ability
for a community to accept a given group, a priori, and be able to tell
one another that the group they previously agreed to use is the one to
use for a given SA.
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.
The problem my clients have encountered is that vendors generally
provide NO management interface to enter the parameters for private
groups. Thus the existence of this facility has, in effect, been
useless. However, if we mandated in IKEv2 that a management interface
MUST be present to configure private groups, which can then be
referenced as you note above, I think that would suffice.