Re: ike2 ambiguities?

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

"jpickering%creeksidenet.com" <jpickering@xxxxxxxxxxxxxxxx> wrote:
>
>While trying to understand IKE2 behavior in the face of man in the 
>middle attacks, I
>noticed some ambiguities in the spec that could/should be clarified:
>
>* In section 4.2 the following statements are made:
>
>Each endpoint in the IKE Security
>Association maintains two "current" Message IDs: the next one to be
>used for a request it initiates and the next one it expects to see
>from the other end. These counters increment as requests are
>generated and received.
>and
>Note that Message IDs are cryptographically protected and provide
>protection against message replays.
>
>I am presuming that, for cryptographically protected messages, if the 
>message is
>not authenticated, the message is rejected and message ID counters are 
>not incremented.
>If this assumption is correct, the requirement should be explicitly 
>stated somewhere.

Your presumption is correct. If a message is received that does
not verify as authentic, it is discarded, and does not affect
the message ID.

>
>* In section 4.3 the following requirement is imposed on message initiators:
>
>An IKE endpoint MUST NOT exceed the peer's stated window size (see
>section 5.3.2) for transmitted IKE requests. In other words, if Bob
>stated his window size is N, then when Alice needs to make a request
>X, she MUST wait until she has received responses to all requests up
>through request X-N. An IKE endpoint MUST keep a copy of (or be able
>to regenerate exactly) each request it has sent until it receives the
>corresponding response. An IKE endpoint MUST keep a copy of (or be
>able to regenerate with semantic equivalence) the number of previous
>responses equal to its contracted window size in case its response
>was lost and the Initiator requests its retransmission by
>retransmitting the request.
>
>However, the required action by a responder if a message is outside the 
>window
>is not stated in the spec. One would think that an efficient method of 
>rejecting
>replays would be to reject messages received outside the window. If this 
>is the
>desired action, it should probably be stated.
>

You are correct. If a message is outside the window (too
small or too large) it is rejected by the receiver. Perhaps that
could be clearer in the spec, which states that the sender isn't
allowed to send something outside the window, but doesn't explicitly
say the receiver must reject it.

>* While it would seem intuitive that an endpoint would reject all but 
>child-SA messages
>after IKE-SA establishment, this is not stated in the spec. Failure to 
>reject would allow
>a MitM to mount a DOS attack by replaying IKE_SA_AUTH messages with
>an updated message ID (unless all nonces were tracked which imho is 
>adding undesirable
>state upon msg1 receipt). It would be nice to add to the draft some text 
>about
>rejecting messages like this and other things that don't make sense in
>the current context.

I'm not sure I quite understand this one, but I think it isn't a problem
because an attacker that replayed messages would not be able to increment
the message IDs, so they would be rejected without undo computation.

Radia