[Openswan dev] nss/nspr4 warning and PLUTO_SENDS_VENDORID vs HAVE_LIBNSS

[Paul Wouters]

On Tue, 5 Jan 2010, Avesh Agarwal wrote:

>> You cannot change it, as the *other* IPsec implementations send vendorids
>> using the md5sum.

> How does it know if that operation is cryptographic or non-cryptographic (in 
> other words security related or non-security related). When using NSS it just 
> disables or enables usage of algorithms based on FIPS or non-FIPS mode.

Ok, so that means we would have to pre-compute the hashes, or we could
create a vendoridmd5() function that is only used there, which can be
part of libopenswan, so that we can use md5, but only for that specific
non-security context.

> (3.16 Vendor ID Payload, page 42) "An implementation is NOT REQUIRED to 
> understand any Vendor ID payloads. An implementation is NOT REQUIRED to send 
> any Vendor ID payload at all.

Yes, but a lot of interop will fail if you don't recognise and/or act on
vendorids. Remember NAT-T detection and XAUTH are stuffed into vendorids.

> So I feel that if we do not want to change md5 hashes, another way is to 
> avoid sending and recognizing vendor id during IKE negotiation when the 
> system is in FIPS mode.

That would severely cripple and downgrade openswan.

>> Alternatively, we could run the md5 on the version in our release script,
>> and generate a custom header of field with the md5 sum, so that the code
>> does not have to run an md5() call, but honestly, I find that really a 
>> silly
>> obfuscation that should not be needed.
>> 
> I also feel that is a bad way of implementation.

We could also change the vendorid of openswan to make sense in a textual
representation, eg just "Openswan a.b.c". Still, I think we also define
some macros calling md5 in determing some of the incoming vendorid payloads.

Paul