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

# sorry, i sent a garbage by my misoperation.

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

no objection here ?  I propose the text below discussion.

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

There was my fault.  I have told a strange thing here.  the fact is
that there is no chance to negotiate the DH group in phase 2 of IKEv1.
so the negotiators have to make an agreement of the group in use
before the negotiation begins, otherwise the negotiation will fail.

in ether case, the document has to describe it like the IKEv2 document.

   section 1.3:
   If the SA offers include
   different Diffie-Hellman groups, KEi MUST be an element of the group
   the initiator expects the responder to accept. If it guesses wrong,
   the CREATE_CHILD_SA exchange will fail and it will have to retry with
   a different KEi.

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

I have understood what you mean.  so the responder has three choices
when it receives a KE payload.  that is:

	- return a notify payload with INVALID_KE_PAYLOAD.
	- return a notify payload with NO_PROPOSAL_CHOSEN.
	- reply without KE payload.

so I would like to propose the following process.  any idea ?

   All node conformed to the document MAY implement the KE payload
   handling.  If a node receives a KE payload, and the receiver does not
   support the KE handling, and does not want to proceed the negotiation,
   then the receiver SHOULD send a Notify payload of the type
   NO_PROPOSAL_CHOSEN to the sender.  If the receiver wants to keep the
   negotiation without the KE payload handling, then the receiver sends
   a response witout a KE payload.  the sender MAY reject it by its policy
   in this case.
   If the receiver does not want to process the KE payload by its policy,
   the receiver SHOULD send a Notify payload of tye type INVALID_KE_PAYLOAD
   to the sender.
   Notification Data MUST contain the KE payload in both case.  the Protocol
   ID MUST be 1, and the SPI Size MUST be zero.

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