[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


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.