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

RE: Simplifying IKE



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 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.



Follow-Ups: