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.

I probably did not understand "MUST implement KE payloads" you said.
I am fine if the receiver can reject KE payloads by its policy, and
SHOULD send an error to the sender.

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

I don't understand what you mean.  what is the initial DH exchange ?
there are 2 phases in IKEv1.  DH exchange can be used in each phases. 
there is no description of the group number of phase 2's DH exchange.
that is the problem i said.
in IKEv2, both IKE_SA_INIT and CREATE_CHILD_SA can be used DH exchange.
the group number to be used in each exchange can be specified in each
SA payload.  so if we choice IKEv2 manner, there is no problem what i said.

what do you mean "the KE payload is mandatory." ?  KE payload in phase 2
of IKEv1, or in CREATE_CHILD_SA of IKEv2 is optional.

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

I agree with you, however there is no suitable error type in both RFC2408
and the IKEv2 specification.  INVALID_KE_PAYLOAD would be better, but the
meaning is slightly different from this context.  do you have any idea ?

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

could you explain me with another word ?  i could not understand what
you said.  probably language issue. i am sorry.

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

could you specify the place in the draft ?  i didnt find it.