[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)
Okay, I'll be more explicit. You alluded to it already, but it seems to me
that this new SA has less entropy in the key material generation, and
therefore might have some greater susceptibility in being cracked.
If I explicitly state that the new SA in this particular case has less
entropy because it re-uses the initiator nonce from the original quick mode
message one that is replayed, and therefore might possibly be weakened,
would that satisfy you rather than having the statement removed?
> -----Original Message-----
> From: Dan Harkins [mailto:dharkins@cips.nokia.com]
> Sent: Friday, July 14, 2000 1:34 PM
> To: Tim Jenkins
> Cc: 'IPsec List'
> Subject: 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.
> > >
>
Follow-Ups: