Subject: [Hipsec] Basic question about HIP

From: [email-masked] (Henderson, Thomas R)
Date: Wed May 5 16:57:01 2004

Marcelo,
I'm not aware of a detailed analysis of this risk.  It is=20
discussed a bit in the HIP architecture draft=20
(http://hip.piuha.net/drafts/) in Section 3.3.

HITs are operational representations of Host Identifiers.
The assumption in the architecture draft is that HITs are
statistically unique but not guaranteed to be so, and
that the Host Identifier (probably authenticated by some
third-party service or infrastructure like X.509) is
the final proof of identity.

However, operationally, it may be that people use
HITs as the identifiers themselves, relying on the=20
self-certifying property that it is not computationally
feasible to produce a matching HI given the HIT.  In
that case, it seems that a vulnerability is possible
if the HI is not consulted or traced back to a trusted=20
authority (e.g., an ACL based solely on HITs).

Tom

> -----Original Message-----
> From: marcelo bagnulo [mailto:[email-masked]]=20
> Sent: Wednesday, May 05, 2004 10:18 AM
> To: [email-masked]
> Subject: [Hipsec] Basic question about HIP
>=20
>=20
> Hi,
>=20
> I was wondering which are the risks vulnerabilities by a=20
> collision of HITs.
> I mean, suppose that a user U has his public key PKu and his=20
> hit is HITu =3D
> hash(PKu)
> Suppose that another user A finds another key PKa which hash=20
> collides with
> the previous one,
> i.e. HITa=3Dhash(PKa)=3D hash(PKu)=3DHITu
> would this allow A to perform some sort of attacks to U or to=20
> another party?
> I am sorry if this topic has already been discussed before,=20
> if this is so i
> would appreciate a pointer to previous discussion/documents)
>=20
> Thanks, marcelo
>=20
> _______________________________________________
> Hipsec mailing list
> [email-masked]
> http://honor.trusecure.com/mailman/listinfo/hipsec
>=20

---

From: [email-masked] (marcelo bagnulo)
Date: Thu May 6 04:11:04 2004

Hi Thomas,

thank you very much for answer.

I would like to pose an additional question related to this...

[...]

> HITs as the identifiers themselves, relying on the
> feasible to produce a matching HI given the HIT.

Well, there is something about this point that puzzles me, probably because
my lack of knowledge related to this issues, but wouldn't the fact that the
HIT is fixed to 128 bits may affect this property in the future? I mean,
AFAIK, as the computational power increases, the length of public keys has
to be increased in order to preserve the security provided. However, in the
case of the HITs, the length is fixed, so it won't be possible to increase
its length.
So, even if today it is not computationally feasible to produce a HI that
matches with a HIT, would this remain so from 20 years from now?
And if this happens, how would HIP will be affected?

> In
> if the HI is not consulted or traced back to a trusted

Considering that current IPv6 applications use 128 bit long strings (IP
addresses) as endpoint identifiers, so it would be natural for them to use
HITs as endpoint identifiers. I guess that during the first period of
adoption of HIP, HITs will be used as identifiers instead of the HI. So, i
can see the usage of the HIT as a transition tool. But in the long term goal
is that applications will use the HI or HIT?

In brief, is it recommended that future apps use the HIT or the HI?

Regards, marcelo

> > From: marcelo bagnulo [mailto:[email-masked]]
> > I was wondering which are the risks vulnerabilities by a
> > collision of HITs.
> > I mean, suppose that a user U has his public key PKu and his
> > hit is HITu =
> > hash(PKu)
> > Suppose that another user A finds another key PKa which hash
> > collides with
> > the previous one,
> > i.e. HITa=hash(PKa)= hash(PKu)=HITu
> > would this allow A to perform some sort of attacks to U or to
> > another party?
> > I am sorry if this topic has already been discussed before,
> > if this is so i

---

From: [email-masked] (Miika Komu)
Date: Thu May 6 08:59:00 2004

> In brief, is it recommended that future apps use the HIT or the HI?

I see the HIT (and LSI too) as transition tools. In fact, I think I
referred to the API scheme that uses the HITs and LSIs as "legacy API"
in some earlier discussion on this list.

It would seem much nicer to have the whole HI in the application to avoid
collisions and allow some modularity in the HIP protocol if the length of
the identifiers need to be changed in the protocol itself some day. This,
however, requires some changes in the apps... and eventually a new API.

I have implemented such an API (called "native HIP API") and it works. I
also ported an example application (v6 telnet) to use the API and it works
fine too. The native HIP API has a new resolver (HIP counterpart for
getaddrinfo) and a nice way to hide the ugly details of HIs and locators.
But I would rather postpone the discussion of this topic to June when I am
finally going to release the documentation for public consumption and we
will have a more solid base for discussion.

-- 
Miika Komu              [email-masked]          http://www.iki.fi/miika/