[Openswan dev] nss/nspr4 warning and PLUTO_SENDS_VENDORID vs HAVE_LIBNSS
paul at xelerance.com
Tue Jan 5 14:06:00 EST 2010
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
> (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
>> 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.
More information about the Dev