HSC
Network Security Consulting Agency Since 1989 - Specialized in Unix, Windows, TCP/IP and Internet
Text mode: access to the page content
Hervé Schauer Consultants
You are here: Home > Resources > IPsec > IPsec 2001 Interop Demo
Go to: HSC Trainings
Search:  
Version française
   Services   
o Skills & Expertise
o Consulting
o ISO 27001 services
o Vulnerabilities monitoring
o Audit & Assessment
o Penetration tests
o Vunerability assessment (TSAR)
o Forensics
o ARJEL
o Training courses
o E-learning
   Conferences   
o Agenda
o Past events
o Tutorials
   Resources   
o Thematic index
o Tips
o Lectures
o Courses
o Articles
o Tools (download)
o Vulnerability watch
   Company   
o Hervé Schauer
o Job opportunities
o Credentials
o History
o Partnerships
o Associations
   Press and
 communication
 
 
o HSC Newsletter
o Press review
o Press releases
o Publications
   Contacts   
o How to reach us
o Specific inquiries
o Directions to our office
o Hotels near our office
|>|IPsec 2001 Interop Demo  
> Description Information on the setup of the interoperability demonstration platform for the IPsec 2001 conference and results of the tests conducted.
> Table of content Introduction
Course of events
Participants
Network Layout
IKE/IPsec parameters
Test results
   Summary table
   Success
   PKI issues
   Miscellaneous issues
Config files
> Related documents PDF Slides of the presentation made during the IP Security conference by IIR [3 December 2001 - English]
PDF Slides of the presentation made during the IPsec 2001 conference [24 October 2001 - English]
[Techno-watch]  Report on the conference [29 October 2001 - French]
dir  Report on the IPsec 2000 demonstration [November 2000 - French/English]
[Theme]  IPsec theme
> Author Ghislaine Labouret
> Copyright © 2001, Hervé Schauer Consultants, all rights reserved.

 

IPsec 2001


Introduction

On the occasion of the IPsec 2001 conference, organized by Upper Side , an IKE/IPsec demonstration and test platform was set up. The event was coordinated by HSC , which acted as an integrator, and mainly provided its expertise in network security (and in particular IPsec ).

The aims of this event were to:

  • Demonstrate interoperability to the public
  • Get a feeling of the feature level of current IPsec implementations
This event is not a bakeoff, it was not intended to perform exhaustive or advanced features testing.


Course of events

This demonstration was conducted as follows:

  • Preparation in HSC's office from Thuesday 16 to Monday 22 October (excluding the week-end).
    • Network setup
    • Tests so as to find working configurations

  • Moving the hardware to the conference center (La Défense) on Tuesday 23 October at 7:30 AM (a carrier has been reserved).
  • Demonstration during the IPsec 2001 conference, from Tuesday 23 (8am) to Thursday 25 October (6pm)
    • The platform was displayed in the exhibition area of the conference center and vendors answered the public's questions
    • Ghislaine Labouret from HSC introduced the demonstration and gave a quick overview of tests results at the conference (slides)
    • Press representatives were invited to take a look at the platform during the welcome reception
  • After the conference
    • Vendors willing to perform additional tests are welcome to leave their devices in HSC's lab for some time
    • A report is published on HSC's and Upper Side's web sites


Participants

The list of participating devices is:

VendorDeviceSetup by
6WIND 6WINDGate 6200 Series 6WIND
Cisco PIX firewall, version 6.0(1) Ghislaine Labouret
VPN 3000, version 3.1
2621 router, IOS version 12.2(1a) Netcelo
FreeS/WAN 20011016 snapshot (quite similar to version 1.91) + X.509 patch v0.9.3 beta Andreas Steffen <andreas.steffen@zhwin.ch>
(author of the X.509 patch for FreeS/WAN)
Netasq F100, version 3.5.0 Netasq
Netcelo Netcelo VPN Gateway (extended isakmpd running over FreeS/WAN 1.91) Netcelo
NetScreen NetScreen NS 100a, version 2.6.1r1 Snaiso, French reseller
Nortel Contivity Extranet Switch, 1500 version 4.0 Nortel
OpenBSD OpenBSD-3.0 beta's isakmpd Ghislaine Labouret

