 |
|
||||
|
 |
 |
|||
|
|
||||||||||||
|
|||||||||||||
|
|||||||||||||
|
|||||||||||||
|
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:
Course of events
This demonstration was conducted as follows:
Participants
 The list of participating devices is:
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:
 Phase 1 parameters:
Phase 2 parameters:
We suggest testing the following situations:
Test results
The following table sums up the results obtained on 5 November 2001:
Legend:
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.
For all the green cells above, we found a configuration for which:
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:
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:
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:
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:
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:
Certificate fields constraints the requirements on the content of the various certificate fields are scarce:
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:
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:
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. 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 |
|
]![[Techno-watch]](/gif/icone.veille.png){kind=small}
]
]
![[Theme]](/gif/icone.theme.png){kind=small}
