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