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

Re: Moving forward with IKE V2: A proposal for final edits to ikev2-04

At 9:58 PM -0500 2/1/03, Charlie_Kaufman@xxxxxxxxxxxxxxxx wrote:
Stephen Kent <kent@xxxxxxx> wrote on 01/31/2003 06:31:45 PM:
 It is likely that IANA will add additional Suite-IDs in the future, and
 some users may want to use private suites, especially for IKE where
 implementations should be capable of supporting different parameters,
 up to certain size limits. In support of this goal, all
 implementations of IKEv2 SHOULD [I'd prefer MUST, but Paul has argued
 eloquently for very restrictive criteria for MUST re suites.] include
 a management facility that allows specification (by a user or system
 administrator) of Diffie-Hellman parameters (the generator, modulus,
 and exponent lengths and values) for new IKE Suites. Implementations
 SHOULD provide a management interface via which these parameters and
 the associated Suite-IDs may be entered (by a user or system
 administrator), to enable negotiating such Suites.

I would strongly oppose making this a "MUST" and have mixed feelings about "SHOULD". If we are going to include it, I think we have to say what the size limits are, and whether all intermediate sizes SHOULD be supported. We had such a debate over RSA key sizes, without concrete resolution. The current draft says 1024 and 2048 bit keys MUST be supported and doesn't say anything about SHOULD. There exist implementations of crypto toolkits that don't support RSA keys that are not an integer multiple of 16 bits in size. Very general requirements make conformance testing harder.



My goal in pushing for this is NOT to require any implementation to support a bigger key size, but rather to allow specification of parameters within whatever constraints we established separately for parameters sizes. I'm very much open to rewording suggestions to avoid any confusion over this aspect of my proposed text.