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

The WG's inability to choose is good in this case.

John Gilmore says:

 > We are stuck for a good reason; we don't want to make a good political
 > decision.  We want to make a good technical decision, and there is no
 > good technical choice for securing the Internet right now.  The IPSEC
 > process is working.  It looks too slow because the technical proposals
 > and implementations need to evolve faster than they have been, not
 > because the consensus process has failed.
 >

There is NO strong technical reason that impedes the convergence of
ISAKMP, Oakley and SKIP. There is nothing essentially contradictory
between these protocols. Technically, they can be merged at not much cost.
(Of course, the resultant protocol will not be as simple as the basic SKIP,
but the latter is in any case not an IPSEC-acceptable stand-alone solution
as it does not provide PFS). Therefore, I conclude, the difficulties
in finding a common ground are purely political.

In order to accomodate SKIP functionality into Oakley there are two
issues to decide on:

(1) Support of DH-certificates
(2) Support of in-line keying

These two issues are mostly independent (ie, the decision on one does not
depend on the other).

Support for (2) can be added to Oakley with no implication to the rest of the
protocol (some issues are: (a) mandatory-vs-optional to implement,
(b) separate header for carrrying the packet key or combined into the
existing ESP and AH transforms, (c) SPI allocation)

Support for (1), especially if mandatory, is more delicate. It would mean
that each IPSEC-compliant host will need a DH certificate. (As opposed to,
say, an RSA or DSS certificate). It means also that we'll need to define
a universal DH group (e.g. prime p and generator g) on which to work.

I am personally not enthusiastic about the latter but was (and am) willing
to accept it in order to resolve the WG deadlock.
In particular, I have suggested particular ways to accomodate DH-certificates
for key derivation in Oakley (actually this is part of my suggestions
in my SKEME proposal from a year ago).

One personal clarification regarding (2): in my opinion, there is a
strong technical basis to require key exchange/refreshment via authenticated
handshakes as supported by Oakley (even if in-line keying is also supported
by the protocol). And I believe (hope) that SUN (in particular, Ashar)
would not oppose that.

Hugo