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

Re: problems with draft-jenkins-ipsec-rekeying-06.txt

  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.