[Hipsec-rg] re: 答复: 答复: Key Revocation Issue
xuxh at huawei.com (Xu Xiaohu) Fri, 23 January 2009 04:06 UTC
From: "xuxh at huawei.com"
Date: Fri, 23 Jan 2009 12:06:23 +0800
Subject: [Hipsec-rg] re: 答复: 答复: Key Revocation Issue
In-Reply-To: <24C851CC-4CB6-4E6F-9A5A-E418F4B1EBE4@indranet.co.nz>
Message-ID: <001b01c97d0f$f4cc2210$670c6f0a@china.huawei.com>
Hi Andrew, > It isn't reasonable to assume that each host is associated > with a FQDN (unless we make it so, for instance by > constructing said FQDN out of the HIT), for the majority of > devices. For example, is my cellphone associated with an > FQDN? If so, is that FQDN at all useful for access, > identification or authorisation? Probably not, since it is > under the control of the cellphone carrier; they might be > able to use it for some of those purposes, but I can't. > > I believe it to be a design goal of HIP that it should be > useful without connectivity to the DNS; DNS record formats > and packets may be useful, but HIP itself should not require > that any host have an FQDN nor any ability to do DNS queries > (except perhaps by querying its immediate HIP peers... and > even then, only for information about those peers themselves, > in zeroconf style). Thanks for your comment and I agree with your opinion. When source host got the HIT of the destination host, the HIT needs to be resolved to locator through some id/locator mapping system. If the HIT has no organizational structure, who will run this mapping system? Isn't it lack of business incentive or security/trust boundary? Xiaohu > > Hi, > > > > I absolutely agree that FQDNs cannot directly be used for session > > authentication etc. But we need to clarify that the original > > objective of designing HIP is separation of IDs and locators rather > > than security. I agree security is an important > functionality provided > > by HIP. But I am not convinced that HITs cannot be taken placed by > > FQDNs just because HIT can be used for security purposes. > If so, why > > cannot we just associate with each FQDN with a PKI > certificate? There > > has been lots of work on session authentication using certificates. > > This solution seems much easier to be achieved than modifying the > > protocol stack. > > > > In addition, do you have any idea about whether it is reasonable to > > assume that each HIP host is associated with a FQDN? > > > > Best wishes, > > > > Dacheng Zhang > > > > > >> Excerpts from Zhang Dacheng on Thu, Jan 22, 2009 10:43:02AM +0800: > >>> I agree that it is an intuitive solution to solve the key > >> revocation > >>> issue with DNS. However, my concern is whether it is > >> reasonable for us > >>> to assume that every host has a FQDN. If yes, the > >> importance of HIP is > >>> largely weakened. We can use FQDN rather than HI to achieve the > >>> separation of ID from Locator. > >> > >> As far as I can see this isn't true. Different "identification" > >> functions have different needs. You can use a FQDN as an > identifier > >> for initial discovery of a location, but you cannot use it for > >> session authentication or control. To start with you would be > >> subject to man-in-the-middle attacks. > >> > >> Scott > >> _______________________________________________ > >> Hipsec-rg mailing list > >> Hipsec-rg at listserv.cybertrust.com > >> https://listserv.cybertrust.com/mailman/listinfo/hipsec-rg > > > > _______________________________________________ > > Hipsec-rg mailing list > > Hipsec-rg at listserv.cybertrust.com > > https://listserv.cybertrust.com/mailman/listinfo/hipsec-rg > > > > _______________________________________________ > Hipsec-rg mailing list > Hipsec-rg at listserv.cybertrust.com > https://listserv.cybertrust.com/mailman/listinfo/hipsec-rg
- [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