[Hipsec-rg] 答复: Key Revocation Issue

[zhangdacheng at huawei.com (Zhang Dacheng)]

Hi:

DNS server cannot directly be used to help a user holding a antique HIT
access the host whose HIT has been changed, unless the user has got the FQDN
(by reverse DNS lookup of HITs maybe) in advance. Additional authentication
processes are needed too, and so DNS can guarantee only the owner of a HIT
can modify its result.

Another concern is that should we assume that every host using HIT should be
registered with DNS?





> 
> Zhang Dacheng wrote:
> 
> Hi,
> 
> > Hello everyone:
> > 
> > When reading IETF HIP related documents, I found there were 
> still lots 
> > of things left for us to explore in the key revocation 
> issues. Because 
> > of security reasons, the cryptographic key held by a host normally 
> > should be changed after being used for a certain period. In 
> this case, 
> > the HIT needs to be changed too.
> > 
> > Assume there is a host, A, which has changed its HIT. It may be not 
> > practical for A to notify all the hosts which hold the old HIT of A 
> > about the change, and this can cause several problems. For example, 
> > when A attempts to use the new HIT to access a server which 
> uses the 
> > old HIT of A in its ACL, the request may be rejected. In 
> addition, a 
> > user holding the old HIT will find it is very difficult (if 
> it is possible) to locate A.
> > Therefore, I think there should be a third party in the HIP 
> > architecture to provide the mapping service between the old 
> HITs and 
> > the associated new HITs. Currently, I am thinking whether 
> it is a good 
> > way to achieve this objective by extending the functionality of 
> > Rendezvous servers. DNS can also be a candidate.
> > 
> > What do you think about it? Hope to get your comments.
> 
> what about just changing the HI record of the FQDN? Of 
> course, this does not solve the problem with static ACLs.