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