Several PKI solutions vendors were contacted for this demonstration; the only participant was IDEALX, with IDX-PKI.


Network layout

All the devices were directly interconnected through an ethernet 10 base T network, simply made of hubs. A PC connected to the hub provided traffic analysis (ethereal).

We used static IP addresses: each device was given an address of the form 192.70.106.xxx and had to use 10.xxx.0.0/16 on its internal network.

Those addresses were defined in a DNS server, inside the ipsec2001.hsc.fr domain


IKE/IPsec parameters

The test case is the following:

  • Fully meshed, gateway-to-gateway VPN
  • Protect all traffic between internal networks
  • Use exclusively IKE (no manual IPsec)

Phase 1 parameters:

  • Main Mode, 3DES, SHA-1, DH group 5 or 2, default lifetimes
  • Peer authentication:
    • RSA Signature
    • Device certificates issued by CA signed by a root CA
    • Revert to pre-shared keys only if RSA-SIG fails

Phase 2 parameters:

  • No PFS
  • Protect all traffic between internal networks
  • Negotiate tunnel mode ESP (AES or 3DES, HMAC-SHA-1)
  • No compression

We suggest testing the following situations:

  • Initial negotiation
  • Rekeying
  • Voluntary SA deletion


Test results

The following table sums up the results obtained on 5 November 2001:

Responder
Initiator
6WIND Cisco IOS Cisco PIX Cisco VPN 3000 FreeS/WAN Netasq Netcelo NetScreen Nortel OpenBSD
6WIND                    
Cisco IOS                   Local cert
Cisco PIX                   Local cert
Cisco VPN 3000                    
FreeS/WAN               PSK    
Netasq             Transform n°     Transform n°
Netcelo                    
NetScreen                    
Nortel                   Empty CA
OpenBSD   Local cert
Prop n°
Local cert
Prop n°
Proposal n°            

Legend:
  Success: RSA_SIG with online certificate exchange
  Ok, but had to downgrade the features
  Failure: no workaround found, traffic not going through

These results have evolved since the results presented during the conference, which you can find in the slides of the presentation made on October 24 (PDF - 891KB).

Below are the details of those results, notably the limitations, necessary adjustments, characteristics and bugs detected.
Here is an implementation-based index of those items:

Success

For all the green cells above, we found a configuration for which:

  • The IKE negotiation worked
  • A simple traffic test (mostly ping) works

In some cases, we used short lifetimes so as to check that the rekeying went fine. But these tests were not exhaustive and the results were not recorded. However, we did not discover any major bug in the rekeying

We had the occasion to test the following new features:

  • IPv6: 6WIND & OpenBSD; there is a patch for FreeS/WAN, but it was not tested
  • DH group 7 (ECC): Nortel Contivity & Cisco VPN 3000
  • AES in phase 2: Netasq (128/256), NetScreen (128), OpenBSD (128/256)
All these features worked at first try.

PKI issues

The aim of this demonstration was to make the devices interoperate with an RSA signature authentication, with online certificate exchange.

Enrolment protocol

