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

[Avesh Agarwal]

On 01/05/2010 01:38 PM, Paul Wouters wrote:
> 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?
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.

That said, I looked at the RFC that says:

(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.

In addition it says

(3.16 Vendor ID Payload, page 43) "There are no security implications of 
this hash, so its choice is arbitrary."

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.

>
>>> 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?
>
The main issue is calling md5 algo calls.

>>> 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.
>
I also feel that is a bad way of implementation.

Thanks and Regards
Avesh

> Paul