Re: simplifying rekeying [draft-jenkins-ipsec-rekeying-06.txt]
"D. Hugh Redelmeier" <hugh@mimosa.com> Tue, 18 July 2000 00:57 UTC
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA28489; Mon, 17 Jul 2000 17:57:25 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA16630 Mon, 17 Jul 2000 19:32:42 -0400 (EDT)
X-Authentication-Warning: redshift.mimosa.com: hugh owned process doing -bs
Date: Mon, 17 Jul 2000 19:43:19 -0400
From: "D. Hugh Redelmeier" <hugh@mimosa.com>
Reply-To: hugh@mimosa.com
To: Dan Harkins <dharkins@cips.nokia.com>
cc: "David W. Faucher" <dfaucher@lucent.com>, Paul Koning <pkoning@xedia.com>, henry@spsystems.net, ipsec@lists.tislabs.com, hugh@toad.com, gnu@toad.com
Subject: Re: simplifying rekeying [draft-jenkins-ipsec-rekeying-06.txt]
In-Reply-To: <200007171934.MAA26154@potassium.network-alchemy.com>
Message-ID: <Pine.LNX.4.21.0007171939450.23915-100000@redshift.mimosa.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
| From: Dan Harkins <dharkins@cips.nokia.com> | To: David W. Faucher <dfaucher@lucent.com> | An implementation may be open to a DoS attack if it does not keep | track of the MIDs of Quick Modes in which PFS was used for all active | IKE SAs. This attack is not effective if PFS is not used. It seems to me that if "unique" is read in some weaker sense ("probably unique" or "unique amongst live exchanges"), then a Responder probably isn't justified in rejecting a packet just because the Message ID is a duplicate of one from the past. Of course, an implementation can do what it wishes, but the rejecting Responder would not be conforming to (this reading of) the RFCs. I would very much like to be wrong about this. If I am wrong, then whether an implementation decides to enforce uniqueness is a purely local decision. Since it has (rare) interoperability consequences, I think that this ought to be a standardized feature. If it isn't, we have the worst of both worlds: implementations should not generate duplicate Message IDs for fear that their peers would reject them, but should not reject duplicate Message IDs because their peers might generate them. | There is no "security hole" associated with small amounts of entropy I imagine that this is correct. Have we a convincing argument? My intuition is that each side should put in the entropy it requires. Thus there is enough entropy in the keying material for its purposes. Besides, no sample encrypted packets are provided, so there isn't much to crack. But I made this up out of whole cloth. | nor is there any generic replay attack which can induce an implementation | into processing old IPSec packets. But IKE packets are another story. Any Phase 2 exchange with fewer than 3 messages must be vulnerable to replay unless Message ID uniqueness is enforced. Any other exchange with fewer than 3 messages must be vulnerable (Message IDs can't save this case). Some such exchanges probably have no important effect when replayed. Deleting an already deleted SA isn't dangerous. Even so, care ought to be taken to avoid an opening for DoS -- logging or excess notification or excess computation in response to a replayed packet. Even for exchanges with 3 or more messages, enforcing uniqueness will defeat a replay attack earlier, perhaps avoiding DoS consequences. Why was the Acknowledged Notification Exchange designed with only 2 messages? This seems like a mistake if uniqueness isn't to be enforced. | On Mon, 17 Jul 2000 13:34:01 CDT you [David W. Faucher <dfaucher@lucent.com>] wrote | > Regardless of how "unique" is interpreted, it does appear that | > an implementation may be open to replay attacks if it does | > not keep track of the MIDs that have been used on a given | > ISKAMP SA. Hugh Redelmeier hugh@mimosa.com voice: +1 416 482-8253
- simplifying rekeying [draft-jenkins-ipsec-rekeyin… D. Hugh Redelmeier
- Re: simplifying rekeying [draft-jenkins-ipsec-rek… Jan Vilhuber
- Re: simplifying rekeying [draft-jenkins-ipsec-rek… D. Hugh Redelmeier
- Re: simplifying rekeying [draft-jenkins-ipsec-rek… Dan Harkins
- Re: simplifying rekeying [draft-jenkins-ipsec-rek… Jan Vilhuber
- RE: simplifying rekeying [draft-jenkins-ipsec-rek… Andrew Krywaniuk
- Re: simplifying rekeying [draft-jenkins-ipsec-rek… Henry Spencer
- Re: simplifying rekeying [draft-jenkins-ipsec-rek… Dan Harkins
- Re: simplifying rekeying [draft-jenkins-ipsec-rek… D. Hugh Redelmeier
- Re: simplifying rekeying [draft-jenkins-ipsec-rek… Bill Sommerfeld
- Re: simplifying rekeying [draft-jenkins-ipsec-rek… Dan Harkins
- Re: simplifying rekeying [draft-jenkins-ipsec-rek… Valery Smyslov
- Re: simplifying rekeying [draft-jenkins-ipsec-rek… Bill Sommerfeld
- Re: simplifying rekeying [draft-jenkins-ipsec-rek… Paul Koning
- RE: simplifying rekeying [draft-jenkins-ipsec-rek… D. Hugh Redelmeier
- Re: simplifying rekeying [draft-jenkins-ipsec-rek… Valery Smyslov
- Re: simplifying rekeying [draft-jenkins-ipsec-rek… David W. Faucher
- Re: simplifying rekeying [draft-jenkins-ipsec-rek… Dan Harkins
- Re: simplifying rekeying [draft-jenkins-ipsec-rek… D. Hugh Redelmeier