[Hipsec-rg] Key Revocation Issue

[zhangdacheng at huawei.com (Zhang Dacheng)]

Hi, Tom:

Very happy to get your reply again. It is very nice to exchange ideas with
you. 

In a security system, a key revocation may occur not only when a key has
been found to be compromised but also when the possibility of key compromise
is over a threshold. For example, the operating system of our computer may
remind us to change our password every three months, which indicates the
strengths of our passwords are not secure enough as time passes rather than
our passwords have been stolen. 

I agree that in a distributed system, the identifiers of system components
are desired to be stable. Transient identifiers will make the system more
complex and error prone. However, in the HIP architecture, each HIT is
associated with a cryptographic key which needs to be updated periodically
to keep the security strength. Therefore, the key revocation issues cannot
be ignored unless we only expect a HIP system works securely for a
relatively short period (for example, one year). Do you agree with this
point?

In addition, I believe there are many things left in the area for us to
explore. For instance, in PKI, one can assess the validity of a public key
by checking its living-period in corresponding certificate. In HIP, no such
information is provided. In addition, PKI provides the Online Certificate
Status Protocol for users to query the validity of certificates while no
similar protocol is provided in HIP. 

Best Regards

Dacheng


> -----Original Message-----
> From: Henderson, Thomas R [mailto:thomas.r.henderson at boeing.com]
> Sent: Friday, February 06, 2009 11:58 PM
> To: Zhang Dacheng; hipsec-rg at listserv.cybertrust.com
> Subject: RE: [Hipsec-rg] Key Revocation Issue

> 
> 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.
> 
I definitely agree with that. Additionally, in this case, additional
information needs to be provided to authenticate or verify 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.
> 
This is the way that I am thinking in. However, since HITs are used to
identify hosts in HIP, we seems to have no choice but to find some ways to
let the entities using an antique HIT know that the HIT has been updated. 


> 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.
> 
I agree with that. In many existing security systems, human involvement is
required when dealing with key compromising issues. However, this doesn't
mean we need to do nothing when we design HIP. Maybe we cannot  solve the
entire problem, but at least we can try to push a step forward. For example,
in PKI, when a certificate is found to be compromised, the CA are normally
informed in an out-of-band way. But this does not prevent the Certificate
revocation list protocol and the Online Certificate Status Protocol from
being adopted.




> Tom
> 
> Tom