[Hipsec-rg] 答复: Key Revocation Issue

[zhangdacheng at huawei.com (Zhang Dacheng)]

Hi,

Very happy to get your feedback. Actually, the requirements of HIT mapping
are not limited to ACLs. There are still some other scenarios where HIT
mapping is needed. For example, the components of a current business
application can be developed independently, maintained by different
organizations, combined at runtime, and communicate with asynchronous
messages.  A typical collaboration between such two components can last from
days to months.  Therefore, in such a scenario, change of HITs can be
common.(Please refer to the literature of SaaS (software as a service) and
SOA (service oriented architecture) for more details.) When a host changes
its HIT, there should be a way to inform other collaborating asynchronous
hosts of the change. DNS is a potential solution. But my concern is whether
every host in the HIP architecture should be associated with a FQDN. In this
point, I agree with Andrew.
https://listserv.cybertrust.com/pipermail/hipsec-rg/2009-January/000616.html
. If a host only consumes services provided by other hosts, it is not
reasonable to force the host to apply and maintain an FQDN. 

> > 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.

As I mentioned previously, I am not trying to introduce a "new" third party.
It is fantastic if DNS service can be provided. But in the cases there is no
FQDN, we can try to solve the HIT mapping issue by extending the
functionality of Rendezvous servers. In addition, a HIT can only last for a
very short period (maybe  minutes), while it may take time for DNS to
refresh information. In this case, the idea of  extending of  Rendezvous
servers seems to be more valuable. 

What do you think about it?

Cheers

Dacheng

> ???: Henderson, Thomas R [mailto:thomas.r.henderson at boeing.com] 
> ????: 2009?1?31? 2:12
> ???: Zhang Dacheng; hipsec-rg at listserv.cybertrust.com
> ??: RE: [Hipsec-rg] Key Revocation Issue
> 
>  
> 
> > -----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-Janua
> ry/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