Re: Nortel CES (3DES version) offers false sense of security when usi ng IPSEC

[Tina Bird <tbird () PRECISION-GUESSWORK COM>]

Note there are two mitigating circumstances:

1) if Diffie-Hellman is used for key generation in ISAKMP phase
two, then the keys used for IPsec encryption are never themselves
passed through the DES-encrypted phase two tunnel, so using DES
to encrypt phase two negotiation doesn't introduce a vulnerability

2) although DES is vulnerable to brute force attacks within
a few hours, for an attacker to exploit this weakness she would
have to be able to crack the DES key within seconds -- the amount
of time the ISAKMP phase two negotiation is proceeding --
which is unlikely in most cases.

I do of course think we should use 3DES when possible...

cheers -- Tina Bird

On Mon, 26 Feb 2001 spitko () HOTMAIL COM wrote:

> Date: Mon, 26 Feb 2001 11:21:51 +0200
> From: spitko () HOTMAIL COM
> To: BUGTRAQ () SECURITYFOCUS COM
> Subject: Nortel CES (3DES version) offers false sense of security when usi
              ng IPSEC
> Short summary:
>
> Nortel Networks Contivity Extranet Switch (CES) has a weakness in it's IPSEC
> key exchange when using 3DES encryption. The 3DES encryption keys are
> encrypted using single DES during initial key exchange thus reducing
> cryptographic strength to 56-bit DES level. The weakness affects both CES to
> other IPSEC device (including another CES) tunnels and remote user to CES
> tunnels created with Nortel Extranet Access Client.
>
> Basics:
>
> CES is a VPN concentrator used between untrusted (Internet) and trusted
> network, which supports among other protocols IPSEC. Nortel ships CES'es in
> two versions, 56 and 128 bits encryption versions (for example CES 1510 and
> CES 1510D; D stands for domestic == 128 bits version). For some reason
> stickers on shipping package says 128 bit encryption and documentation
> states 168 bits (== 3*56 bits DES) encryption.
>
> The weakness exists at least in software versions 2.5x and 2.6x. Extranet
> Access Client version 2.62 has been patched, as well as newest version of
> CES software (3.50).
>
> Details:
>
> IPSEC IKE (RFC2409 <URL:http://www.google.com/search?q=rfc2409&btnI=>)
> defines two phase key exchange. IKE phase 1 creates a Security Association
> (ISAKMP SA) between two peers. ISAKMP SA is created by negotiating an
> encryption algorithm and changing encryption keys securely regardless of
> eavesdropping third party. Encryption key for ISAKMP SA is negotiated using
> Diffie-Hellman exchange. If Perfect Forward Secrecy (PFS) is not requested,
> one ISAKMP SA can be used to create multiple secure channels in IKE phase 2.
>
> In phase 2, the actual algorithm used for data encryption in IPSEC tunnels
> is negotiated and encryption keys are exchanged. Phase 2 relies on
> encryption level created in phase 1. If I have read and understood IKE RFC
> correctly, keys used for data encryption are "normally" (RFC doesn't
> _require_ Diffie-Hellman exchange inside ISAKMP SA, but allows it  if
> approved by both peers) exchanged inside ISAKMP SA in plain text. Hopefully
> someone will prove me wrong.
>
> Nortel CES prior to version 3.50 and Extranet Access Client prior to version
> 2.62 create IPSEC IKE phase 1 ISAKMP SA using only single DES (56-bits),
> regardless of encryption settings on CES. Eavesdropper is able to resolve
> the 3DES encryption keys only by (brute force or otherwise) cracking the IKE
> phase 1 single DES key. Single DES is crackable in less than 24 hours
> according to <URL:http://www.rsasecurity.com/rsalabs/des3/index.html>
>
> Following are sample IKE negotiations with different CES and Extranet Access
> Client versions (all CESes involved have only 3DES/MD5 and 3DES/SHA
> encryption algorithms enabled for IPSEC):
>
> Client version 2.61 or below (3DES capable)
> CES version 2.63 or below (3DES capable)
> IKE negotiation:
> client:       IKE proposal, DES_CBC algorithm, MD5, aggressive mode
> CES:          IKE Diffie-Hellman key exchange, DES_CBC
> client:       encrypted response, phase one completed
> (3DES encryption key exchange inside ISAKMP SA just created)
>
> Client version 2.62 or higher (3DES capable)
> CES version 2.63 or below (3DES capable)
> IKE negotiation:
> client:       IKE proposal, 3DES_CBC algorithm, MD5, aggressive mode
> CES:          IKE notification, No Proposal Chosen
> client:       IKE proposal, 3DES_CBC algorithm, MD5, aggressive mode
> CES:          IKE notification, No Proposal Chosen
> client:       IKE proposal, 3DES_CBC algorithm, MD5, aggressive mode
> CES:          IKE notification, No Proposal Chosen
> *client fallback to DES_CBC*
> client:       IKE proposal, DES_CBC algorithm, MD5, aggressive mode
> CES:          IKE Diffie-Hellman key exchange, DES_CBC
> client:       encrypted response, phase one completed
> (3DES encryption key exchange inside ISAKMP SA just created)
>
> Same applies to branch office connections (VPN tunnels between two
> networks):
> CES1 version 2.63 or below (3DES capable)
> CES2 version 2.63 or below (3DES capable)
> IKE negotiation:
> CES1:         IKE proposal, DES_CBC algorithm, MD5, aggressive mode
> CES2:         IKE key exchange, DES_CBC
> CES1:         encrypted response, phase one completed
> (3DES encryption key exchange inside ISAKMP SA just created)
>
> The warning message for 3DES IKE rejection in CES can be found from
> Status/Event Log by searching for string "ISAKMP [13] No proposal chosen
> in message from".
>
> The reason I found this weakness was an interoperability issue between
> FreeS/WAN 1.8 and CES. FreeS/WAN has dropped support for single DES in IPSEC
> IKE phase 1 in FreeS/WAN release 1.6. So these two products couldn't
> interoperate because 3DES version of CES couldn't do 3DES key exchange.
>
> Solution:
>
> Upgrade to CES to version 3.50 and Extranet Access Client software to at
> least version 2.62.
>
> According to release notes for software version 3.50
> <URL:http://www25.nortelnetworks.com/library/tpubs/pdf/extranet/301459S00.PD
> F> Nortel has added a capability to send message/drop connection based on
> client version. This could be used for informing about update or restricting
> access for clients with versions below 2.62.
>
> According to release notes, version 3.50 software is not supported on CES
> 600 or CES 1000 series.
>
> CES upgrade procedure requires a ftp-server which implements NLST command
> incorrectly according to RFC959
> <URL:http://www.google.com/search?q=rfc959&btnI=>. For example newest
> wu-ftpd is not able to update CES, but versions before wu-ftpd 2.6 do work
> <URL:http://www.wu-ftpd.org/wu-ftpd-faq.html#QA84>.
>
> After upgrade you should check the IPSEC settings for Profiles/Groups and
> Profiles/Branch office. The setting is named "IKE Encryption and
> Diffie-Hellman Group" and it can be set to 56-bit or to 128-bit encryption.
> Unfortunately you have to upgrade all your Extranet Access Clients at once,
> because the setting is exclusive. You cannot have both 56 and 128 bits
> encryption for IKE activated.
>
> This weakness does not mean that data in VPN tunnels created with CES is not
> encrypted with specified level. Only the _effective_ encryption level is
> reduced to single DES security regardless of CES version used, if
> eavesdropper is able to capture IKE negotiation. IKE negotiation is
> performed through the same routers in Internet as the encrypted data is
> routed after IKE. IKE negotiation is also quite easy to harvest from large
> amount of network packets because of it's unique characteristics: IKE use
> UDP protocol and both source and destination ports are 500 in every IKE
> packet.
>
> Versions tested:
>
> CES 1500D running software 2.51 - single DES IKE
> CES 1510D running software 2.60 - single DES IKE
> CES 1510D running software 2.61 - single DES IKE
> CES 1500D running software 2.63 - single DES IKE
> CES 1500D running software 3.50 - 3DES IKE
> Extranet Access Client 2.51 (128-bit version) - single DES IKE
> Extranet Access Client 2.62 (128-bit version) - 3DES IKE
>
> Other CES models (domestic versions of 600, 1000, 2500, 2600, 4500, ...)
> most probably contain the same weakness, as Nortel seems to run the same
> software in all models.
>
> Vendor notified:
>
> 12th of February, 2001 by contacting local Nortel presales people in
> Finland.
>
> Vendor response:
>
> Local presales people have helped with debugging the weakness by providing
> newer software releases. No other response so far. New software version
> solves the problem.

VPN:  http://kubarb.phsx.ukans.edu/~tbird/vpn.html
life: http://kubarb.phsx.ukans.edu/~tbird
work: http://www.counterpane.com