Re: LAST CALL: IKE

[Stephen Kent <kent@bbn.com>]

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
>>  >negotiate.
>>
>>  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.
>
>	or
>
>	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.

Steve