clean #37 and #5 and introduce #45

At Thu, 10 Feb 2005 17:41:10 +0900,
"KAMADA Ken'ichi" <[email protected]> wrote:
> 
> #37 [**] Difference between IKE and KINK on CREATE command (section 4.3)
> 
> 	IN addition, any differences
> 	between how this works and how IKE would set up the same SA need to be
> 	called out.  It is fine for there to be differences, but I want to
> 	make sure the working group explicitly decided the differences are a
> 	good thing.
> 
> 	I'm somewhat concerned that 4.3 is not specific enough to describe
> 	exactly what key gets set up.  I.E. I'm concerned it may not be
> 	detailed enough for interoperable implementations.
> 	(Sam Hartman)
> 
> 	- What keys are used for the resulting SA on the each side?
> 	  (Sam Hartman, Message-ID: <[email protected]>)
> 
> 		Answer: Message-ID: <20050204170451BM%[email protected]>
> 
> 	- Doesn't the timing when to add in/out SAs conflict with IKE?
> 	  (Sam Hartman, Message-ID: <[email protected]>)
> 
> 		Related thread: Message-ID: <20050204170454BO%[email protected]>
> 
> 	- How about when to add SAs and which SAs to add when 3-way.
> 	  (Message-ID: <20050204170454BO%[email protected]>)
> 
> 
> #5 [*] When 3-way, is responder's nonce MUST or SHOULD? (section 4.3 and 7.3)
> (solution proposed)
> 
> 	Sec 4.3 and 7.3 use SHOULD and MUST respectively regarding when the 
> 	nonce should be used.  If the circumstances they're describing are 
> 	different, that's okay, but if so, I missed it on first reading.
> 	(Ken Raeburn)
> 
> 	They are talking the same situation and the requirement levels should
> 	be aligned.  I think SHOULD is appropriate because non-returning
> 	responder's nonce does not break interoperabilities.
> 	(Message-ID: <20050127171441FF%[email protected]>)
> 
> 	If the initiator receives a responder's nonce, she MUST use
> 	it in the KEYMAT calculation.
> 
> 	I think it is also editorial issue.  anyway, the behavior depends on
> 	condition.  if a responder does not agree with the initiator's proposal,
> 	AND if the responder wants to continue the transaction, then the responder
> 	MUST send back a message with ACK request bit, and MAY contain a nonce.
> 	There is a case when the responder wants to use same KEYMAT of the
> 	initiator, but just doesn't want to use the initiator's proposal.
> 	It is not always required to add a nonce.
> 	(Message-Id: <[email protected]>)

#37 and #5 seems to have some overlapping discussion.
Can I clean them up as follows?

#37
	Following two issues are answered and seems to have no problem.
	- What keys are used for the resulting SA on the each side?
	- Doesn't the timing when to add in/out SAs conflict with IKE?

	This one seems overlap with #5, so seperate from #37 and moved
	into #45 (described below).
	- How about when to add SAs and which SAs to add when 3-way.

	We have no issue left in #37, so we can close it.


#5
	The original issue that the responder's nonce is MUST or SHOULD,
	is answered.  It should be SHOULD.

	Sakane-san's issue is seperated from #5 and moved into #45

	We can just fix #5 editorially.


and introduce #45.
#45 [*] When to add SAs and which SAs to add in 3-way handshake

	derived from #5 and #37, and related to #23.

	When does the responder require ACK?
	- disagreeing on the proposal
	- doing KE (dispite accepting or rejecting?)
	- agreeing with the parameters but want to add NONCE
	  (Is this allowed in KINK?)

	When to add (and remove if necessary) SAs?
	- usual optimistic approach
		This is already described in the current draft.
	- (non-KE) 3-way
	- KE 3-way

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