[hiprg] review of HI revocation draft

"Henderson, Thomas R" <thomas.r.henderson@boeing.com> Wed, 25 April 2012 04:55 UTC

Return-Path: <thomas.r.henderson@boeing.com>
X-Original-To: hiprg@ietfa.amsl.com
Delivered-To: hiprg@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 226E821F8668 for <hiprg@ietfa.amsl.com>; Tue, 24 Apr 2012 21:55:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -107.099
X-Spam-Status: No, score=-107.099 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id ETsjWYQiM7-R for <hiprg@ietfa.amsl.com>; Tue, 24 Apr 2012 21:55:53 -0700 (PDT)
Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com []) by ietfa.amsl.com (Postfix) with ESMTP id 7DA0621F8661 for <hiprg@irtf.org>; Tue, 24 Apr 2012 21:55:53 -0700 (PDT)
Received: from stl-av-01.boeing.com (stl-av-01.boeing.com []) by blv-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id q3P4thdJ018005 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <hiprg@irtf.org>; Tue, 24 Apr 2012 21:55:46 -0700 (PDT)
Received: from stl-av-01.boeing.com (localhost []) by stl-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id q3P4uI3i029980 for <hiprg@irtf.org>; Tue, 24 Apr 2012 23:56:18 -0500 (CDT)
Received: from XCH-NWHT-07.nw.nos.boeing.com (xch-nwht-07.nw.nos.boeing.com []) by stl-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id q3P4uHxs029956 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK) for <hiprg@irtf.org>; Tue, 24 Apr 2012 23:56:18 -0500 (CDT)
Received: from XCH-NW-16V.nw.nos.boeing.com ([]) by XCH-NWHT-07.nw.nos.boeing.com ([]) with mapi; Tue, 24 Apr 2012 21:55:42 -0700
From: "Henderson, Thomas R" <thomas.r.henderson@boeing.com>
To: "hiprg@irtf.org" <hiprg@irtf.org>
Date: Tue, 24 Apr 2012 21:55:42 -0700
Thread-Topic: review of HI revocation draft
Thread-Index: Ac0in6rJVWV9fsmKT3mByCoD7yzsxQ==
Message-ID: <758141CC3D829043A8C3164DD3D593EA1BD24C86F9@XCH-NW-16V.nw.nos.boeing.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
Subject: [hiprg] review of HI revocation draft
X-BeenThere: hiprg@irtf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Host Identity Protocol \(HIP\) Research Group" <hiprg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/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: Wed, 25 Apr 2012 04:55:54 -0000

I'd like to start discussion of open issues for the HI revocation draft, the most recent version of which can be found at http://tools.ietf.org/html/draft-irtf-hiprg-revocation-05.  

The stated goal of this informational draft is to analyze the issues surrounding the key revocation issues for the host identity (HI) keys in HIP.  

Section 4.2 provides a taxonomy of permanent key revocation mechanisms.  

Section 5 discusses implicit HI revocation, by virtue of associating valid lifetimes directly in the HOST_ID parameter, or by specifying the lifetime by a trusted authority (certificate).  The section discusses the issues of how to implement a lifetime bound on the HI and directions for updating resolution systems to provide this information.

Section 6 discusses explicit HI revocation via mechanisms such as CRLs, and the issues that make such explicit revocation difficult operationally.  There is some discussion about extending RVS to serve as some kind of a trusted authority to map old (revoked) HIs to new HIs.

Section 7 discusses issues such as HI refreshment for current HIP associations, suggesting that Update packets can be used to signal the transition.  It also discusses issues surrounding how to communicate HI revocation securely if the HI has been compromised.

This document does not mandate new specification, but it does suggest that some extensions to HIP (support for online HI refreshment via UPDATEs, support for HI lifetimes) could be made.  It does predict that various HI revocation approaches will be adopted to support multiple use cases.

In my opinion, one of the purposes of a document like this is to guide future readers to the issues, considerations, and background literature surrounding a topic.  I tend to think that it is helpful to organize drafts like this around use cases, and try to cover those use cases well while explicitly excluding those use cases or items that are out of scope for the draft.  I believe that this draft could be improved if it were made more clear up front what use cases were covered and what were out of scope, and that some additional text on scoping and organization would help before submitting for review.  However, I realize this is a subjective assessment and would appreciate other opinions on this.

I would like to ask the research group to please review and comment on the document's readiness for publication and for an endorsement as a product of the RG, and if not, are there specific things that could be improved upon to reach that state?  

- Tom

p.s I had some comments about a year ago on this draft that were posted here:  http://www.ietf.org/mail-archive/web/hiprg/current/msg00816.html;  many have since been addressed.