Subject: [Hipsec] Type 1 and 2 HITs

From: Julien Laganier <[email-masked]>
Date: Fri, 29 Jul 2005 08:51:34 +0200

Folks,

Currently [I-D.ietf-hip-base] defines Type 1 HITs only:

----------------------------------------------------------------------
       0                                                          2
       0 1 2 3 4 5 6 7 8  ...                                     7
      +-+-+-+-+-+-+-+-+-+-//-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Prefix      |             Hash                           |
      +-+-+-+-+-+-+-+-+-+-//-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       Prefix (8 bits) - Fixed prefix, TBD.  All other values 
       reserved.

       0x40 - SHA-1 hash algorithm
       All other values reserved.

       Hash (120 bits) - Lower-order bits of the hash (as specified by
                 the hash algorithm) of the public key

   Additional values for the prefix (including different hash
   algorithms, or other information) may be defined in the future.  A
   host may receive a HIT for which it does not understand the prefix.
   In such a case, it will not be able to check the mapping between HI
   and HIT.
----------------------------------------------------------------------

Then, Type 2 HITs are defined in [I-D.ietf-hip-dns] as 64 bits of HAA 
followed by 64 bits of the low order bits of the hash of the public 
key.

I have the feeling that these two definitions are inconsistent because 
a node cannot determine the type of a HIT based on the HIT itself. I 
propose the following resolution:

    o In [I-D.ietf-hip-base], replace "0x40 - SHA-1 hash algorithm"
      by "0x40 - Type 1 HIT with SHA-1 hash algorithm"

    o In [I-D.ietf-hip-dns], defines Type 2 HITs as:

       0                                                          2
       0 1 2 3 4 5 6 7 8  ...                                     7
      +-+-+-+-+-+-+-+-+-+-//-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Prefix      |    HAA           |           Hash          |
      +-+-+-+-+-+-+-+-+-+-//-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       0x80 - Type 2 HIT with SHA-1 hash algorithm

       HAA (56 bits) - Host Assigning Authority supporting two levels
                       of delegation. The first is a registered
                       assigning authority (RAA). The second is a
                       registered identity (RI, commonly a company).
                       The RAA is 16 bits with values assigned 
                       sequentially by ICANN. The RI is 40 bits, also
                       assigned sequentially but by the RAA.

       Hash (64 bits) - Lower-order bits of the hash (as specified by
                        the hash algorithm) of the public key

Do you think it is sensible? or perhaps we should get rid of Type 2 
HITs...

Thanks.

--julien

_______________________________________________
Hipsec mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/hipsec

---

From: Pekka Nikander <[email-masked]>
Date: Fri, 29 Jul 2005 11:16:42 +0200

> Currently [I-D.ietf-hip-base] defines Type 1 HITs only:...
>
> a node cannot determine the type of a HIT based on the HIT itself.
>

Earlier on we had a discussion where we decided to go from encoding the
HIT type in the HIT itself external to the HIT.  The idea was that you
need to HIT type only for being able to verify the relationship between
a given HIT and a given HI public key.  That led to a design where  
Type 1
HITs were 128 bits long plain hashes.  IIRC, the rationale more-or-less
was that you would get the HIT type along with the HI public key.

Then, more recently, it became clear that for security reasons we do
need to encode the hash function into the HIT itself.  The potential
attack here is that one of the hash functions used for creating HITs
becomes weak.  If that happens, then an attacker that wants to attack
the binding with a given HIT and the intended HI could use the weak
hash algorithm to create another HI' so that HIT == weakhash(HI')
while the intended binding was HIT == stronghash(HI).

To prevent that, we have to encode the hash algorithm to the HIT
itself.

Now, consider a situation where

   Type_1_HIT == 0x40 | lowbits(120, stronghash(HI))

Consider an attacker that creates a Type 2 HIT so that

   Type_2_HIT == 0x40 | HAA | lowbits(64, stronghash(HI'))

where HAA = highbits(120-64, lowbits(120, stronghash(HI))

In this scenario the attacker only needs to create a public key
HI' whose hash has only same low order 64 bits and not 120 bits
than the HIT being attacked.  That is clearly something that we
do not want to have.

Hence, I think you are right.  We need to have another code point
for the different encoding of the hash in the Type 2 HITs.

In general, it looks like that we need to encode in the HIT itself
the exact method that was used to generate the hash of the public
key in the HIT.

Now, this goes back to the discussion whether to divide the first
byte in the HIT into two fields, one being fixed for now ("This is
a HIT" and not an IPv6 address) and the other creating a new IANA
registry, for easier definition of new hash encodings.

As I have stated before, I still think that instead of defining
a single 8-bit prefix (to be allocated from the IPv6 address space)
it is probably a better idea to have an e.g. 5-bit prefix and then
have initially 3 bits (8 choices) for encoding the hash.

--Pekka