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

Let me clarify my position: I think that a KINK implementation
MUST deal properly with receiving a KE payload from a sender.
I'm perfectly happy if the receiver somehow rejects the KE
payload and proceeds from there (either by sending an error,
or not performing the DH and not returning its KE payload). 

I believe this gives you what you're asking for: the ability
to not have to run the big number arithmetic... But even
if we required implementation (and I'm not recommending this),
nobody says that the DH arithmetic has to be _fast_ :)

		Mike

On Tue, 2005-02-08 at 21:01, KAMADA Ken'ichi wrote:
> 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.

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

iQCVAwUAQgo9m7MsDAj/Eq++AQK7ZgQAtpI4FwZC9ymErUe/68W9KkvC68p9WGzR
xxj088MrHYEIrardMaWyTtlBRApPI7u43gwKqWTgaPP+3q8r4RuuZfajUw2Vq7dV
TvYUu7bt5iNJ/HETrvkUi7ZVxFv42lmdsQX7sWD0tFrNqiLL3uoW72XdUBxVCtRP
3HCK0Y5yvF4=
=yAqX
-----END PGP SIGNATURE-----