[Hipsec] HI Parameter (was: HIP parameters critical flag)

[Tobias Heer <[e-mail]>]

Hi Jeff, 

Am 12.01.2010 um 20:56 schrieb Ahrenholz, Jeffrey M:

>> Again, I'd say make the value 715 if you plan to include it 
>> in ENCRYPTED, otherwise you may want to leave that value open 
>> for future parameters to be included in ENCRYPTED.
> 
> looking more carefully at that previous message, I guess there is no ENCRYPTED in the I1 packet that will include this info:
> 
>  "I1 packet has to be modified to include the hash, public keys and
>  diffie-hellman algorithms supported by the Initiator in a new "algo"
>  parameter.  The parameter should indicate which hash and public key
>  algorithm the Initiator used to generate its HIT."
> 
> -Jeff
> _______________________________________________
> Hipsec mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/hipsec

The purpose of the HIH parameter is to convey which hash function was used to generate the HIT used by a host. It is needed to verify the relation between HI and HIT because multiple algorithms. As far as I can see, there are four options to transfer the information:

a) as part of the HIT 
   - this option takes bits from the HIT that could otherwise be used for cryptographic purposes. It raised serious concerns about security and extendability.

b) as part of the HIP header (close to the HIT itself)
   - this would make sense from a conceptual point but the information is only needed when verifying the HI/HIT relationship. Putting it into every packet would be overkill.

c) as part of the HI parameter
   - this would make sense from a usage point of view but conceptually, the HIH is not part of the HI. Mixing these two might confuse people. Depending on the HIT in the HIP header, different HIs would be used.

d) as extra parameter
   - this provides a distinction between HOST_ID and HIH. However, the space requirements for an own TLV are slightly higher than for options a, b, and c.

I agree that c) and d) are valid and (in my opinion) good options.
 
In which packets do we need the HIH parameter? In my opinion, we need the parameter in all packets that may trigger a verification of the HI-HIT relationship. This means R1 and I2 during the BEX. In general every packet that contains a HI should probably have a HIH parameter. However, I am not sure if there are any extension for which this rule of thumb fails.



The list that Bob mentions is not necessarily a collections of HIH parameters. The HIH contains an index to the hash function used, the list contains several indexes. The list could be a separate parameter to avoid confusion and context-sensitive interpretation of the HIH. I will include some thoughts about crypto agility for the HIH below. The following text contains some thoughts for a BEX in which the Initiator does not know the HIHs supported by the Responder before the BEX:



     The Initiator initiates the BEX with an I1 packet. The
     Initiator picks source HIT and HIH based on local policies.

     The Responder responds to the I1 with an ordinary R1 with the
     exception that the R1 contains a list of supported HIH hash
     functions in the signed part of the R1.

     When receiving the R1, the Initiator verifies the signature
     in the R1 packet. If the signature is valid, it looks at the
     list of HIHs. If the previously selected initiator source HIT
     is amongst the supported HIHs, the Initiator continues with
     an I2 packet. If not it may restart the BEX with an I1 and a
     different source HIT.

     An attacker could try to launch a downgrade attack here but
     this will not be successful. I will explain the attack anyway.
     The attacker could store a old R1 message containing a HIH list 
     with weak algorithms and replay it to the initiator even if the
     Responder upgrades its algorithms to stronger ones. The initiator
     would restart its BEX after receiving this replayed R1 - using the
     weaker algorithms. It sends a new I1 with a weaker HIT. So far the 
     attack seems to be working. The next step is where it fails. The
     Responder will send an R1 message as response to the weaker source
     HI in the I1. This fresh R1 contains the HIH list (with the stronger
     algorithms) in the signed part of the packet, thereby revealing
     the attack. Moreover, the R1 counters will not match (huge gaps).
     This can even be noticed by security middleboxes.

     If the Attacker would decide to continue replaying the old R1
     to the new (downgraded I1), the initiator would send a I2 with
     an invalid R1 counter and a wrong HMAC because the DH public
     key in the replayed R1 are not valid any more. -> No successful
     downgrade due to the list in the R1.

I hope this gives enough context to understand my perception of the HIH parameter and the need for the HIH list.

Best regards, 

Tobias









--  

Dipl.-Inform. Tobias Heer, Ph.D. Student
Distributed Systems Group 
RWTH Aachen University, Germany
tel: [phone]
web: http://ds.cs.rwth-aachen.de/members/heer