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

René Hummen <rene.hummen@cs.rwth-aachen.de> Sun, 07 November 2010 17:17 UTC

Return-Path: <rene.hummen@informatik.rwth-aachen.de>
X-Original-To: hiprg@core3.amsl.com
Delivered-To: hiprg@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C46FA3A680C for <hiprg@core3.amsl.com>; Sun, 7 Nov 2010 09:17:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.702
X-Spam-Level:
X-Spam-Status: No, score=-3.702 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, SARE_SUB_RAND_LETTRS4=0.799]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CcKFKc23+-Rd for <hiprg@core3.amsl.com>; Sun, 7 Nov 2010 09:17:02 -0800 (PST)
Received: from mta-1.ms.rz.rwth-aachen.de (mta-1.ms.rz.RWTH-Aachen.DE [134.130.7.72]) by core3.amsl.com (Postfix) with ESMTP id 025273A67D3 for <hiprg@irtf.org>; Sun, 7 Nov 2010 09:17:02 -0800 (PST)
MIME-version: 1.0
Received: from ironport-out-2.rz.rwth-aachen.de ([134.130.5.41]) by mta-1.ms.rz.RWTH-Aachen.de (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008)) with ESMTP id <0LBI0072LYOS5YE0@mta-1.ms.rz.RWTH-Aachen.de> for hiprg@irtf.org; Sun, 07 Nov 2010 18:17:16 +0100 (CET)
X-IronPort-AV: E=Sophos; i="4.58,310,1286143200"; d="p7s'?scan'208"; a="42694910"
Received: from relay-auth-2.ms.rz.rwth-aachen.de (HELO relay-auth-2) ([134.130.7.79]) by ironport-in-2.rz.rwth-aachen.de with ESMTP; Sun, 07 Nov 2010 18:17:16 +0100
Received: from [192.168.2.182] ([unknown] [217.50.197.126]) by relay-auth-2.ms.rz.rwth-aachen.de (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 9 2008)) with ESMTPA id <0LBI00KATYOSWI50@relay-auth-2.ms.rz.rwth-aachen.de> for hiprg@irtf.org; Sun, 07 Nov 2010 18:17:16 +0100 (CET)
From: =?iso-8859-1?Q?Ren=E9_Hummen?= <rene.hummen@cs.rwth-aachen.de>
Content-type: multipart/signed; boundary=Apple-Mail-54--542093248; protocol="application/pkcs7-signature"; micalg=sha1
Date: Sun, 07 Nov 2010 18:17:15 +0100
In-reply-to: <7CC566635CFE364D87DC5803D4712A6C4CEC451AAE@XCH-NW-10V.nw.nos.boeing.com>
To: "Henderson, Thomas R" <thomas.r.henderson@boeing.com>, hiprg@irtf.org
References: <20101025021501.884C63A6931@core3.amsl.com> <7CC566635CFE364D87DC5803D4712A6C4CEC451AAE@XCH-NW-10V.nw.nos.boeing.com>
Message-id: <50C6BB14-D32E-42CB-89CF-72BA0D576C6D@cs.rwth-aachen.de>
X-Mailer: Apple Mail (2.1081)
Subject: Re: [hiprg] comments on draft-irtf-hiprg-revocation-01.txt
X-BeenThere: hiprg@irtf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Host Identity Protocol \(HIP\) Research Group" <hiprg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/listinfo/hiprg>, <mailto:hiprg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/hiprg>
List-Post: <mailto:hiprg@irtf.org>
List-Help: <mailto:hiprg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/hiprg>, <mailto:hiprg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Sun, 07 Nov 2010 17:17:03 -0000

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
> hiprg@irtf.org
> 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: +49 241 80 20772
web: http://ds.rwth-aachen.de/members/hummen