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

Re: Simplifying IKE

P.S. I really would prefer a 2 message version, if some smart cookie out
there can figure out how to guard against replay attacks. That would be the
coolest...

jan



On Wed, 8 Aug 2001, Jan Vilhuber wrote:

> On Wed, 8 Aug 2001, Dan Harkins wrote:
> 
> >   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"? 
> > 
> As you say, both work. One strikes me as more aesthetically pleasing, or
> cleaner, i.e. a 4th message is part of the protocol, and you don't need much
> verbiage to tell people how to handle the sync between IKE and ipsec in a 3
> message scenario. It's therefore much cleaner and offers better chances of
> passing interop (the more verbiage to explain something, the more you give
> people to argue what was meant by the verbiage).
> 
> >   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!
> > 
> 
> Or wait for a 4th message to confirm. I grant you they are almost the same.
> 
> >   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?
> > 
> It's an explicit ACK, rather than relying on implicit behaviour of lacking
> the 3rd message. It just strikes me as cleaner. it's all software. We can
> implement almost anything in software. Question is how. And obviously
> different people have different ideas of 'cleanliness' and different
> definition of 'obvious' (as we can tell from dangling SA and continuous
> channel fiascos).
> 
> Telling IPSec to instantiate a single SA, and then later possibly revoking
> it, just doesn't seem as clean to me. I'd rather only tell ipsec to go ahead
> and do its thing when IKE is completely 100% sure that we're done.
> 
> I also realize that KINK does what you propose. I didn't much like it there,
> either. So be it. The very fact that it has to be explained, rather than
> having a protocol definition, makes me nervous. But if it can be explained
> very simply, and you are confident that people won't find things they claim
> were open to interpretation (what do you mean I shouldn't delete my IPSec
> Sa's when the IKE SA that created them dies?! Duh...), then I'm OK with it.
> 
> To put it a different way: Define the protocol, and when the protocol has
> unambiguously finished, THEN (and only then) tell ipsec to proceed. This
> doesn't leave things open to interpretation of exactly when one SA should be
> instantiated and when the next should be instantiated, and so on. Maybe I'm
> just being pedantic. Being pedantic should be a good thing right now, so we
> don't repeat the past with son-of-IKE (did we decide it's 'doud', pronounced
> 'dude'?? ;)
> 
> Different folks, different strokes...
> jan
> 
> 
> 
> 
> 
> >   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
> > > 
> > 
> 
>  --
> Jan Vilhuber                                            vilhuber@cisco.com
> Cisco Systems, San Jose                                     (408) 527-0847
> 
> 

 --
Jan Vilhuber                                            vilhuber@cisco.com
Cisco Systems, San Jose                                     (408) 527-0847
Follow-Ups: References: