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