RE: User interface ciphersuites for IKEv2

["Ricky Charlet" <rcharlet@SonicWALL.com>]

Howdy,

	I agree with Paul's point about having a 'simple'
choice-already-made set of cipher suites. But I would add one tempering
note.

	We have an expectation that 'recomended' cipher suites may
change over time. New actions from inventors, standards bodies or
certification bodies may lend credence to new crypto tools not
considered at the time of 2nd Generation IKE (looking for a neutral term
there) standardization. New cryptanalysis developments may take credence
away from crypto tools which were highly regarded at the time of 2nd
Generation IKE standardization.

	About 2 years ago (I think at Washington DC, or perhaps
Adelaide) there was a discussion on this very topic at SAAG where there
was a well received suggestion about how to handle a documentation
process which could track this dynamism. Who remembers what that
suggestion was in particular, and isn't it about time we start doing
something like that?


--
"They that can give up essential liberty to obtain a little temporary 
safety deserve neither liberty nor safety." Benjamin Franklin

 Ricky Charlet     : rcharlet@sonciwall.com   : usa (408) 962-8711 





> -----Original Message-----
> From: Paul Hoffman / VPNC [mailto:paul.hoffman@vpnc.org]
> Sent: Wednesday, March 27, 2002 6:01 PM
> To: ipsec@lists.tislabs.com
> Subject: User interface ciphersuites for IKEv2
> 
> 
> Ciphersuites would greatly increase interoperability in deployments by
> reducing the number of knobs a user has to twiddle in order 
> to match two
> IPsec systems. The IKEv2 design rationale document says that 
> the authors
> wanted to do ciphersuites but didn't because they heard a lot of
> objections that "people preferred to negotiate individual algorithms".
> It is highly doubtful that end users stated this preference; 
> it is much
> more likely that implementors did so that they could accommodate a few
> users who think they get more security with more choices.
> 
> IKEv2 can have both the flexibility of individual mixing and 
> matching of
> algorithms and the simplicity of ciphersuites at the same time. Suites
> can be specified as user interface items and implementations 
> can be told
> that they should implement at least one of them (the one that matches
> the mandatory-to-implement algorithms). The suites can be 
> given letters
> (because the numbers are already taken for DH groups), and a few could
> be listed in the document, and additional ones can being 
> added later by
> IANA. The initial ones might be:
> 
> Suite A
> Phase 1: AES-128, SHA-1, preshared keys, MODP group 5
> Phase 2: AES-128, SHA-1, MODP group 5, ESP tunnel mode
> 
> Suite B
> Phase 1: AES-128, SHA-1, RSA certs, MODP group 5
> Phase 2: AES-128, SHA-1, MODP group 5, ESP tunnel mode
> 
> Suite C
> Phase 1: TripleDES, MD-5, signed DH, MODP group 2
> Phase 2: TripleDES, MD-5, MODP group 2, ESP tunnel mode
> 
> A is the mandatory-to-implement algorithms with preshared 
> keys, B is the
> same but with certs. C is secure and can be used in case there is a
> catastrophic defeat of AES, SHA-1, or MODP group 5. We would 
> also define
> a handful of others that we are sure will be used significantly used,
> such as ones with no PFS. We don't have to list every possible
> combination, only a handful that we think will help users. 
> For all other
> combinations, they can twiddle the options in the rest of the UI.
> 
> Note that these suites are for the UI only: they do no change the
> bits-on-the-wire messages at all. The system has to translate the
> ciphersuites into the proper options for the wire protocol.
> 
> If adopted, this could be the most significant user-visible 
> change from
> IKEv1 and will probably get a great deal more interest in
> successor-to-IKE than most of the other things we have talked about so
> far.
> 
> --Paul Hoffman, Director
> --VPN Consortium
>