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

RE: Simplifying IKE

On Wed, 8 Aug 2001, Brian Swander wrote:

> I'd prefer to keep the commit bit.  Otherwise the responder is forced to
> add SAs before the final QM hash from the initiator is processed,
> opening the responder up to adding potentially suspect SAs into the
> system.  
> 
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: