[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Simplifying IKE
I believe that using the Message ID field as a counter
has already been suggested, and in this case should work
to prevent replay attacks.
----- Original Message -----
From: "Jan Vilhuber" <vilhuber@cisco.com>
To: "Dan Harkins" <dharkins@lounge.org>
Cc: "Brian Swander" <briansw@windows.microsoft.com>; "Ari Huttunen"
<Ari.Huttunen@F-Secure.com>; <ipsec@lists.tislabs.com>
Sent: Wednesday, August 08, 2001 9:17 PM
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
>
Follow-Ups:
References: