[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: Saturday, January 31, 2009 6:01 PM
> To: Henderson, Thomas R; hipsec-rg at listserv.cybertrust.com
> Subject: ??: [Hipsec-rg] Key Revocation Issue
> 
> 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-Janua
> ry/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?

Sorry for the delay in responding...

I agree that there will be a need to deal with HIT changes in any
practical deployment.  What I was observing is that, if the HIT is
transient, this is all the more reason not to base ACLs on them, but to
use rather the long-term stable name.

This may also mean that guidance similar to RFC 1958 section 4.1 may
apply to HITs, in such use cases:

   4.1 Avoid any design that requires addresses to be hard coded or
   stored on non-volatile storage (except of course where this is an
   essential requirement as in a name server or configuration server).
   In general, user applications should use names rather than addresses.

Also, if HITs truly need to be revoked due to key compromise, it seems
problematic to try to define a framework where one HIT is linked somehow
to another so holders of the old HIT can securely find the new HIT,
based on HIP mechanisms alone.  

Tom

Tom