[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Responder Pre-set-up hole (was RE: problems with draft-jenkin s-ip sec-rekeying-06.txt)
There are no guarantees in anything but I would say that it is
statistically impossible. What sort of analysis of a previous SA can be
done resulting in what sort of attack? And on what SPI would the attacker
send packets if he was able to somehow divine the key?
The SA will, presumably, die a quick death due to the fact that the
true Initiator did not send the original message prompting the
creation of this SA. If the Initiator sent anything back to the
Responder upon receipt of this response to the attack it would probably
be an Informational saying that the message was garbled (he'd think it
was message #1 and be unable to authenticated it). If he sent nothing
the Responder would retransmit a few times and delete the SA. The only
harm is the exponentiation which should be noted.
And, this whole thing is an issue only because of the proposal to
actually create a usable SA upon receipt of a single message in the
first place! Don't do "responder pre-set up". If a Responder is sensitive
about receiving a few IPSec packets prior to creation of a valid,
usable SA then it should use the commit bit. That's what it's there for.
Even so, if the Responder did "pre set-up" it still isn't any sort of
Security Hole.
Dan.
On Fri, 14 Jul 2000 15:47:16 EDT you wrote
> Dan,
>
> I assume you mean "... if it that SA not be used" by the attacker.
>
> Are you going to guarantee that the SA cannot be used given that it has less
> entropy in its keying material? Is there no attack that can be launched
> based on analysis of the previous SA and knowing that some of the keying
> material input is the same?
>
> As I said before, I won't guarantee that.
>
> I won't call it a security hole. I would categorize it as a potential risk.
> How about I change the section name to "2.2.1.4 Responder Pre-Set-up Issues"
> and I'll add your comments about DoS?
>
> Would that make you happy?
>
> Tim
>
> > -----Original Message-----
> > From: Dan Harkins [mailto:dharkins@cips.nokia.com]
> > Sent: Friday, July 14, 2000 1:51 PM
> > To: Tim Jenkins
> > Cc: 'IPsec List'
> > Subject: Re: Responder Pre-set-up hole (was RE: problems with
> > draft-jenkin s-ip sec-rekeying-06.txt)
> >
> >
> > But what's the point if that SA can not be used? If there is some
> > issue aside from the potential for a DoS attack then what is it? If
> > it's just a potential DoS attack then just say so. If it's just a DoS
> > attack it seems appropriate to mention that the attack is bounded by
> > the number of Quick Modes already performed on each active
> > SA. Replaying
> > old Quick Modes for SAs which have expired will do nothing.
> >
> > "Unsafe at any speed" killed a very fine, and quite safe,
> > car; "Security
> > Hole" seems hyperbolic.
> >
> > Dan.
> >
> > On Fri, 14 Jul 2000 13:42:53 EDT you wrote
> > > 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.
> > > > > >
> > > >
> >
References: