Re: ike2 ambiguities?

[Radia Perlman - Boston Center for Networking <Radia.Perlman@xxxxxxx>]

> "jpickering%creeksidenet.com" <jpickering@xxxxxxxxxxxxxxxx> wrote:
	The scenario I was thinking of was if a MitM intercepted msg3, he could 
	replay with the msgId changed  to a new valid
	value without affecting the validity of the message since the header is 
	not encrypted.
***********
Ah. It's true the header isn't *encrypted*, but it is integrity protected.
So replay of message 3 should not be a threat. The spec could be
more clear. For instance, in the descriptive intro it says:
>> all fields in all
>> the messages are authenticated.
which certainly could lead someone to believe it's the inside of
the messages and doesn't include the header.

However, later in the spec (final paragraph of 5.14) it says:
>>Integrity Checksum Data is the cryptographic checksum of
>>the entire message starting with the Fixed IKE Header
>>through the Pad Length. The checksum MUST be computed over
>>the encrypted message.

Admittedly I had to do some searching to find that text. Since I
was involved in the design, I knew the intent was that every
bit transmitted, including the header, would be integrity
protected, so knew it had
to be there somewhere, and still it was not easy to find.
So we'll make that clearer.


Radia