Bugtraq mailing list archives
Re: Nortel CES (3DES version) offers false sense of security when usi ng IPSEC
From: Eric Vyncke <evyncke () CISCO COM>
Date: Tue, 27 Feb 2001 16:22:41 +0100
[If you look to my signature, you will probably smile ;-) ] This is not a HUGE issue, because the real security of phase 1 comes from the Diffie-Helman key exchange and from the IKE authentication. The phase 2 SA are negotiated by the Quick Mode exchange and can be done without a new DH by reusing the previous DH key material plus some random numbers exchanged during Quick Mode. So, even with the bug, the phase 2 keys are protected through the original DH. Breaking the phase 1 key (which seems easy based on the original email) gives access to the identity and to the negotiated policies. Bad of course, but not a CATASTROPHIC security hole. Regards -eric At 11:21 26/02/2001 +0200, spitko () HOTMAIL COM wrote:
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.
Eric Vyncke Distinguished Engineer Cisco Systems EMEA Phone: +32-2-778.4677 Fax: +32-2-778.4300 E-mail: evyncke () cisco com Mobile: +32-475-312.458 (CHANGED) PGP fingerprint: D35F BEF9 643F 656F 90F5 76C5 9CA1 C289 D398 B141
Current thread:
- Re: Nortel CES (3DES version) offers false sense of security when usi ng IPSEC Eric Vyncke (Feb 27)