Subject: [Hipsec] Basic question about HIP

From: [email-masked] (Henderson, Thomas R)
Date: Thu May 6 10:54:01 2004

> -----Original Message-----
> From: marcelo bagnulo [mailto:[email-masked]]=20
> Sent: Thursday, May 06, 2004 1:58 AM
> To: Henderson, Thomas R
> Cc: [email-masked]
> Subject: RE: [Hipsec] Basic question about HIP
>=20
>=20
> Hi Thomas,
>=20
> thank you very much for answer.
>=20
> I would like to pose an additional question related to this...
>=20
> [...]
>=20
> > However, operationally, it may be that people use
> > HITs as the identifiers themselves, relying on the
> > self-certifying property that it is not computationally
> > feasible to produce a matching HI given the HIT.
>=20
> Well, there is something about this point that puzzles me,=20
> probably because
> my lack of knowledge related to this issues, but wouldn't the=20
> fact that the
> HIT is fixed to 128 bits may affect this property in the=20
> future? I mean,
> AFAIK, as the computational power increases, the length of=20
> public keys has
> to be increased in order to preserve the security provided.=20
> However, in the
> case of the HITs, the length is fixed, so it won't be=20
> possible to increase
> its length.

I think that it may be possible to increase the HIT size in
the future, if needed, although it may possibly incur as much
pain as IPv4 to IPv6 is causing now.  It is probably to
be avoided.

> So, even if today it is not computationally feasible to=20
> 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?
>=20

Offhand, I do not know what the timeframe is before this=20
self-certifying property is lost.  My guess is that it would
be a long time.  However, in such a case, you would lose the=20
masquerade protection and would need to do a reverse lookup
if you wanted to fully authenticate the HIT.  That, I believe,
was one reason behind the so-called Type 2 HITs that have the
top 60 or so bits allocated to a Host Assigning Authority--=20
to enable reverse lookups.  Even in such as case, one would
not lose the ability to use type 1 HITs for opportunistic
security.  Furthermore, there is mechanism in the protocol to
support an initiator sending a certificate to back up the
host identity.  So it is not clear how this would evolve
exactly in such a case, but there seem to be a couple of
options.

But, as Pekka suggested, one should try to use the public key=20
itself if identification is needed, even today.  Miika Komu has=20
been studying how we might transition from using the HITs in API=20
calls to using the host identities, and I see that he already=20
replied too.

> > In
> > that case, it seems that a vulnerability is possible
> > if the HI is not consulted or traced back to a trusted
> > authority (e.g., an ACL based solely on HITs).
>=20
> Considering that current IPv6 applications use 128 bit long=20
> strings (IP
> addresses) as endpoint identifiers, so it would be natural=20
> 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=20
> the HI. So, i
> can see the usage of the HIT as a transition tool. But in the=20
> long term goal
> is that applications will use the HI or HIT?
>=20
> In brief, is it recommended that future apps use the HIT or the HI?
>=20

Well, I would say "not the HITs".  Whether the apps would use HIs=20
directly or something else is an open research area.

Tom