|
Brought to you by:
Suppliers of:
|
|
|
| |
| Nortel Networks Contivity Extranet Switch (CES) has a weakness in its 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. |
| |
Credit:
The information has been provided by spitko.
|
| |
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.
Background:
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) 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. 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.
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 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".
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 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. For example newest wu-ftpd is not able to update CES, but versions before wu-ftpd 2.6 do work, see 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.
Vendor status:
The vendor was notified on the 12th of February 2001 by contacting local Nortel presales people in Finland.
Local presales people have helped with debugging the weakness by providing newer software releases. The new software version solves the problem.
|
|
|
|
|
