Re: IKEV2: Issue #2: Cipher suites

[Russ Housley <housley@vigilsec.com>]

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