MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15926.44131.464641.710215@pkoning.dev.equallogic.com>
Date: Tue, 28 Jan 2003 11:14:27 -0500
From: Paul Koning <pkoning@equallogic.com>
To: howard.c.herbert@intel.com
Cc: ipsec@lists.tislabs.com, Black_David@emc.com, ips@ece.cmu.edu
Subject: RE: Ciphersuites for IKEv2
References: <5AE0592A6AF6494F80CE87370A723B1F2344A3@azsmsx401.ch.intel.com>
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

>>>>> "Howard" == Howard C Herbert <Herbert> writes:

 Howard> Per the admonition in David's email below, I would like to
 Howard> request that in addition to the following cipher suites
 Howard> already on the list:

 Howard> AES-CBC + HMAC-SHA-1 AES-CTR + AES-CBC MAC w/XCBC

 Howard> that the following additional cipher suites be added:

 Howard> AES-CBC + AES-CBC-MAC w/XCBC AES-CTR + HMAC-SHA-1

 Howard> As noted above, these algorithms will already exist in an
 Howard> implementation.  Not being able to use them in the added
 Howard> combinations simply because we do not have a ciphersuite
 Howard> defined for them seems like a real easy thing to fix at this
 Howard> point.

The whole point of cipher suites is NOT to expose the O(2^n)
combinations.  

There may be valid reasons to add suites, but "the components already
exist" surely is not a valid reason.

       paul