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

[Paul Wouters]

On Tue, 5 Jan 2010, Avesh Agarwal wrote:

>> 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.
>
> Hi Paul,
>
> I understand it. The only reason is that md5 calls will not be enabled when 
> in FIPS mode, as that is not an alllowed algorithm as per FIPS requirements. 
> can it be chanaged to SHA1 then?

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

Please tell me exactly where it states that md5 cannot be used in FIPS for
non-cryptographic operations?

>> 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.
>
> Actually if we can still send the vendor id in FIPS mode (may be by using 
> SHA), then there is no option required as it will be sent in any case.

We could do that, but it would introduce two issues:

- Older versions of openswan will not recognise newer versions of openswan
   (now this is only a logging issue, as no decisions are made based upon
    the vendorid by Openswan. Other implementations might differ though)
- We would get a repeat issue when SHA1 is dropped, or later on SHA256.
   I would also have to look at the vendorid payload specification to see if
   a SHA256 hash would fit in the IKEv1 and IKEv2 payload.

> As 
> currently it is using md5, thats why I used the option to disable it in FIPS 
> mode. If you see the code that I have put the code under Pluto_IsFIPS calls 
> which check whether the system is in FIPS mode nor not.

So am I right that your only issue right now is the md5() call to generate
our own vendorid based on version? Not the receiving or recognising of
other vendorids we receive?

>> 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.
>> 
> Same as above, can we then change it to SHA1 or something else?

I'd still prefer to not need to change that behaviour. If we want to change
to SHA256, we need to check the payload specification.

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.

Paul