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

Re: Responder Pre-set-up hole (was RE: problems with draft-jenkins-ip sec-rekeying-06.txt)

  Tim,

  But that SA will not and cannot be used in the case of a replay attack.

  I'm not sure about whether you're being over-cautious or not but saying
that there is a Security Hole seems being not only over critical but wrong.
If the issue is a DoS attack in which the Responder can be induced into
doing exponentiations as a result of replayed packets then that should be
explicitly stated. 

  I received 2 private emails over the last couple of days saying that the
Security Hole was that the Responder would accept traffic (also replayed)
on that SA. Statistics 101 tells me that there are probably even more
people who received that impression by reading the draft. 

  Dan.

On Fri, 14 Jul 2000 12:48:19 EDT you wrote
> Dan,
> 
> The hole I was referring to was the existence for a brief period of time an
> inbound SA that was created with less randomness then the one set up with by
> the original quick mode exchange since it would use the same value for Ni_b
> and protocol in the KEYMAT generation.
> 
> I was not willing to state that this was as secure and was not somehow
> exploitable, so I took the cautious route and decided that it was not
> acceptable to do this.
> 
> Is this being over-cautious?
> 
> Tim
> 
> > -----Original Message-----
> > From: Dan Harkins [mailto:dharkins@cips.nokia.com]
> > Sent: Friday, July 14, 2000 2:01 AM
> > To: 'IPsec List'
> > Subject: 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.
> >
References: