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

From: Shoichi Sakane <[email-masked]>
Date: Fri, 04 Feb 2005 21:35:47 +0900

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

---

From: Michael Thomas <[email-masked]>
Date: Fri, 04 Feb 2005 06:45:33 -0800

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. 

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.

		Mike

---

From: "KAMADA Ken'ichi" <[email-masked]>
Date: Wed, 09 Feb 2005 14:01:39 +0900

At Fri, 04 Feb 2005 06:45:33 -0800,
> 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.

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

-- 
KAMADA Ken'ichi <[email-masked]>

---

From: Shoichi Sakane <[email-masked]>
Date: Wed, 09 Feb 2005 18:22:17 +0900

> > an error message if it doesn't want to participate. 

I disagree.  it must reduce the value of using KINK.

> > 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.  If so, there is no description in RFC2409 to use
the same group in phase 2 when the negotiation uses KE payload.
actually, it brought an interoperability problem at the test event.
so we have to describe what KINK do that.

>   but it's not possible when using KE payloads.

Thank you for the clarification.

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

---

From: Michael Thomas <[email-masked]>
Date: Wed, 09 Feb 2005 08:26:02 -0800

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

> in phase 1.  

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

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

> >   but it's not possible when using KE payloads.

I believe the appropriate behavior is specified here...

> SHOULD(or MUST) add ACKREQ bit to the response message in order to be

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

		Mike

---

From: Michael Thomas <[email-masked]>
Date: Wed, 09 Feb 2005 08:43:07 -0800

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

---

From: "KAMADA Ken'ichi" <[email-masked]>
Date: Thu, 10 Feb 2005 15:47:28 +0900

At Wed, 09 Feb 2005 08:43:07 -0800,
> or not performing the DH and not returning its KE payload).

I understand, thank you.  If "rejecting" is allowed, I'm
happy with it.
Regarding how to reject, I like the idea of the absense of KE.

> nobody says that the DH arithmetic has to be _fast_ :)

Indeed.  :-D

---

From: Shoichi Sakane <[email-masked]>
Date: Wed, 16 Feb 2005 09:57:14 +0900

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

> Diffie Hellman exchange, so the KE payload is 

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.

> 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

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

> I believe the appropriate behavior is specified here...

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

---

From: Shoichi Sakane <[email-masked]>
Date: Wed, 16 Feb 2005 10:51:16 +0900

---

From: Shoichi Sakane <[email-masked]>
Date: Tue, 22 Feb 2005 12:33:28 +0900

---

From: Shoichi Sakane <[email-masked]>
Date: Tue, 22 Feb 2005 12:53:29 +0900

# sorry, i sent a garbage by my misoperation.

> SHOULD send an error to the sender.

no objection here ?  I propose the text below discussion.

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

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

---

From: "KAMADA Ken'ichi" <[email-masked]>
Date: Tue, 22 Feb 2005 13:39:19 +0900

At Tue, 22 Feb 2005 12:53:29 +0900,
>    a response witout a KE payload.  the sender MAY reject it by its policy

The sender (I assume you meant the initiator) can't reject it
because the ACK message can't carry it.

>    ID MUST be 1, and the SPI Size MUST be zero.

What is the difference between NO_PROPOSAL_CHOSEN and
INVALID_KE_PAYLOAD?  "Not supported" and "Rejected by policy"?

---

From: Shoichi Sakane <[email-masked]>
Date: Tue, 22 Feb 2005 14:30:38 +0900

> >    a response witout a KE payload.  the sender MAY reject it by its policy

I meant the sender was the initiator.

> because the ACK message can't carry it.

the one does not need to proceed the ACK handling.  as referencing to
the section 7.2, when the initiator reject it, then the initiator
SHOULD re-send a CREATE message without KE payload.

> INVALID_KE_PAYLOAD?  "Not supported" and "Rejected by policy"?

yes, correct.

---

From: "KAMADA Ken'ichi" <[email-masked]>
Date: Tue, 22 Feb 2005 15:12:12 +0900

At Tue, 22 Feb 2005 14:30:38 +0900,
> SHOULD re-send a CREATE message without KE payload.

How the responder distinguish it from a brand new CREATE?
Without distinction, the responder can't know whether the
first CREATE succeeded or not.

---

From: Shoichi Sakane <[email-masked]>
Date: Tue, 22 Feb 2005 15:29:34 +0900

> first CREATE succeeded or not.

can the Transaction ID be used for this purpose ?
otherwise, the section 7.2 description won't work, will it ?

---

From: "KAMADA Ken'ichi" <[email-masked]>
Date: Fri, 25 Feb 2005 09:58:59 +0900

At Tue, 22 Feb 2005 15:29:34 +0900,
> otherwise, the section 7.2 description won't work, will it ?

I don't like sending multiple (different in parameters) commands
in a transaction.
- It makes things complex when packets are dropped, retransmitted,
  reordered, etc.
- The current spec says "A transaction is defined as a command,
  a reply, and an optional acknowledgment."

I interpreted the word "reinitiate" in section 7.2 that
we can take another transaction(s).

---

From: Shoichi Sakane <[email-masked]>
Date: Mon, 28 Feb 2005 08:28:37 +0900

> we can take another transaction(s).

Okey, It is bad thing to reinitiate with identical transaction identifier.
It would be better to improve the text about the reinitiation and
the usage of the transaction ID.

I think that this issue is not only related to the KE payload handling,
but also the case when the responder does not choice the optimistic
proposal from the intiator.

for keeping the consistency of the protocol design, we have three choices.

1. the KE handling is an implicit proposal.
   When the initiator send a KE payload, but the responder will not reply
   with a KE payload, that means the responder does not want to choice the
   KE handling, or does not support it.  The initiator must proceed the
   session as if the KE handling was not present at all.

2. the KE handling is an explicit proposal.
   When the initiator gives choices of the KE handling to the responder,
   then the initiator must send two proposals.

3. the KE payload handling can not be negotiated.
   When the responder does not like the KE handling, the responder just
   reply an error.  The initiator must proceed the next step properly.

#3 is easy, isn't it ?