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
- IKE clarifications Hilarie K. Orman