RE: Remove little-used algorithms from IKEv2

["Hallam-Baker, Phillip" <[e-mail]>]

Any reason for keeping the MD5 algorithms given their somewhat compromised
status?

MD5 and SHA are pretty close and share the same internal structure so I
don't think we can really justify MD5 as a fallback to SHA-1, particularly
in the light of the Dobbertin results.

We should anticipate that the AES based SHA-2 algorithms will appear in due
course so it is not as if there would only be one algorithm

		Phill


Phillip Hallam-Baker FBCS C.Eng.
Principal Scientist
VeriSign Inc.
[e-mail]
781 245 6996 x227


> -----Original Message-----
> From: Paul Hoffman / VPNC [mailto:[e-mail]]
> Sent: Thursday, March 14, 2002 2:06 PM
> To: [e-mail]
> Subject: Remove little-used algorithms from IKEv2
> 
> 
> 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
> 
> 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
>