[Hipsec-rg] Key Revocation Issue

miika.komu at hiit.fi (Miika Komu) Wed, 21 January 2009 08:04 UTC

From: "miika.komu at hiit.fi"
Date: Wed, 21 Jan 2009 10:04:54 +0200
Subject: [Hipsec-rg] Key Revocation Issue
In-Reply-To: <001901c97b9a$1c233820$480c6f0a@china.huawei.com>
References: <001901c97b9a$1c233820$480c6f0a@china.huawei.com>
Message-ID: <4976D726.5020508@hiit.fi>

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.