Re: [Hipsec] WGLC: draft-ietf-hip-reload-instance-00

[Ari Keranen <[e-mail]>]

Henderson, Thomas R wrote:
>>> When you say "In the other Peer ID mode, namely "RELOAD",..."
>>> which case do you mean?  Just the self-generated case?  If it is
>>> the centralized case, the Node IDs can't be used as HITs, and
>>> then the Node IDs and the HITs are not related to one another and
>>> need to be bound by some kind of certificate framework.  This is
>>> what I think section 5.6.1.1 of the base draft refers to.  Or am
>>> I misunderstanding something?
>> We mean both cases.  I'm sorry but I don't follow why couldn't the 
>> non-ORCHID Node IDs be used as "HITs" (i.e., in the HIP header, VIA
>>  lists and certificates) in the centralized case?
>> 
> 
> Let's say that the enrollment server allocates the first node the
> Node ID of "0", the second node a Node ID of "1" etc.  Are you
> suggesting that these values are used as HITs?

Yes. Although the enrollment server would not really give IDs like that 
but rather make them cryptographically random, but the point remains the 
same: the IDs in the RELOAD mode are not (necessarily) hashes of public 
keys.

> I raised this issue in another thread yesterday, but it seems to me
> that a central idea in the HIP architecture is that the HIT is the
> hash of the public key of a public/private key pair and that the host
> holds the private key.  I don't believe we've talked before about the
> possibility that the HI and HIT are not related cryptographically.

Yeah, we had a thread on the HIP list about this some half a year ago 
but it died away. I admit that the HIT being a hash of a public key is 
somewhat central idea in HIP, but is it really necessary if you have a 
certificate that can provide the same binding between the non-HIT-ID and 
Host ID?

AFAIK, you only lose the property that for someone else it's really hard 
to generate the same identity, but with an enrollment server that would 
not be a problem thanks to the certificates. Without an enrollment 
server one could fake the ID in the RELOAD mode, but then you can still 
use the ORCHID mode and real HITs or generate IDs as digests (SHA-1 or 
SHA-256) of the public key as the RELOAD draft proposes.


Cheers,
Ari