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

[Ari Keranen <[e-mail]>]

Henderson, Thomas R wrote:
>> -----Original Message-----
>> From: Ari Keranen [mailto:[e-mail]]
>> Sent: Thursday, February 25, 2010 11:00 PM
>> To: Henderson, Thomas R
>> Cc: 'Gonzalo Camarillo'; HIP
>> Subject: Re: [Hipsec] WGLC: draft-ietf-hip-reload-instance-00
>>
>> 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.
>>
> 
> I think we should really explore this idea more but let's do so in the more RFC4423bis context as discussed in the other thread.  I wasn't objecting to the idea per se, but just that we should not slip it into this draft if it is not really recognized as a part of HIP today.

Actually, we used to have a milestone about this in the charter, but it 
was removed last July when the WG's conclusion was that transformations 
would be context specific. So, this already is recognized as part of the 
HIP today.

> I see pros and cons to non-ORCHID HITs:
> - pro:  can be designed to be hierarchical or formatted as needed.  Can they even be IPv6 addresses?
> - con:  HITs are no longer unique.  It is really the certificate which is the unique identifier.
> It does seem more flexible and may have deployment advantages.  Does it solve the ACL problem with current HITs (that they are non-aggregatable)?  It could lead to aggregatable HITs but then the ACL will need to know the authorizing enrollment server for those HITs, and check CERTs.

These questions are good to be explored on RFC4423bis, but we don't need 
the answers to proceed with the RELOAD instance spec, so I would not 
delay the instance spec by making it depend on RFC4423bis.

Anyhow, we are not changing anything fundamental in HIP, and having this 
property we can make HIP meet the different requirements that people 
building overlays have.


Cheers,
Ari