[strongSwan] Options available for using a certificate hierarchy or chain

[Graham Hudspith]

Hello All,

We've been using strongSwan as our IPsec solution for a while now (thanks to
Martin, Andreas and everyone else who has helped us get this far!).

However, we've come up against a problem trying to implement the certificate
hierarchy designed by our device-security guys.

They've come up with a four-certificate chain solution, i.e. self-certified
root CA -> class CA -> group CA -> device certificate.

Unfortunately, when I set up one of our devices to use this chain (i.e. root
CA on the SeGW, class and group CAs and device certificate on the device),
the tunnel is set up fine, but during the initial IKE_AUTH packet sent from
the device to the SeGW, the amount of certificate data sent is so large that
IP fragmentation kicks in and three IP fragments are sent.

We've been warned by our SeGW partners that most SeGWs will not accept IP
fragments due to the security risk and that we need to trim back the data
sent to make everything fit inside one IP packet. This matches up with one
of the answers given in the strongSwan FAQ.

Our PKI guys are incredulous about this situation. They wonder "how have the
IPsec standards managed to get into this situation ?".

Can anyone suggest any solutions ?

I see that hash-and-url is one proposed solution, and although it is
implemented by strongSwan, does anyone have a feel for how widespread that
is among other IPsec SeGW implementations ?

The PKI guys have grudgingly agreed to cut out one level of CA from the
chain, but this would still involve sending one CA plus the device
certificate across in the IKE_AUTH packet, and that would still involve IP
fragmentation.

Another solution would be to preload the intermediate CAs onto the SeGW (as
well as our root CA). This works in our lab, when we also use strongSwan as
a test SeGW, but I've been informed that most of our customers would NOT be
interested in this solution. They want to load ONE root CA onto their SeGW
and nothing else.

Are there any options left ?

Thanks,

Graham.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/users/attachments/20100513/3a8cf634/attachment.html>