Nortel Networks response to Contivity Extranet switch security co ncern

[David Passamonte <dpassamo () NORTELNETWORKS COM>]

        Bugtraq #
<8CB7F81A5D17D31197A60008C7EBE37103341C9B () helsrv01 vaisala com>
        Date Submitted: on Feb 26 2001 10:21:51

        This note addresses security concerns raised around the use of
single DES(1DES) in IKE Phase 1 exchanges.
        Response to: Nortel CES (3DES version) offers false sense of
security when using IPSec.

        Point 1: The Nortel Networks Contivity Extranet switch provides
IPSec Triple DES (3DES) data encryption using IKE main mode and IKE
aggressive mode key exchange in accordance with IETF RFC 2409.

        Point 2: The Phase 1 established ISAKMP SA key material is obtained
from the Phase 1 D-H key exchange. Any encrypted IKE messages exchanged over
the ISAKMP SA will use this key. i.e. phase 2 messages. Cracking the Phase 1
key does NOT expose phase 2 encrypted data.

        Point 3: Phase 2 key material, which is obtained using the Phase I
SA, is also obtained from a D-H key exchange if Perfect Forward Secrecy(PFS)
is enabled. PFS is enabled by default for all versions of the Contivity
Extranet Switch.


        Point 4: Phase 1 D-H group 2 support with 3DES is available in
V03_50.44. Nortel Networks recommends upgrading to this version of software
if there are concerns surrounding this issue.



        As stated above, all versions of Contivity software have Perfect
Forward Secrecy (PFS) enabled by default. For situations where D-H group
1/DES IKE phase 1 exchanges are not deemed adequate the Nortel Networks
default value with PFS should be used in conjunction with frequent
re-keying. PFS initiates a IKE phase 2 QM exchange and performs a new D-H
exchange under the protection of an existing IKE SA to derive new keying
material independent of the original keying material generated in IKE phase
1.
        
        At no time does the use of D-H group 1/DES imply that the IPSec data
channels are subject to attack based on the compromise of a single 56-bit
key as suggested. The relative cryptographic strength of a Group 1 D-H
exchange is much greater than that of 56-bit DES CBC. Therefore, with PFS
enabled, cracking of the 56-bit DES CBC key used to protect the IKE SA does
NOT compromise the 3DES CBC key material protecting the IPSec data channel.

While it is recognized 56-bit DES is not recommended by the cryptographic
community, measures can be taken with software pre-dating v02_62.x to extend
the privacy lifetime of data protected by IPSec 3DES. Taking the following
measures will extend the privacy lifetime of data far beyond the privacy
lifetime of 56-bit DES when brute force or plain-text attacks are employed.
*       Use PFS
*       Use IPSec w/ 3DES/SHA-1
*       Re-key often
*       Use RSA digital signatures
        Nortel Networks has implemented Diffie-Hellman group 2 with 3DES for
IKE phase 1 in v03_50.44 and recommends upgrading to this version of
software if concerns exist surrounding this issue. It should be noted that
implementations of IKE that do NOT support Diffie-Hellman Group I exchanges
are not compliant with the current IPSec standard. It is for this reason
that the Contivity product continues to support these groups. The
administrator can always choose to disable these groups if so desired.
        
        Important notes and details clarification:
*       It was cited that the EAC will fall back to DES_CBC if the initial
IKE SA proposal cannot be negotiated for 3DES_CBC. This is ONLY true if
configured so by the administrator. IKE Phase 1 parameters may be configured
as follows:
        3DES with DH group 2
        DES with DH group 1
        Both 3DES with DH group2 and DES with DH group1
        
        If support of client software predating v02_62 (DES with DH group1)
is NOT desired select 3DES with DH group 2 ONLY.
        
        The same applies for branch office connections when negotiating down
to DES_CBC is NOT desired.
*       The example sited shows an aggressive mode IKE SA being negotiated
for branch office connections. The CES uses only IKE main mode for branch
office connections.
                
                The comments regarding upgrades and configuring IPSec
settings states:
        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.
        
        The "IKE Encryption and Diiffie-Hellman Group" field actually allows
for configuration of:
        
        56-bit DES with Group1 (768-bit prime)
        or
        3DES with Group2 (1024-bit prime)
        
        not 56-bit or 128-bit. As the author pointed out earlier, 3DES has a
168-bit effective key space.
        
        In addition the CES uses an LDAP directory structure that allows
user centric profile configuration. If you want to use both 56-bit
        
        DES clients (client software pre-dating v02_62) and DES/3DES Group1
and Group2 clients (client software v02_62 and higher) simply create a group
profile for each. You DO NOT have to upgrade all client software in the
field.
        
As always Nortel Networks Contivity team is committed to providing devices
of the highest quality and security. Peer review is a critical component of
the evolving security framework used today, and appreciates the interest
given in this area by others. The CES is currently certified in several
areas to FIPS certification criteria as follows:

CES is FIPS 140-1 level 2 certified, certificate #98
http://csrc.nist.gov/cryptval/140-1/1401val2000.htm

The CES  implementation of SHA-1 is FIPS certified, certificate #31
http://csrc.nist.gov/cryptval/dss/dsaval.htm#SHAvals


The CES  implementation of DES is FIPS certified, certificate #48
http://csrc.nist.gov/cryptval/des/desval.html

Nortel Networks considers this resolution to bugtraq #
<8CB7F81A5D17D31197A60008C7EBE37103341C9B () helsrv01 vaisala com>