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

[Paul Wouters]

On Tue, 5 Jan 2010, Avesh Agarwal wrote:

> I looked into this, and the reason for not to send vendorid during FIPS mode 
> is that it computes MD5 hashes on the vendorid, and MD5 should not be allowed 
> in FIPS mode.

But md5 here is not used as a security issue. It is used so that the vendorid
payload is of a fixed size. Other payloads in IKE are defined by the IETF,
so they have reference numbers registered at IANA that are used in the
payloads. Vendor ID's dont have such a central registration. If you look at
vendor.c and vendor.h you will see most vendors use longer strings to
identify their model and version number, and then hash it to get it down to
a fixed length. md5 is used as "compression" only.

For example, the vendor id for "CISCO-UNITY" is:

md5('CISCO-UNITY') = 12f5f28c457168a9702d9fe274cc02d4

The vendorid 'NATT_IETF_00' is md5("draft-ietf-ipsec-nat-t-ike-00")

These are not "secrets" or "encrypted" information.

> As FIPS or non-FIPS mode can be setup at "run time", I coded it 
> in the way so at run time, the sending of vendor id can be enabled and 
> disabled depending upon non-FIPS mode or FIPS mode.

What I see now is that we should send the vendorid regardless of FIPS mode.

> If you do it at compile time like you did above then, even during non-FIPS 
> mode, it is not possible to send vendor id which should be allowed.

Changing sending the vendorid from a compile time to a runtime option is
something we can implement, but I see it as a seperate issue from FIPS.

> And the reason that it does not compile with USE_VENDORID=false is not due to 
> HAVE_LIBNSS. The problem is there even if you do not have HAVE_LIBNSS 
> enabled.

That is right, and it got fixed seperately.

Thanks for the clarification of your patch. To sumarize, since the use of
md5 here is not done in any security context, I believe we do not require
to change our behaviour based on FIPS mode.

Paul