Home page logo
/

bugtraq logo 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


  By Date           By Thread  

Current thread:
  • Re: Nortel CES (3DES version) offers false sense of security when usi ng IPSEC Eric Vyncke (Feb 28)
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]