[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, spitkoHOTMAIL.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: evynckecisco.com Mobile: +32-475-312.458 (CHANGED)
PGP fingerprint: D35F BEF9 643F 656F 90F5 76C5 9CA1 C289 D398 B141

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]