This part concerns the retrieval of the CA certificate and of its own certificate by a device. The available methods were:

  • File based (PKCS#10 + copy-paste/FTP/floppy): supported by all devices except Cisco IOS and Cisco PIX.
  • SCEP: Cisco IOS, Cisco PIX, Netcelo, NetScreen
  • CMP: Nortel
IDEALX implemented SCEP (Simple Certificate Enrolment Protocol) support in their PKI during the preparation week. CMP support was not available and thus not tested.

Key length limitations

Initially, we used 4096 bits keys for the CAs. Even though the error messages did not explicitly mention key length, errors appeared on some devices:

  • When receiving a peer's certificate, the Nortel box complained about an invalid signature.
  • The Cisco IOS and PIX refused to record the CA certificate.

Certification hierarchy and multiple CAs

We used a certificate hierarchy composed of two CAs: a root CA (self-signed certificate) and an operational CA (certificate signed by the root CA).

All the devices accepted this simple hierarchy, except Cisco PIX and IOS, which require a single, self-signed CA certificate. For those devices, we generated a self-signed certificate for the operational CA. [Note: As of version 12.1(5)T, Cisco IOS supports 2-tiered certificate chaining.]

The tests we should have performed here, but for which time lacked are:

  • Path validation: check which CA certificate(s) the device needs a local copy of.
    A priori, the devices only send their own certificate, without the certificate of the issuing CA. So the peer must have a local copy of all the operational CAs certificates. It can then either directly trust those CAs (most common case), or it can require the root CA certificate to check those certificates.

  • Using several operational CAs
    the reason why one might need a certification hierarchy is to delegate certificate issuance to several operational CAs, all certified by a root CA which devices trust. Cross certification can also be used, to link devices which were initially configured with certificates from different CAs. Most of the devices taking part in the demonstration should handle several CAs and can even have several local certificates.

Certificate requests

During the IKE negotiation, each peer can ask the other one to send its certificate by including a CERT_REQ payload in an IKE message. Several behaviors are possible:

  • Sending or not sending CERT_REQ
    • Most of the time, the sending of the request is automatic. On some devices (Netasq, Netcelo), it is configurable.
    • FreeS/WAN and OpenBSD do not send CERT_REQ (feature not implemented). With most devices, that's not a problem, because they send their certificate anyway. But Cisco IOS and PIX stay closer to the standard and do not send their certificate in this situation. The following workarounds were used during the demonstration:
      • FreeS/WAN: Andreas Steffen implemented CERT_REQ support during the demo preparation. This feature will be publicly available from version 0.9.3 of the X.509 patch.
      • OpenBSD: it is possible to replace the online certificate reception by providing a local copy of the certificate or public key of the peer. This is a feature reduction, thus the yellow cells in the results table.

  • Certificate type
    The CERT_REQ payload includes a field which specifies the type of certificate requested.
    • All devices support the X.509-SIG type (type 4), so we used this type during the tests. NetScreen also supports PKCS#7 (type 1).
    • By default, NetScreen sends a request for an unspecified certificate type (type = 0). The other devices do not support this and return an INVALID-CERT-ENCODING error. So NetScreen must be explicitly configured with type 4.

  • CA specification
    The CERT_REQ payload may optionally specify the name of the requested certificate issuer.
    • To send back its certificate, Cisco must receive either a CA-less request or a request specifying the locally-configured CA (i.e. the operational CA in our case).
    • OpenBSD has a bug which stops it when selecting the certificate to return when it receives a request without CA (happens with Nortel, and with NetScreen in default configuration).
    • Other devices don't mind and send their certificate in any case.

Certificate fields constraints

the requirements on the content of the various certificate fields are scarce:

  • OpenBSD requires peer certificates to contain one and only one subjectAltName, otherwise there is a parsing error.
  • Nortel requires the digitalSignature and keyEncipherment keyUsage, but this check can now be disabled.

Certificate Revocation Lists

The PKI used included a web server enabling the devices to download the CRLs.

The only encountered issue was the following: At first, the NetScreen box, when receiving a peer certificate, kept wanting to use LDAP to get the associated CRL and failed the certificate validation, which explains the PSK only results in the October 24 presentation. After manually inserting the operational CA's CRL into the box, it accepted the peer certificates and we could test with certificates. The only case that still does not work is when FreeS/WAN initiates to NetScreen: the NetScreen blocks at the end of phase 1.

Certificate checking (other than validity)

Besides the peer certificate validation (dates, CA signature, CRL...), the device must check that the received certificate is acceptable for the current negotiation. Indeed, if we may wish, in some cases, to simply allow any peer presenting a valid certificate to negotiate a tunnel with shared rights (road-warriors for example), it can also be desirable to check the identity of the peer so as to know which authorizations to grant him. In other words, when different peers correspond to different policies, which is mostly always the case in a VPN scenario, identity checking is required; when authentication relies on a certificate, that means taking into account the identity announced by the certificate.

The following verifications are performed by the tested devices:

  • FreeS/WAN: The content of the ID payload must be present in one of the certificates fields (DN, subjectAltName), the ID being the key that decides whether a connection is accepted and which policy is associated to it. It is possible to define an ID-less connection (i.e. any valid certificate gives access), typically to manage road warriors.
  • OpenBSD: The content of the ID payload must be equal to the subjectAltName. This verification is disabled when defining a connection without specifying the associated ID. The verification of the policies (and identifiers) is delegated to the keynote system, which enables various optional verifications.
  • Others: Unknown.

Miscellaneous issues

Lifetimes restrictions

  • Some devices (Cisco IOS, 6WIND in default configuration...) do not accept a longer lifetime than that configured. To interoperate, they thus need to be configured with the exact same lifetime.
  • FreeS/WAN's hardcoded maximum lifetime is smaller than the default lifetime proposed by some devices.

ID payload - FQDN versus DER_ASN1_DN

Some devices only support one of those two types, and sometimes it is not possible to configure what is sent. This could have caused interoperability issues, but it did not, either because this payload is not checked, or because its checking can be disabled. Indeed, when using certificates for authentication, the certificates fields are generally preferred to the ID payload for identity checking.

ID payload - Encoding of the DN

The following were noticed:

  • VPN 3000 uses a T61STRING encoding instead of the more common PRINTABLESTRING encoding for the O and CN fields. That causes an issue for FreeS/WAN when it compares it with the DN defined in ASCII format in its configuration file; we had to define the DN in binary format in the configuration file.
  • Nortel modifies the order of the RDNs in the ID payload compared to the certificate content; that was an issue for FreeS/WAN again, as it needs the correct order.

Proposal versus transform

A rather complex bug encountered during the tests and for which a workaround was found...

Symptoms

During the first tests between OpenBSD and the Cisco devices (IOS, PIX, VPN 3000), a strange bug occurred: when Cisco initiated, everything worked fine; but when OpenBSD initiated, the security association created in the Cisco -> OpenBSD way had different SPIs on the two devices. So the traffic could not flow this way.

Explanation

The phase 2 configuration on the OpenBSD side consisted in proposing two choices: (1) AES, (2) 3DES. Cisco devices only accept 3DES.

The default OpenBSD behavior in this case is to send, in the first QM message, 2 proposal payloads, each containing 1 transform payload (the more common behavior being to send 1 proposal payload containing 2 transform payloads):

17:57:53.355921 openbsd.ipsec2001.hsc.fr.isakmp> pix.ipsec2001.hsc.fr.isakmp:  [udp sum ok] isakmp v1.0 exchange QUICK_MODE
	cookie: d52e131d5f9b76f9->2eb316965f3c20ec msgid: 4755b931 len: 188
	payload: HASH len: 24
	payload: SA len: 84 DOI: 1(IPSEC) situation: IDENTITY_ONLY
	    payload: PROPOSAL len: 36 proposal: 1 proto: IPSEC_ESP spisz: 4 xforms: 1 SPI: 0x5ef2ffef
	        payload: TRANSFORM len: 24
	            transform: 1 ID: AES
	                attribute LIFE_TYPE = SECONDS
	                attribute LIFE_DURATION = 1800
	                attribute ENCAPSULATION_MODE = TUNNEL
	                attribute AUTHENTICATION_ALGORITHM = HMAC_SHA
	    payload: PROPOSAL len: 36 proposal: 2 proto: IPSEC_ESP spisz: 4 xforms: 1 SPI: 0x8f03ed24
	        payload: TRANSFORM len: 24
	            transform: 1 ID: 3DES
	                attribute LIFE_TYPE = SECONDS
	                attribute LIFE_DURATION = 1800
	                attribute ENCAPSULATION_MODE = TUNNEL
	                attribute AUTHENTICATION_ALGORITHM = HMAC_SHA
	payload: NONCE len: 20
	payload: ID len: 16 type: IPV4_ADDR_SUBNET = 10.200.0.0/255.255.0.0
	payload: ID len: 16 type: IPV4_ADDR_SUBNET = 10.198.0.0/255.255.0.0 [ttl 0] (id 1)
When the Cisco devices receive this message, they correctly select the 3DES proposal, but their answer specifies the wrong proposal number (1 instead of 2):
17:57:53.366018 pix.ipsec2001.hsc.fr.isakmp> openbsd.ipsec2001.hsc.fr.isakmp:  [udp sum ok] isakmp v1.0 exchange QUICK_MODE
	cookie: d52e131d5f9b76f9->2eb316965f3c20ec msgid: 4755b931 len: 188
	payload: HASH len: 24
	payload: SA len: 48 DOI: 1(IPSEC) situation: IDENTITY_ONLY
	    payload: PROPOSAL len: 36 proposal: 1 proto: IPSEC_ESP spisz: 4 xforms: 1 SPI: 0x10fb6346
	        payload: TRANSFORM len: 24
	            transform: 1 ID: 3DES
	                attribute ENCAPSULATION_MODE = TUNNEL
	                attribute LIFE_TYPE = SECONDS
	                attribute LIFE_DURATION = 1800
	                attribute AUTHENTICATION_ALGORITHM = HMAC_SHA
	payload: NONCE len: 24
	payload: ID len: 16 type: IPV4_ADDR_SUBNET = 10.200.0.0/255.255.0.0
	payload: ID len: 16 type: IPV4_ADDR_SUBNET = 10.198.0.0/255.255.0.0
	payload: NOTIFICATION len: 28
	    notification: RESPONDER LIFETIMESPI: 0x10fb6346
	        attribute LIFE_TYPE = KILOBYTES
	        attribute LIFE_DURATION = 00465000 [ttl 0] (id 1)
After enquiry, it appears that such a modification of the proposal number in the answer is not forbidden by the standard. Indeed, retaining the original proposition number is only a SHOULD in RFC 2408 (section 4.2 Security Association Establishment):
   When responding to a Security Association payload, the responder MUST
   send a Security Association payload with the selected proposal, which
   may consist of multiple Proposal payloads and their associated
   Transform payloads.  Each of the Proposal payloads MUST contain a
   single Transform payload associated with the Protocol.  The responder
   SHOULD retain the Proposal # field in the Proposal payload and the
   Transform # field in each Transform payload of the selected Proposal.

OpenBSD is responsible, because it should check the content of the proposal returned by Cisco:

   Retention of Proposal and Transform numbers should speed the
   initiator's protocol processing by negating the need to compare the
   respondor's selection with every offered option.  These values enable
   the initiator to perform the comparison directly and quickly.  The
   initiator MUST verify that the Security Association payload received
   from the responder matches one of the proposals sent initially.

But OpenBSD does not perform any check, and instantiates the SA (as described by Cisco, in 3DES), but with the SPI previously chosen for proposal number 1 (AES). Cisco, as for it, instantiates the SA with the correct SPI, the one from proposal number 2. Thus the SPI mismatch.

This bug was reported to OpenBSD and Cisco.

Workaround

A quick workaround is to configure OpenBSD to send only one proposal, 3DES.

It is also possible to configure OpenBSD to send its two choices in one proposal payload, containing two transform payloads (see the config file). In this case everything works normally.

NetScreen case

NetScreen uses the same approach as OpenBSD in phase 2, but uses the same SPI for both proposals. As a consequence, the SA is correctly set up, but that seems to imply that NetScreen does not verify the selected proposal either.

Transforms numbering

When Netasq sends several transform payloads, it gives them all the same number, whereas RFC 2408 imposes a strictly increasing numbering. OpenBSD and Netcelo detect this error and reject the proposal. This is a known racoon bug, which is corrected by a patch.


Config files

Disclaimer: The following are test configurations, they are not optimized and their security is not guaranteed

Last modified on 15 February 2005 at 09:45:26 CET - webmaster@hsc.fr
Information on this server - © 1989-2010 Hervé Schauer Consultants