[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Simplifying IKE
No, the main purpose of quick mode was to be able to amortize the
cost of authentication over many SAs. Different SAs can be established
to protect different flows as specified by different selectors without
having to reauthenticate every time. And SAs for a particular flow can
expire and be reestablished, again, without having to reauthenticate.
You may not like PFS but it has been a continued requirement in this
working group. That is why the SKIP folks had to come up an optional
PFS extention. (It is worthwhile to look back at how that Simple protocol
became exceedingly complex-- components at IP, ICMP, and UDP, a PFS
extension, an algorithm discovery extension, a certificate discovery
extension-- in its attempt to satify the requirements from this working
group).
What is "normal" depends on perspective (as well as hardware
acceleration I guess). The Evil Kirk thought it was perfectly normal for
Spock to have a goatee.
Dan.
On Sun, 12 Aug 2001 10:04:52 BST you wrote
> This is why I have never liked the PFS option. One of the main purposes of
> quick mode is to thwart traffic analysis on ESP data without greatly slowing
> down the protocol. That's why it's called "quick".
>
> The normal thing to do is to use quick mode w/o PFS and the ultra-paranoid
> thing to do is to do more frequent phase 1 rekeys. I can't think of a
> realistic threat model that PFS solves. (Michael Richardson did once point
> one out to me in which an 'ethical law-enforcement agency' forces you to
> reveal your keys, but they are ethically prevented from using those keys to
> impersonate you.)
>
> Of all the security vulnerabilities I have seen in the design of security
> protocols, a large percentage of them came about solely through the process
> of optimization. If we truly want to have a simple and analyzable protocol,
> we have to realize that simplicity does not come merely from reducing
> options; it also comes from being conservative in our assumptions and from
> clearly separating the protocol into independent stages.
>
> A lot of people who complain about the complexity of IKE have also been
> tacking on optimizations as part of their solutions. Whenever we try to
> optimize the protocol, we have to accept that this is a design tradeoff and
> security flaws may result.
>
> 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 Derrell Piper
> > Sent: Friday, August 10, 2001 2:17 AM
> > To: sommerfeld@East.Sun.COM; Michael Thomas
> > Cc: Ari Huttunen; Dan McDonald; Sandy Harris; ipsec@lists.tislabs.com
> > Subject: Re: Simplifying IKE
> >
> >
> > QM with PFS has never really been all that "quick". However,
> > it seems a
> > valuable attribute that the relatively long-lived Phase 1 IKE
> > SA's allow
> > for seamless Phase 2 rekeying (when done right). This would
> > be much harder
> > if there were just one single negotiation.
> >
> > Derrell
> >
> > --On Thursday, August 9, 2001 7:52 PM -0400 Bill Sommerfeld
> > <sommerfeld@East.Sun.COM> wrote:
> >
> > >> Ari Huttunen writes:
> > >> > Thus my preference would be to have a four packet
> > phase 1 (base mode)
> > >> > and a four packet quick mode.
> > >>
> > >> Gad. Doesn't anybody care about link up times???
> > >
> > > Smooshing phase 1 and phase 2 together begins to look very
> > attractive
> > > when quick mode isn't very (quick).
> > >
> > > - Bill
> > >
> > >
> >
> >
> >
> >
>
Follow-Ups:
References: