[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: simplifying rekeying [draft-jenkins-ipsec-rekeying-06.txt]



| 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



References: