[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Simplifying IKE
Guarding against replay attacks is easy. Just use
draft-ietf-ipsec-antireplay-00.txt.
I can see a rationale for 2, 3, or 4 message exchanges. It's just an
engineering tradeoff. As soon as we start using the above draft, we can stop
worrying about replayed messages. Therefore, the only thing to worry about
is lost packets.
Tim Jenkins pointed out a long time ago that you can't solve a packet loss
problem by extending the exchange. There will always be a new last packet,
and the last packet can't be ACK'ed, only NACK'ed. However, there is some
value in delaying use of the SA until the peer has added in in order to
avoid spurious INVALID-SPI messages that the peer might generate (although I
might add that even these can be avoided if the IKE process pre-notifies the
IPsec process of which SPIs are currently pending negotiation.
However, if we add the replay protection and eliminate PFS then I don't see
any particular reason why we couldn't make quick mode only 2 packets. If,
over my strenuous objections, we still wanted to support PFS then a 3rd
message would be required. And a 4th message if you want to make the
exchange even (although I don't personally see the value of this argument).
I have listed avoiding INVALID-SPI messages as the main reason for delaying
use of the SA. Another would be avoiding the (small) wasted bandwidth of
occasionally sending a message that the peer can't decrypt yet. Having the
router drop the first packet of a flow is a common scenario on the Internet
already; TCP will retransmit the packet soon enough. There is no reason to
get paranoid about the ocasional lost packet here and there.
If the peer had buffer space, it could save the message and decrypt it
later. Delaying the use of the SA until the peer has ACK'ed doesn't fix the
problem; it only potentially allows you to shift the storage buffer from the
receiver to the sender. (If we snuff out the replay problem as I suggest
then there is no possibility of a state-clogging attack, so it doesn't
really matter which side has the buffer.)
Andrew
-------------------------------------------
Upon closer inspection, I saw that the line
dividing black from white was in fact a shade
of grey. As I drew nearer still, the grey area
grew larger. And then I was enlightened.
> -----Original Message-----
> From: owner-ipsec@lists.tislabs.com
> [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Jan Vilhuber
> Sent: Thursday, August 09, 2001 3:18 AM
> To: Dan Harkins
> Cc: Brian Swander; Ari Huttunen; ipsec@lists.tislabs.com
> Subject: 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
>
References: