Re: [Hipsec] Implementation questions from students

[Jeff Ahrenholz <[e-mail]>]

Hi Andrei et al.,

Some inline comments below...

> We had some questions about the HIP project that you could perhaps forward to the correct person:
> 1. In the function build_tlv_hmac() in src/protocol/hip_output.c, there is the following bit of code:
> /* get lower 160-bits of HMAC computation */
> memcpy( hmac->hmac,
>         &hmac_md[hmac_md_len - sizeof(hmac->hmac)],
>         sizeof(hmac->hmac));

We currently use the HMAC() function writing directly into the TLV buffer. We're not truncating the output hash when using AES-256.

> Also, per RFC 7401 (HIPv2), "The size of the HMAC is the natural size of 
> the hash computation output depending on the used hash function". Thus 
> there does not seem to be a need to truncate this value to 160 bits?
>  At least one implementation (https://www.cryptosys.net/manapi/api_kmac.html)
> of the KMAC function (that we have added as an option to HMAC) also states
> that the output of the KMAC function cannot be truncated when used as a message authentication code.

This likely stems from the original RFC 5201 / RFC 5202 required algorithms. You're correct, with AES-256 and others you do not need to truncate the output hash. Although that is allowed by old RFCs such as RFC 2104.

> There is a fallback in hi_to_hit() which silently uses SHA256 as
> the hashing algorithm for creating a HIT from a HI if the HIT suite 
> is set to an invalid value, which enables the verification to succeed 
...
> We have worked around this issue by first ignoring all parameters 
> other than the HIT_SUITE_LIST (thus ensuring that the HIT suite 
> variable is set before any other parameters are parsed), then continuing
> with parsing the signature-related parameters and finally the others. 
> Is this an acceptable solution to this problem? Those silent fallbacks 
> seem to cause more problems that they solve, maybe they should be removed
> or at least emit a warning when triggered?

Yes, I think you should remove the silent fallback.

You should be able to use the OGA ID field of the HIT in order to validate the HIT.
From RFC 7401 section 3.1:

"  One of these
   measures allows different hash functions for creating a HIT.  HIT
   Suites group the sets of algorithms that are required to generate and
   use a particular HIT.  The Suites are encoded in HIT Suite IDs.
   These HIT Suite IDs are transmitted in the ORCHID Generation
   Algorithm (OGA) field in the ORCHID.  With the HIT Suite ID in the
   OGA ID field, a host can tell, from another host's HIT, whether it
   supports the necessary hash and signature algorithms to establish a
   HIP association with that host."

The HIT_SUITE_LIST TLV is used to list the supported HIT SUITE IDs.

See RFC 7401 section 5.2.10 around this text:

"   The ID field in the HIT_SUITE_LIST is defined as an eight-bit field,
   as opposed to the four-bit HIT Suite ID and OGA ID field in the
   ORCHID."

I don't think you should parse the HIT_SUITE_LIST when validating the HIT.

> Seeing as this function will then sometimes calculate a HMAC and other
> times a KMAC, should it be renamed to build_tlv_mac()? Or will it be
> less intrusive to others (that might be used to the name) to not
> change it even though the name might be misleading? 

The new name build_tlv_mac() sounds good.

regards,
-Jeff