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

On Wed, 2005-02-09 at 01:22, Shoichi Sakane 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 disagree.  it must reduce the value of using KINK.

I don't understand: if the receiver has a way of 
rejecting the use of PFS, where is the harm here?
The sender at worst would have to retry without the
KE payload it seems to me.

> 
> > > 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.
> 
> I am assuming that "the initial DH" means the group number used
> in phase 1.  

No, I meant that IKE always performs an initial
Diffie Hellman exchange, so the KE payload is 
mandatory.


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

Maybe it should be more specific so that a sender
can know that it's really the KE payload that's
causing problems? Another possibility that I haven't
looked at yet is for the receiver to _not_ send its
KE payload back in which case the sender would realize
that the receiver didn't perform the DH and it could
proceed as if the sender KE wasn't present at all?

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

I believe the appropriate behavior is specified here...

> > > > 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.
> 
> I noticed what the document probably does not touch.  When a responder
> accepts the KE from the initiator, it would be better that the responder
> SHOULD(or MUST) add ACKREQ bit to the response message in order to be
> less packet loss.

Hmm, I thought that that was actually in the draft. If
not, then I think that you're right...

		Mike

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

iQCVAwUAQgo5mrMsDAj/Eq++AQIj5gP/X5tbRN37hgrsp9U2qsRa6Gqiy48S3/mc
kXWOPq7WkAIjPe3CFOQ7xXntQvKKiX4CLv3c4zcTywuP7miGj4WeJxZEhiAzn2YG
B1aAgMbrTpqvXmsB72ONjJYiBRWKaLlmt/vtrxLK9Dtr08MrFzAfyfxUpOwS5PWi
mOR3U5agU8M=
=Of7O
-----END PGP SIGNATURE-----