[Hipsec-rg] Key Revocation Issue
thomas.r.henderson at boeing.com (Henderson, Thomas R) Fri, 30 January 2009 18:11 UTC
From: "thomas.r.henderson at boeing.com"
Date: Fri, 30 Jan 2009 10:11:49 -0800
Subject: [Hipsec-rg] Key Revocation Issue
In-Reply-To: <001901c97b9a$1c233820$480c6f0a@china.huawei.com>
References: <001701c97b77$5c494480$480c6f0a@china.huawei.com> <001901c97b9a$1c233820$480c6f0a@china.huawei.com>
Message-ID: <77F357662F8BFA4CA7074B0410171B6D07B0BD39@XCH-NW-5V1.nw.nos.boeing.com>
> -----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
- [Hipsec-rg] Hierarchical HITs Xu Xiaohu
- [Hipsec-rg] 答复: Key Revocation Issue Zhang Dacheng
- [Hipsec-rg] Key Revocation Issue Henderson, Thomas R
- [Hipsec-rg] re: 答复: 答复: Key Revocation Issue Xu Xiaohu
- [Hipsec-rg] 答复: 答复: Key Revocation Issue Andrew McGregor
- [Hipsec-rg] 答复: 答复: Key Revocation Issue Zhang Dacheng
- [Hipsec-rg] 答复: Key Revocation Issue Scott Brim
- [Hipsec-rg] 答复: Key Revocation Issue Zhang Dacheng
- [Hipsec-rg] Hierarchical HITs JiangSheng 66104
- [Hipsec-rg] Key Revocation Issue Oleg Ponomarev
- [Hipsec-rg] Hierarchical HITs Oleg Ponomarev
- [Hipsec-rg] 答复: Key Revocation Issue Zhang Dacheng
- [Hipsec-rg] 答复: Key Revocation Issue Zhang Dacheng
- [Hipsec-rg] Key Revocation Issue Miika Komu
- [Hipsec-rg] Key Revocation Issue Zhang Dacheng
- [Hipsec-rg] 答复: Hierarchical HITs Zhang Dacheng
- [Hipsec-rg] 答复: Hierarchical HITs Teemu Koponen
- [Hipsec-rg] Hierarchical HITs JiangSheng 66104
- [Hipsec-rg] Hierarchical HITs Oleg Ponomarev
- [Hipsec-rg] 答复: Hierarchical HITs Zhang Dacheng
- [Hipsec-rg] Hierarchical HITs JiangSheng 66104
- [Hipsec-rg] Hierarchical HITs Julien Laganier
- [Hipsec-rg] Hierarchical HITs Julien Laganier
- [Hipsec-rg] 答复: Hierarchical HITs Julien Laganier
- [Hipsec-rg] Hierarchical HITs Oleg Ponomarev
- [Hipsec-rg] 答复: Hierarchical HITs Sheng Jiang
- [Hipsec-rg] 答复: 答复: Hierarchical HITs Sheng Jiang
- [Hipsec-rg] 答复: Hierarchical HITs Sheng Jiang
- [Hipsec-rg] Hierarchical HITs Oleg Ponomarev
- [Hipsec-rg] Hierarchical HITs (Was: reverse DNS l… JiangSheng 66104
- [Hipsec-rg] Key Revocation Issue Zhang Dacheng
- [Hipsec-rg] Key Revocation Issue Henderson, Thomas R