Re: LAST CALL: IKE

[jeff pickering <jpickering@creeksidenet.com>]

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
>>>  >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
>
>