RE: Last ditch proposal for crypto suites

["Hallam-Baker, Phillip" <pbaker@verisign.com>]

OK how about a different arrangement, each suite is specified as follows

<Ciphersuite>
	<Number>		1
	<Algorithms>	RSA/3DES-CBC/SHA-1 
	<Status>		Required
	<Rationale>		Provide alternative to AES

<Ciphersuite>
	<Number>		2
	<Algorithms>	RSA/AES-CTR-128/SHA-2 
	<Status>		Required
	<Rationale>		AES is prefered cryptography algorithm for 
				IETF protocols (see SAAG discussion)
				CTR mode is preferred

<Ciphersuite>
	<Number>		3
	<Algorithms>	RSA/AES-CTR-256/SHA-2 
	<Status>		Required
	<Rationale>		Support highest security version of AES

<Ciphersuite>
	<Number>		4
	<Algorithms>	RSA/AES-CBC-128/SHA-2 
	<Status>		Optional
	<Rationale>		Compatibility mode for use with hardware
that
				does not support CTR efficiently

<Ciphersuite>
	<Number>		5
	<Algorithms>	DSA/AES-CTR-128/SHA-2 
	<Status>		Optional
	<Rationale>		Backup for use in case that RSA is
compromised.
				Support applications that require DSA for
				certification reasons

<Ciphersuite>
	<Number>		6
	<Algorithms>	DSA/AES-CTR-256/SHA-2 
	<Status>		Optional
	<Rationale>		Long key version of #5



Then at the end of the discussion we go through the list and 
decide which to cull.

		Phill


> -----Original Message-----
> From: Scott Fluhrer [mailto:sfluhrer@cisco.com]
> Sent: Friday, August 30, 2002 1:22 PM
> To: Hallam-Baker, Phillip; Alex Alten; 
> Charlie_Kaufman@notesdev.ibm.com;
> ipsec@lists.tislabs.com
> Subject: RE: Last ditch proposal for crypto suites
> 
> 
> At 06:45 AM 8/30/02 , Hallam-Baker, Phillip wrote:
> >Actually following on from Radia's point I think we would 
> have three suites:
> >
> >1: RSA/3DES-CBC/SHA-1 
> >2: RSA/AES-CTR-128/SHA-2
> >3: RSA/AES-CTR-256/SHA-2
> 
> One problem with mandating AES counter mode is that there's 
> been quite a bit
> of hardware development that assumed the AES CBC mode draft.  
> Some of it can
> be changed to use counter mode without too much pain and 
> effort, but some of
> it can't.  If these are MUST suites, this means that those 
> implementations
> cannot do IKEv2 efficiently, not because they cannot do the 
> IKEv2 protocol
> itself, but because they cannot do the negotiated IPSec 
> transforms.  I would
> suggest that this is not in the IETF's best interest to impose such
> limitations.
> 
> 
> -- 
> scott
> 
>