Re: [hiprg] comments on draft-irtf-hiprg-revocation-01.txt

[René Hummen <[e-mail]>]

Hello Tom, hello all,

On 07.11.2010, at 05:36, Henderson, Thomas R wrote:
> Dacheng and all,
> 
> I will send some editorial comments privately but I have some more substantive comments on this draft below, for discussion.
> 
> I believe there are some scope or use case issues for this draft that needs to be discussed further.  In particular, I think it is important to distinguish between key revocation and certificate revocation, and try to decide what items we want to consider to be in-scope vs. out-of-scope.
> 
> In traditional certificate revocation, it is the binding between name and key that must be revoked, but the name is assumed to persist longer than the binding/certificate.  Here, the name _is_ the key.  This has some implications.  What does it mean to revoke a name or an identity in this architecture?  It seems to me that, conceptually, the host named by the HI no longer exists.  Therefore, I am a bit suspicious of techniques that would try to replace one HI for another.
> 
> For example, suppose a HI is compromised and two hosts now have the key.  Each of them could contact a third party and purport to be the "real" owner of the HI and ask to move the HI to a new HI.  Which one to believe?  I also think it would be unexpected if I opened a session to one host ID and later inspected my HIP database and found that I was instead talking to another host ID.
> 
> It seems to me that for revocation to work, there must be a longer-lived name of some sort that persists across the key change.  But in pure HIP, I am not sure what that would be.

You have a valid point here. Tobias and I recently discovered the same issue in a bit different context. Motivated by the problem of needing a stable identifier, I started writing a draft about a certificate-based namespace for HIP that consists of a descriptive host identifier, a public key and a binding certificate. Tobias will hold a short presentation on the ideas during this year's IETF HIPRG meeting for me. I would be glad to get early feedback regarding the definition of such a namespace.

BR,
René

> So, I would like to offer the following for discussion:
> 
> - do not allow one HI to replace another in active associations.  If a HI is declared to be compromised or expired, another HI for the host in question needs to be disseminated through some third party means (e.g. DNS, or however the original HI was learned in the first place).
> 
> - specify procedures or recommended practice if a HIP host finds that its HI has been compromised.  For instance, closing all of its open associations, perhaps with some kind of NOTIFY, would be a good idea, as well as updating DNS, updating RVS, etc.  I think that this tends to imply that there probably needs to be some kind of stable identifier and security in addition to the HI that a host can use to authenticate itself to resolution infrastructure, in case this happens.  For example, the secret_hash value in the DHT draft could be used to remove the DHT record.
> 
> - specify procedures to allow a HIP host to intentionally put an expiration date on its HI, and what measures it should take to allow another HI to be available in advance of the expiry
> 
> - suggest techniques how a host may learn from third parties (e.g. poll some kind of revocation list, check such list on-demand, process a new kind of NOTIFY) that one of its peer's HI is revoked or expired.  Peers will need to learn of new HIs in such a case that is logically associated with the physical host they want to contact.
> 
> - I think there are potentially also some API implications of this, similar to DNS TTLs not being passed to applications, that should be considered for native HIP APIs.
> 
> Then, another scenario to consider is what to do when certificates such as in the current HIP WG Cert draft are in use with non-HIP-based distinguished names (such as FQDN/NAI).  This case is an example in which there is a longer-lived name (the DN)-- maybe there might be different solutions for this case.
> 
> - Tom
> 
> _______________________________________________
> hiprg mailing list
> [e-mail]
> https://www.irtf.org/mailman/listinfo/hiprg




--
Dipl.-Inform. Rene Hummen, Ph.D. Student
Chair of Communication and Distributed Systems
RWTH Aachen University, Germany
tel: [phone]
web: http://ds.rwth-aachen.de/members/hummen