Re: problems with draft-jenkins-ipsec-rekeying-06.txt
Dan Harkins <dharkins@cips.nokia.com> Fri, 14 July 2000 14:03 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 HAA21406; Fri, 14 Jul 2000 07:03:41 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA04611 Fri, 14 Jul 2000 08:50:33 -0400 (EDT)
Message-Id: <200007140600.XAA26578@potassium.network-alchemy.com>
To: 'IPsec List' <ipsec@lists.tislabs.com>
Subject: Re: problems with draft-jenkins-ipsec-rekeying-06.txt
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <26575.963554441.1@network-alchemy.com>
Date: Thu, 13 Jul 2000 23:00:41 -0700
From: Dan Harkins <dharkins@cips.nokia.com>
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
I do not believe that a "Responder Pre-Set-up Security Hole" exists in IKE as is defined in RFC2409 and suggest that the text referring to such be deleted from rekeying draft prior to advancement to Informational RFC status. The draft says: "2.2.1.4 Responder Pre-Set-up Security Hole In the failed negotiation case, the need to delete the invalid inbound SA raises the issue of a temporary hole, in that the responder allows inbound packets while waiting for the third quick mode message. However, if the inbound SA is not set up ahead of time, initiators that immediately transmit on the new outbound SA will cause packets to be dropped. It also illustrates why the proposal above made the usage of the outbound SA by the initiator wait until there is an indication of the use of the SA by the responder. Note that this security hole is exactly what would result from an attacker replaying the first quick mode message of an exchange." There would be no security hole from an attacker replaying a Quick Mode message because upon receipt of this replayed packet the Responder would choose a random nonce and, if it chose to "pre set up" its SAs, derive keying material for the IPSec SAs which are based, in part, on that nonce. In addition the SPI the Responder would choose is part of his responce which, again, the attacker would be unable to read and therefore would not know which SPI upon which to send his packets! Basically, even if the attacker could guess which random SPI the Responder chose as a result of this replayed packet he would still not be able to construct a packet which the Responder would verify and decrypt. Only the authenticated peer has the SKEYID state necessary to construct the right KEYMAT. The only issue is that there is a possible attack if this replayed packet contained PFS (which the attacker would not know) because the Responder is doing "pre-set-up" and would most likely finish exponentiation. But this seems to be a manufactured problem. Don't do "pre-set-up"! Use the commit bit if you don't want to receive IPSec packets from the Initiator prior to receipt of the message #3. Dan.
- problems with draft-jenkins-ipsec-rekeying-06.txt D. Hugh Redelmeier
- RE: problems with draft-jenkins-ipsec-rekeying-06… Tim Jenkins
- procedural RE: problems with draft-jenkins-ipsec-… Henry Spencer
- RE: problems with draft-jenkins-ipsec-rekeying-06… D. Hugh Redelmeier
- Re: procedural RE: problems with draft-jenkins-ip… Paul Koning
- RE: problems with draft-jenkins-ipsec-rekeying-06… Andrew Krywaniuk
- RE: problems with draft-jenkins-ipsec-rekeying-06… Mason, David
- Re: problems with draft-jenkins-ipsec-rekeying-06… Dan Harkins
- Re: problems with draft-jenkins-ipsec-rekeying-06… Dan Harkins
- RE: problems with draft-jenkins-ipsec-rekeying-06… D. Hugh Redelmeier
- RE: problems with draft-jenkins-ipsec-rekeying-06… Andrew Krywaniuk
- RE: problems with draft-jenkins-ipsec-rekeying-06… Henry Spencer
- Re: problems with draft-jenkins-ipsec-rekeying-06… Dan Harkins
- RE: problems with draft-jenkins-ipsec-rekeying-06… andrew.krywaniuk
- RE: problems with draft-jenkins-ipsec-rekeying-06… Henry Spencer
- RE: problems with draft-jenkins-ipsec-rekeying-06… Paul Koning
- RE: problems with draft-jenkins-ipsec-rekeying-06… Andrew Krywaniuk
- RE: problems with draft-jenkins-ipsec-rekeying-06… andrew.krywaniuk
- RE: problems with draft-jenkins-ipsec-rekeying-06… Paul Koning
- RE: problems with draft-jenkins-ipsec-rekeying-06… D. Hugh Redelmeier
- RE: problems with draft-jenkins-ipsec-rekeying-06… Andrew Krywaniuk