[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: ike2: SAi1 in msg 3



Ah. This part will be going away. The original document had
the stateless cookie, (if Bob suspected he was under attack),
as an extra optional handshake (like OAKLEY did it), so the
exchange was 4 messages or else 6 if Bob rejected Alice's
first message saying "try again, this time including this cookie".
The reason we'd done it that way was it was much simpler since
once the real exchange started we could assume Bob was keeping
state, and it had other advantages (like protection from a fragmentation
attack, and not having to repeat information).

When the JFK and IKEv2 teams agreed to all get behind one document,
we changed the exchange to the always-4 way, since that was one of
the few remaining differences between JFK and IKE. But once we made
that change, some people objected (it especially
complicated the legacy authentication stuff which wasn't at
that point in the document but will be in the next
version), and at the IETF meeting Jeff Schiller made the WG
actually make a decision rather than vaccillating on stuff that
doesn't matter a lot (like suites vs a la carte, another change
that got made for the version posted). And the WG decided it
preferred 4/6 (where Bob's stateless behavior happens as a pre-handshake
pair of messages).

So the particular place in the spec that you're talking about is
going to change in the next version (which will be posted real soon now).
It will be simpler since things don't need to be repeated because
Bob is not stateless after message 2.

Radia


	From: "jpickering%creeksidenet.com" <jpickering@xxxxxxxxxxxxxxxx>
	User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; m18) 
Gecko/20001108 Netscape6/6.0
	X-Accept-Language: en
	MIME-Version: 1.0
	To: ipsec@xxxxxxxxxxxxxxxxx
	Subject: ike2: SAi1 in msg 3
	Content-Transfer-Encoding: 7bit
	
	
	In Ike2, section 3.1 for msg 3 the text reads:
	
	The initial payloads in message three are identical to the payloads in 
	message 1.
	
	While this may be true for payload types, it is clearly not required for 
	payload
	contents since the key may differ if Bob chooses a proposal that changes 
the
	DH group. This brings up the question of  the contents of SAi1 in 
message 3:
	Should this payload contain the original proposal set or the single 
	proposal chosen
	by Bob? And what should Bob do when receiving the payload?
	
	Another question regards Bob's nonce contents in message 2: if Bob 
places
	state information in message 2, eg. which suite he chose, what is the 
	advantage
	of encrypting this state if Bob's cookie effectively signs the nonce?
	
	Always grateful for helpful clarification.
	
	Jeff