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. pbaker@verisign.com 781 245 6996 x227 > -----Original Message----- > From: Paul Hoffman / VPNC [mailto:paul.hoffman@vpnc.org] > Sent: Thursday, March 14, 2002 2:06 PM > To: ipsec@lists.tislabs.com > 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 >
Phillip Hallam-Baker (E-mail).vcf