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

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. 

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.

		Mike

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.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iQCVAwUAQgOKjbMsDAj/Eq++AQINVgQAqzaQkUsbWMLD1mbgA0BUOwccjaKRLVM/
BNwW23UAhpBxEm/B/7aCCQfbyNZJR4nB3nlm2sGJ9FFBxf55zulPVFN8tVFunxDQ
rnzRl5D40TbQz26wvX6a18HFP4IW+Xj8wix3E49od6iybwP95M+bQdmG5tWV6v+E
GwCRChfgJNU=
=XfeC
-----END PGP SIGNATURE-----