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

Re: IKEV2: Issue #2: Cipher suites



Ted:

The S/MIME WG has separated algorithm requirements from the base protocol too. This was done so that the algorithms could be updated without "opening up" the base protocol document. This is more important when the base protocol becomes a Draft Standard or a Full Standard.

I belive that the algorithms proposed by Paul are the right ones for today. One think I really like about the rationale is that it warns marketing folks and product planners which algorithms are likely to become mandatory to implement in a future update.

Russ

At 10:35 PM 2/7/2003 -0500, Theodore Ts'o wrote:

There seems general consensus over the cipher suites proposed by Paul
Hoffman.  However, not fully closed is the question of which ciphers
ought to be mandatory, and which merely optional.

The working group chairs note that this answer to these issue is very
largely dependent on the application for which IPSEC is used, and a
belief for when IKEv2 is likely to be available in the marketplace.
People who believe that IKEv2 will be deployed rapidly, and perhaps
requiring only software upgrades to existing hardware, have expressed
the desire to avoid requiring AES CBC or AES counter mode, because
many existing hardware accelerators do not support AES or counter
mode.  On the other hand, if IKEv2 does not reach maturity quickly,
the lack of a required AES cipher may very well look very silly.

It is also the case that IPSEC as applied to for VPN's will have very
radically different cipher requirements than those already expressed
for use by iSCSI.

For this reason, one potential solution (originally suggested by
Steve Bellovin to the working group chairs) towards achieving closure
on this issue would be to separate out into a separate document --- or
more likely, documents --- the specifications of which ciphers are
mandatory and which are merely optional.  Since which ciphers ought to
be mandatory will likely change more frequently than the base document
itself, combined with the need for different profiles for different
applications, we propose that the IKEv2 document remain silent about
which ciphers are required, and that separate documents, for VPN and
iSCSI applications, be drafted that contain these requirements.

                                        Barbara Fraser
                                        Ted Ts'o
                                        IPSEC working group chairs