Re: Remove little-used algorithms from IKEv2

["Stephane Beaulieu" <[e-mail]>]

> The early goals of the successor-to-IKE work was to make it simpler
> and more interoperable. Continuing to list values for algorithms that
> are rarely used or do not have good interoperabilty, or both, goes
> against both of those goals. Some should be removed because they have
> security properties that are so similar to other algorithms that are
> more used that they add nothing to the security of IPsec; they were
> added "because we could" but at the expense of interoperability and
> simplicity. Some of the algorithms, such as single DES, should be
> removed simply because they are a bad idea for security.
>
> The following lists show the algorithms should be removed from the
> IKEv2 spec. Those marked with an asterisk should be removed from
> IKEv2.
>
> Encryption algorithms:
>    RESERVED                    0
> * ENCR_DES_IV64               1              (RFC1827)
> * ENCR_DES                    2              (RFC2405)
>    ENCR_3DES                   3              (RFC2451)
> * ENCR_RC5                    4              (RFC2451)
> * ENCR_IDEA                   5              (RFC2451)
>    ENCR_CAST                   6              (RFC2451)
> * ENCR_BLOWFISH               7              (RFC2451)
> * ENCR_3IDEA                  8              (RFC2451)
> * ENCR_DES_IV32               9
> * ENCR_RC4                   10
>    ENCR_NULL                  11              (RFC2410)
>    ENCR_AES_128               12

I don't think that encr. alg. and hmac alg. are problems of
interoperability.  As long as everyone implements the MUSTs, everything
should be fine.  There will always be multiple ciphers offered of which you
need to pick one, so the code will exist no matter how many choices there
are.

I'm not saying that it's not OK to remove those that aren't actually
used.... I'm just saying that having more than 3 choices does not affect
interoperability (unless of course an implementation can't handle proposals
with 200 ciphers in them :)

Having said that.  I have encountered a situation where some customer (in
Europe?) was not allowed to use any other cipher other than IDEA.  Can't
remember why?  Anyone know of a good reason why we can't get rid of IDEA?



>
> Pseudo-random Functions:
>    RESERVED                    0
>    PRF_HMAC_MD5                1                   (RFC2104)
>    PRF_HMAC_SHA                2                   (RFC2104)
> * PRF_HMAC_TIGER              3                   (RFC2104)
>
> Integrity:
>    AUTH_HMAC_MD5              1                     (RFC2403)
>    AUTH_HMAC_SHA              2                     (RFC2404)
> * AUTH_DES_MAC               3
> * AUTH_KPDK_MD5              4                     (RFC1826)
>
> In the same vein, all certificate formats other than #4 (X.509
> Certificate - Signature) should be deprecated as well. "PKCS #7
> wrapped X.509 certificate" is particularly bad given that there is no
> standard for how to "wrap" a certificate.
>
> --Paul Hoffman, Director
> --VPN Consortium