[Hipsec-rg] Key Revocation Issue

[thomas.r.henderson at boeing.com (Henderson, Thomas R)]

 

> -----Original Message-----
> From: Zhang Dacheng [mailto:zhangdacheng at huawei.com] 
> Sent: Tuesday, January 20, 2009 11:30 PM
> To: hipsec-rg at listserv.cybertrust.com
> Subject: [Hipsec-rg] Key Revocation Issue
> 
> 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.
> 
Hi Dacheng,

I didn't respond earlier to your post but I don't really have anything
much to add to my previous comments that ACLs probably shouldn't be
HIT-based:
https://listserv.cybertrust.com/pipermail/hipsec-rg/2009-January/000581.
html

If your use case is that HITs are changing, all the more reason to not
base the ACLs or application stable names as HITs.  So, I'm not sure a
new third party is necessary (we already have the DNS).

- Tom