Subject: Re: Nortel Contivity Linux Client
To: Matt Thomas <matt@3am-software.com>
From: Thor Lancelot Simon <tls@rek.tjls.com>
List: port-i386
Date: 07/22/2003 16:31:30
On Tue, Jul 22, 2003 at 09:19:48AM -0700, Matt Thomas wrote:
> 
> On Tuesday, July 22, 2003, at 07:38 AM, Brian Hechinger wrote:
> 
> >does it run under netbsd linux emulation?  i'd like to use it, but 
> >have no
> >real interest in putting linux on my laptop.
> 
> I've been wondering how hard it would be to get racoon and NetBSD to 
> support talking to Contivity directly.  [My employer uses it too.]

Nortel violates the IKE spec in some fairly basic ways -- in particular,
they compute HASH_I/HASH_R or SIG_I/SIG_R in a nonstandard, undocumented
way and use nonstandard PKCS padding when using RSA signatures.  They
also reencode X.509 identites in a way that makes them not match what
most other implementations expect, making it impossible to do meaningful
identity checking with most implementations as the peer (of course, since
many installations stupidly use "signed by this CA" as the policy where
they should use "signed by this CA and matching this identity" this is
not, perhaps, so important, so long as one does not care about security).

There are some hints as to what they've done in obsolete IETF submissions by
companies they bought, but they've repeatedly changed at least the HASH/SIG
computation after others have managed to interoperate with it.

I'm sure you're also aware that there are serious security issues involved
with the use of XAUTH, particularly the way the Connetivity used it last
time I was involved with an effort to make an IKE implementation 
interoperate with the Nortel products.  All in all, I'd say that calling
the Nortel implementation "IKE" borders on false advertising; if at all
possible, I consider "run away!" the best policy.

It is my personal suspicion that the Nortel product diverges so 
substantially from standard IPsec *as a deliberate way of ensuring that
customers can not migrate to other VPN/IPsec implementations without
severe pain*; bearing this out one might note that most of their
"client" implementations seem to go out of their way to make it difficult
or impossible to keep another IPsec implementation present on the system
at the same time and switch back and forth...

Thor