[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: (IPng) Re: out-of-band key management is like virtual circuits
Ashar Aziz says:
> >From: Carl Muckenhirn <cfm@columbia.sparta.com>
> > Even with SKIP, there is some state kept around somewhere, maybe
> > in the DNS (more messages), but it has to exist. In the case of
> > crashes/reboot, you have to "re-establish" the context of all of
> > those connections eventually anyways (not TCP connections per-se,
> > but connections nevertheless). No one has said that the
> > re-establishment was a synchronous event, just bring them back
> > when you need them, you'll need them again in most cases.
>
> There may be state but is not connections and it is not shared-state
> (a la session keys).
A connection is not established in a modern network with wire, and
solder, Ashar. Its, too, is just a bit of state sitting in memory. As
soon as you have state, all you've done is renamed what we are talking
about.
Now, Photuris and other alternatives to your SKIP proposal aren't
"connection oriented", either. They cache a security association. You
cache data and call it something different. Big deal.
You are also being extraordinarily deceptive in claiming not to have
shared state. Of course you have shared state. If both sides didn't
know what key to expect the data to be encrypted with, no
communication could take place. The fact that you are being unusual in
the way you deal with that data in no way changes the fact that you
have state involved and shared information -- you've just renamed it.
> SKIP caching is completely session-less
> (because the SKIP master key is what needs to be cached) and does not
> need to be re-established on both sides in case of a reboot.
Of course it has to be re-established. If you don't have the data
present again, you can't communicate again. You are being deceptive by
renaming things. None of the other proposals claimed to have
"sessions" by the way -- you just claim that you are "sessionless",
but thats meaningless -- you are caching as much data as they are, and
the key database lookups you do are just as expensive as the ones
everyone else has to do.
> Even this can be eliminated, if one can cache the master keys in
> non-volatile secure memory (and we are examining several solutions
> that will permit this in a very inexpensive way). This will permit
> either side to crash/reboot and perform no public-key operations in
> order to go back into secure mode.
In what way is this different from anyone else? All the proposals I
know of would recover from crashes transparently if you had some
NV-RAM available. Big deal. In what way is this a contrast to anyone
else?
Perry