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

SKIP in IPSEC: is it really simple?

skrenta at osmosys.incog.com writes
 >
 > CDP is only needed once for the lifetime of the key to obtain the long
 > term certificate.  And if DNSSEC is used, CDP isn't even necessary.
 >
 > ADP isn't needed if one has ACLs configured to choose the desired
 > encryption algorithms.  I send a triple-DES SKIP packet, if the other
 > side is happy with that, the packet is accepted, and no ADP comes back.
 >
 > It is even possible to achieve PFS with SKIP without a "PFS exchange",
 > by using short-lived keys certified with a long-term secret.  One can
 > thus "turn the PFS crank" at an administratively configurable interval.

How can you say in paragraph 1 that certificate discovery is no problem
since it's needed only once to obtain the long term certificate, and in
paragraph 3 to say that even "PFS exchange" is not needed since you can
change your certificate each day (hour?)
Isn't this a highly misleading argument??

Plain SKIP (no pfs, no CDP, no ADP) is simple.
With all these additions it is not that simple (not SKIP's
fault but the inevitable complexity of our requirements/applications).
If in addition you start considering all the "submodes":
      yes PFS/no PFS,
      long term certificates/ short term cerificiates,
      yes algorithm discovery/ no algorithm discovery,
      yes anonymity/no anonymity (with/without PFS),
      per-packet SKIP header/ per-session SKIP header, etc.
then SKIP is COMPLEX (not SKIP's fault: I've heard voices in this list
for almost every possible combination of these submodes!).

In ISAKMP/Oakley these complexities appear explicitly instead of blurred
over different Internet drafts. But let's not lie to ourselves FULL SKIP
(as needed to support those requirements on which there is already
WG consensus: PFS, certificate-based key mgmt, anonymity)
is COMPLEX.

ISAKMP/Oakley, on the other hand, has several security advantages
over SKIP (hand-shakes for key exchange/refreshment, freshness proof
in each exchange, randomness contributed by both parties to the key,
no reliance on shared time, explicit framework to analyze security,
no reliance in universal DH group, explicit negotiation and authentication
of key attributes).

Let's choose the most desirable subset of Oakley exchanges
and make them mandatory (ie, basis for inter-operability).
ISAKMP and the other Oakley exchanges give the basis for
optional/future extensions.

And if in-band keying is desirable let's decide on it as an extension too
(in my opinion: combined as a transform into AH and ESP rather
than via a separate header).

Hugo