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

Re: Simplifying IKE

  Why is one mandated processing of packets a solution and another a
"work around"? If the "work around" solves the problem in one less
message then why isn't that preferable? Wouldn't adding a timestamp to
the exchange be a "kludge"? Or a "work around"? 

  The only reason the Responder doesn't instantiate the SAs after sending
the 2nd message today is because of concerns about a resource consumption
attack. I feel those concerns are small due to the small time in which
the bogus SAs would be in the SADB, the inability of an attacker to use
them (due to the inability of a 3rd party to know SKEYID state), and the
small (and quantifiable) number of messages that can possibly be exchanged.
Instantiate them and delete them if the 3rd message is never received!

  So we have very few messages which can be replayed and a well-defined
method of dealing with the cases in which they are replayed. Why is that
not satisfactory? What is the problem with this that is solved by adding
a 4th message?

  Dan.

On Wed, 08 Aug 2001 13:57:15 PDT you wrote
> I'd actually prefer to formalize the concept that the commit-bit is trying to
> address:
> 
> 1) Either expand quick mode to 4 messages. That's unambiguous, and leads to
> better interop. A commit bit is really a kludge.
>
> 2) If you think about it, the 3rd message is only needed to prevent replay
> attacks of old messages. If we addressed this some other way (say a timestamp
> field, but that has obvious other problems), then we could drop the 3rd
> message, and have 2, which is again 'good (tm)'.
>
> Dan also outlined some other ways to address this problem, and while they
> work, I don't much care for them, since they're really work-arounds to the
> problem above. It would be preferable to address the replay attacks in some
> other way (if possible) and do away with the 3rd message, or bite the bullet
> and create a 4th message as an ACK to make the exchange as unambiguous as
> possible.
> 
> I point out that KINK manages to use 2 messages, which are (used to be)
> essentially a quick mode exchange. It uses kerberos to handle the replay
> attacks, which involves timestamps. There are surely other ways of addressing
> the replay issue, like a counter or something else. If we could use two
> messages for quick mode, that would solve all this commit-bit versus 'when to
> install the resources' issues....
> 
> jan
> 
> 
> 
> > I am not so concerned with the resources in an attack, but more worried
> > about an attacker potentially getting an SA into the system that could
> > be exploited.  I don't see how this could be done today (all I can see
> > is the obvious replay attack Dan is talking about), but that doesn't
> > mean that such an exploit doesn't exist.  So, I am much more comfortable
> > with the one extra packet and the assurance that everything is ok with
> > the negotiation before SAs are added.  
> > 
> > Of course, if someone has a proof that the security can't be violated by
> > adding the responder SAs early, then I'd agree to eliminating the commit
> > bit (except for backwards compatibility, when we'd still need to support
> > it).
> > 
> > bs
> > 
> > -----Original Message-----
> > From: Dan Harkins [mailto:dharkins@lounge.org] 
> > Sent: Wednesday, August 08, 2001 10:49 AM
> > To: Ari Huttunen
> > Cc: ipsec@lists.tislabs.com
> > Subject: Re: Simplifying IKE 
> > 
> >   My tentative text on the subject is to get rid of the commit bit and
> > have a 3 message exchange. The problem with the existing 3 message
> > exchanage (w/o the commit bit being used) is that the Responder will not
> > instantiate her SAs until receipt of the 3rd message from the Initiator
> > to avoid a resource consumption attack but the Initiator will
> > instantiate
> > his SAs upon receipt of the 2nd message from the Responder. This results
> > in a race between the first few IPsec-protected packets and the final
> > message. If the former win they get dropped.
> > 
> >   My proposal is that the Responder instantiate the SAs when she sends
> > the 2nd message back to the Initiator. She will be setting a timer to
> > deal with non-receipt of the 3rd message and if the timer fires 
> > RETRANSMIT_TIMER_LIMIT times the exchange is declared to have failed
> > and she can delete these SAs from her SADB. 
> > 
> >   In addition to this text there is new text instructing implementations
> > to deal with receipt of an offer to create an IPsec SA with a SPI that
> > is currently in use as an error, and new text instructing the Initiator
> > to hold on to the 3rd phase 2 message for some COMFORT_LEVEL_TIME in
> > case
> > it is dropped and he receives a retransmitted 2nd message from the
> > Responder.
> > 
> >   This is much simpler than what we have and solves the race problem.
> > What it does, though, is allow for some resources to be temporarily 
> > consumed due to the replay of an old message. I don't view this as that
> > big of a problem though since it is temporary (RETRANSMIT_TIME * 
> > RETRANSMIT_TIMER_LIMIT = total seconds these bogus SAs would stay in
> > the SADB) and the number of possible packets that can be replayed is 
> > limited and bounded by the life of the IKE SA. 
> > 
> >   Thoughts?
> > 
> >   Dan.
> > 
> > On Wed, 08 Aug 2001 12:19:02 +0300 you wrote
> > > 
> > > Dan McDonald wrote:
> > > > 
> > > > > >From the Schneier and Ferguson analysis we get:
> > > > >
> > > > >     Can we drop the commit bit?
> > > > 
> > > > Who uses it?
> > > 
> > > I guess someone in past figured out that running IKE on satellite
> > lines
> > > is necessary, so they decided to optimize as much as possible. The
> > result
> > > was that both aggressive mode and quick mode both have three messages.
> > > The problem with three messages is that the initiator will often start
> > sendin
> > >g
> > > actual traffic too soon, or quick mode packets, before the responder
> > is ready
> > >. Thus 
> > > the need for packet buffers, commit bit, whatever. This optimization
> > causes d
> > >esign 
> > > complications that I'd very much prefer to get rid of.
> > 
> 
>  --
> Jan Vilhuber                                            vilhuber@cisco.com
> Cisco Systems, San Jose                                     (408) 527-0847
>
Follow-Ups: References: