RE: Remove little-used algorithms from IKEv2

"Hallam-Baker, Phillip" <pbaker@verisign.com> Thu, 14 March 2002 20:57 UTC

Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2EKvs423951; Thu, 14 Mar 2002 12:57:55 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA05584 Thu, 14 Mar 2002 15:19:55 -0500 (EST)
Message-ID: <2F3EC696EAEED311BB2D009027C3F4F405869A08@vhqpostal.verisign.com>
From: "Hallam-Baker, Phillip" <pbaker@verisign.com>
To: 'Paul Hoffman / VPNC' <paul.hoffman@vpnc.org>, ipsec@lists.tislabs.com
Subject: RE: Remove little-used algorithms from IKEv2
Date: Thu, 14 Mar 2002 12:32:33 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C1CB97.5EB27B20"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk

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
>