Re: [Hipsec] I-D Action:draft-ietf-hip-cert-04.txt

René Hummen <rene.hummen@cs.rwth-aachen.de> Wed, 29 September 2010 11:44 UTC

Return-Path: <rene.hummen@informatik.rwth-aachen.de>
X-Original-To: hipsec@core3.amsl.com
Delivered-To: hipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0522E3A6AD2 for <hipsec@core3.amsl.com>; Wed, 29 Sep 2010 04:44:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.501
X-Spam-Level:
X-Spam-Status: No, score=-4.501 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]
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 h8qbtScaltnG for <hipsec@core3.amsl.com>; Wed, 29 Sep 2010 04:44:34 -0700 (PDT)
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 B98623A6CF9 for <hipsec@ietf.org>; Wed, 29 Sep 2010 04:44:33 -0700 (PDT)
MIME-version: 1.0
Content-type: text/plain; charset="iso-8859-1"
Received: from ironport-out-1.rz.rwth-aachen.de ([134.130.5.40]) 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 <0L9I008OMBBGJ030@mta-1.ms.rz.RWTH-Aachen.de> for hipsec@ietf.org; Wed, 29 Sep 2010 13:45:16 +0200 (CEST)
X-IronPort-AV: E=Sophos;i="4.57,252,1283724000"; d="scan'208";a="74298569"
Received: from relay-auth-1.ms.rz.rwth-aachen.de (HELO relay-auth-1) ([134.130.7.78]) by ironport-in-1.rz.rwth-aachen.de with ESMTP; Wed, 29 Sep 2010 13:45:16 +0200
Received: from umic-i4-137-226-45-95.nn.rwth-aachen.de ([unknown] [137.226.45.95]) by relay-auth-1.ms.rz.rwth-aachen.de (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 9 2008)) with ESMTPA id <0L9I00JQZBBGDC70@relay-auth-1.ms.rz.rwth-aachen.de> for hipsec@ietf.org; Wed, 29 Sep 2010 13:45:16 +0200 (CEST)
From: René Hummen <rene.hummen@cs.rwth-aachen.de>
In-reply-to: <4C9B337D.4000904@hiit.fi>
Date: Wed, 29 Sep 2010 13:45:12 +0200
Content-transfer-encoding: quoted-printable
Message-id: <E309E9CC-551D-45BB-87EB-C67604F024D0@cs.rwth-aachen.de>
References: <20100923104502.A5CA73A6951@core3.amsl.com> <4C9B337D.4000904@hiit.fi>
To: HIP WG <hipsec@ietf.org>
X-Mailer: Apple Mail (2.1081)
Subject: Re: [Hipsec] I-D Action:draft-ietf-hip-cert-04.txt
X-BeenThere: hipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "This is the official IETF Mailing List for the HIP Working Group." <hipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/hipsec>, <mailto:hipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/hipsec>
List-Post: <mailto:hipsec@ietf.org>
List-Help: <mailto:hipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/hipsec>, <mailto:hipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 29 Sep 2010 11:44:36 -0000

Hi,

below are some questions and ideas that crossed my mind while reading the cert draft in section "2. CERT Parameter":

1.) The CERT parameter ordering is not completely clear to me. In a scenario with only one certificate per group the CERT parameters should be placed in ascending order according to the Cert group. However, when a Cert group consists of multiple Cert parameters, how should the CERT parameters of the group be ordered? In my opinion, CERT parameters of the same Cert group must also be placed in ascending order according to their Cert ID, but that's not what "The numbers in the Cert ID field MUST start from 1 up to Cert count." implies. Additionally it is not stated where you start numbering certificates in a chain: at the root (i.e. root-CA) or at leaf (i.e. Host ID)?

2.) When spanning a certificate chain across multiple packets, adding the first certificates of a group _and_ an additional list of issuers for the remaining certificates might be beneficial. The issuer list allows a verifier to validate that it trusts one of the issuing parties of the chain. If none is trusted, the verifier signals an error and drops the current and subsequent packets. Otherwise, it compares the issuer of subsequently received certificates with the ones in the list and only proceeds with the verification of the chain if the comparison was successful. This way, a verifier does not have to store/verify certificates in case there exists no trust root for the chain. Of course, a sender can still lie about the issuers, but this will be evident from the relative cheap list comparison.

3.) And finally: what is the reason behind limiting the group count to 1 in case of a certificate chain spanning multiple packets?

BR,
René


On 23.09.2010, at 13:01, Samu Varjonen wrote:
> Hi,
> 
> This is the updated version of the cert draft.
> 
>   Changes from version 03 to 04:
> 
>   o  Added the non-HIP aware use case to the Section 3.
> 
>   o  Clarified that the HITs are not always required in the
>      certificates.
> 
>   o  Rewrote the signaling section.
> 
>   o  LDAP URL to LDAP DN in Section 2 last paragraph.
> 
>   o  CERT is always covered by a signature as it's type number requires
> 
>   o  New example certificates
> 
>   o  Style and language clean-ups
> 
>   o  Changed IANA considerations
> 
>   o  Revised the type numbers
> 
>   o  RFC 2119 keywords
> 
>   o  Updated the IANA considerations section
> 
>   o  Rewrote the abstract
> 
> Comments are appreciated.
> 
> BR,
> Samu
> 
> On 09/23/2010 01:45 PM, Internet-Drafts@ietf.org wrote:
>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>> This draft is a work item of the Host Identity Protocol Working Group of the IETF.
>> 
>> 
>> 	Title           : HIP Certificates
>> 	Author(s)       : T. Heer, S. Varjonen
>> 	Filename        : draft-ietf-hip-cert-04.txt
>> 	Pages           : 13
>> 	Date            : 2010-09-23
>> 
>> The CERT parameter is a container for X.509.v3 certificates and
>> Simple Public Key Infrastructure (SPKI) certificates.  It is used for
>> carrying these certificates in HIP control packets.  This document
>> only specifies the certificate parameter and the error signaling in
>> case of a failed verification.  The use of certificates including how
>> certificates are obtained, requested, and which actions are taken
>> upon successful or failed verification are to be defined in the
>> documents that use the certificate parameter.  Additionally, this
>> document specifies the representations of Host Identity Tags in
>> X.509.v3 and SPKI certificates.
>> 
>> A URL for this Internet-Draft is:
>> http://www.ietf.org/internet-drafts/draft-ietf-hip-cert-04.txt
>> 
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>> 
>> Below is the data which will enable a MIME compliant mail reader
>> implementation to automatically retrieve the ASCII version of the
>> Internet-Draft.
>> 
>> 
>> 
>> _______________________________________________
>> Hipsec mailing list
>> Hipsec@ietf.org
>> https://www.ietf.org/mailman/listinfo/hipsec
> 
> _______________________________________________
> Hipsec mailing list
> Hipsec@ietf.org
> https://www.ietf.org/mailman/listinfo/hipsec




--
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