IKE clarifications

"Hilarie K. Orman" <ho@earth.hpc.org> Wed, 09 September 1998 23:56 UTC

Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA20845 for ipsec-outgoing; Wed, 9 Sep 1998 19:56:33 -0400 (EDT)
Date: Wed, 09 Sep 1998 20:16:48 -0700
From: "Hilarie K. Orman" <ho@earth.hpc.org>
Message-Id: <199809100316.UAA19107@earth.hpc.org>
To: dharkins@cisco.com
Cc: isakmp-oakley@cisco.com, ipsec@tis.com
In-reply-to: Yourmessage <199809081815.LAA05462@dharkins-ss20.cisco.com>
Subject: IKE clarifications
Sender: owner-ipsec@ex.tis.com
Precedence: bulk

Catherine Meadows at NRL has noted two points that need to be clarified
in order to ensure that secure implementations of IKE are produced.

The first is that message ID's must be pseudo-randomly generated; this
necessity is mentioned in the ISAKMP document, but could be easily
overlooked by an IKE implementor (and has been, more than once, it
seems).

The second point is to note that the decision about whether a message
is a Quick Mode initial message or a reply to a QM init msg must be
made on the basis of a pre-existing message ID only, not by using
any other attribute of the message.

Implementations that omit either of these recommendations are subject
to a denial-of-service attack which results in the production of
security associations that are not usable for communication with
the intended remote party.

Hilarie