Re: #23 [*] KE interoperability (section 6.8)

At Fri, 04 Feb 2005 06:45:33 -0800,
Michael Thomas <[email protected]> wrote:
> 
> I haven't looked it up in the draft, but my feeling is
> that the Receiver MUST implement KE payloads, though
> I suppose that it may be administratively rejected with
> an error message if it doesn't want to participate. 

I feel that MUST is too strong.
It makes a comformant implementation impossible on small devices
without hardware MODP (or something) accelerator.


> IKEv1 doesn't define it because it always expects that
> the initial DH is performed; KINK doesn't require this
> since there's already a shared key in the ticket.

Do you mean that KINK doesn't require KE payloads?
(Sorry if this is my misunderstanding.)

Sakane-san's point (as far as I can read) is that
if KINK allows using KE payloads, the following 3 issues
should be considered.  I think only the 3rd item needs additional
text to the KINK spec.

- Which error code is returned when the responder doesn't support KE,
  if we go with IKEv1.
  (I think INVALID-PAYLOAD-TYPE is enough.)

- KINK (nor IKEv1) doesn't negotiate DH group,
  so the operators must agree the group in advance.
  (I don't know whether KINK spec needs to describe this though.)

- KINK initiators usually set inbound SAs before CREATE command,
  but it's not possible when using KE payloads.


> On Fri, 2005-02-04 at 04:35, Shoichi Sakane wrote:
> > > #23 [*] KE interoperability (section 6.8)
> > > 
> > > 	What happens if a peer that implements the KE payloads communicates
> > > 	with a peer that does not.  Specify the behavior in sufficient detail
> > > 	to guarantee interoperability.  (Sam Hartman)
> > 
> > my understanding is correct, there is no description in the IKEv1
> > specifications though it defines the error code which can be used
> > in this case.  IKEv2 defines clearly.  so if KINK specification
> > complies to IKEv1 manner, we have to define the behavior and describe
> > it for interoperability.  if KINK complies to IKEv2 manner, we can
> > probably leave it.
> > 
> > another problem comes up.  there is no way to negotiate a DH group
> > to use in a quick mode.  so in IKEv1, they have to define the DH group
> > before they negotiate.  current KINK specification does not touch it.
> > this is no matter in IKEv2.
> > 
> > and an initiator can not install the inbound SA when the initiator
> > choices to send KE because KEYMAT is not calculated before the initiator
> > receives KE from the responder.  the document has to touch this situation.

-- 
KAMADA Ken'ichi <[email protected]>