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

"Henderson, Thomas R" <thomas.r.henderson@boeing.com> Sun, 07 November 2010 04:37 UTC

Return-Path: <thomas.r.henderson@boeing.com>
X-Original-To: hiprg@core3.amsl.com
Delivered-To: hiprg@core3.amsl.com
Received: from localhost (localhost []) by core3.amsl.com (Postfix) with ESMTP id 29BCC28C0FC for <hiprg@core3.amsl.com>; Sat, 6 Nov 2010 21:37:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106
X-Spam-Status: No, score=-106 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_RAND_LETTRS4=0.799, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id oEZRRYF+Leb8 for <hiprg@core3.amsl.com>; Sat, 6 Nov 2010 21:36:56 -0700 (PDT)
Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com []) by core3.amsl.com (Postfix) with ESMTP id 3FA923A6978 for <hiprg@irtf.org>; Sat, 6 Nov 2010 21:36:56 -0700 (PDT)
Received: from blv-av-01.boeing.com (blv-av-01.boeing.com []) by slb-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id oA74avBP025656 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sat, 6 Nov 2010 21:37:00 -0700 (PDT)
Received: from blv-av-01.boeing.com (localhost []) by blv-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id oA74avEk004518; Sat, 6 Nov 2010 21:36:57 -0700 (PDT)
Received: from XCH-NWHT-09.nw.nos.boeing.com (xch-nwht-09.nw.nos.boeing.com []) by blv-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id oA74av2J004515 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Sat, 6 Nov 2010 21:36:57 -0700 (PDT)
Received: from XCH-NW-10V.nw.nos.boeing.com ([]) by XCH-NWHT-09.nw.nos.boeing.com ([]) with mapi; Sat, 6 Nov 2010 21:36:57 -0700
From: "Henderson, Thomas R" <thomas.r.henderson@boeing.com>
To: "'Dacheng Zhang'" <zhangdacheng@huawei.com>, "'Dmitriy Kuptsov'" <Dmitriy.Kuptsov@hiit.fi>, "'shenshuo@cnnic.cn'" <shenshuo@cnnic.cn>
Date: Sat, 6 Nov 2010 21:36:56 -0700
Thread-Topic: comments on draft-irtf-hiprg-revocation-01.txt
Thread-Index: Actz6w25BcB+fpVBTiW0yp5b00vPtQKNG5ww
Message-ID: <7CC566635CFE364D87DC5803D4712A6C4CEC451AAE@XCH-NW-10V.nw.nos.boeing.com>
References: <20101025021501.884C63A6931@core3.amsl.com>
In-Reply-To: <20101025021501.884C63A6931@core3.amsl.com>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "hiprg@irtf.org" <hiprg@irtf.org>
Subject: [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 04:37:01 -0000

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.

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