From thomas.r.henderson@boeing.com Mon Aug 10 09:13:22 2009 Return-Path: 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 CEB7028C16F for ; Mon, 10 Aug 2009 09:13:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.409 X-Spam-Level: X-Spam-Status: No, score=-4.409 tagged_above=-999 required=5 tests=[AWL=-1.424, BAYES_40=-0.185, J_CHICKENPOX_16=0.6, J_CHICKENPOX_19=0.6, 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 Wxc9TAeVSKi0 for ; Mon, 10 Aug 2009 09:13:22 -0700 (PDT) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by core3.amsl.com (Postfix) with ESMTP id 0A6C228C164 for ; Mon, 10 Aug 2009 09:13:22 -0700 (PDT) Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by slb-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id n7AGCdIH000725 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 10 Aug 2009 09:12:39 -0700 (PDT) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id n7AGCdNX008520; Mon, 10 Aug 2009 09:12:39 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by slb-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id n7AGCbYg008369; Mon, 10 Aug 2009 09:12:38 -0700 (PDT) Received: from XCH-NW-5V1.nw.nos.boeing.com ([130.247.55.44]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 10 Aug 2009 09:12:38 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 10 Aug 2009 09:12:38 -0700 Message-ID: <77F357662F8BFA4CA7074B0410171B6D0A8B7219@XCH-NW-5V1.nw.nos.boeing.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [hiprg] draft-zhang-hip-hierarchical-parameter-00: Includinghieararchy in HIT generation Thread-Index: AcoPg6Bi2z0pX6p4SVy893mzy7yk7wKUE+bQ References: From: "Henderson, Thomas R" To: "Tobias Heer" , , "Xu Xiaohu" X-OriginalArrivalTime: 10 Aug 2009 16:12:38.0741 (UTC) FILETIME=[61773050:01CA19D5] Cc: hiprg@irtf.org Subject: Re: [hiprg] draft-zhang-hip-hierarchical-parameter-00: Includinghieararchy in HIT generation X-BeenThere: hiprg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Host Identity Protocol \(HIP\) Research Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2009 16:13:22 -0000 =20 > -----Original Message----- > From: Tobias Heer [mailto:heer@cs.rwth-aachen.de]=20 > Sent: Tuesday, July 28, 2009 6:02 AM > To: zhangdacheng@huawei.com; Xu Xiaohu > Cc: hiprg@irtf.org > Subject: [hiprg] draft-zhang-hip-hierarchical-parameter-00:=20 > Includinghieararchy in HIT generation >=20 > Hi! >=20 > I just wanted to clarify my comment in the HIPRG meeting on=20 > including =20 > the hierarchy in the HIT creation process. I think it would=20 > be good to =20 > have the hierarchy information in the HIT creation process=20 > because the =20 > hierarchy will be bound to the HIT itself. >=20 > Below I briefly sketched a possible way of including it without =20 > revealing the hierarchy to all hosts. >=20 > HIT generation could work like this: >=20 > 1. Pick random secret X >=20 > 2. H(Hierarchy, X) =3D> HTag >=20 > 3. H(PubKey, ..., HTag) =3D> HIT (Orchid) >=20 > --> Only use LTag if you do not want to reveal hierarchy. > --> Use hierarchy and X if you want to reveal the hierarchy. Hi Tobias, I recently had a chance to listen to the audio archive of the meeting and I'm reviewing the mail now. Can you explain in more detail what is the use case for what you are proposing? I thought that the draft was mainly concerned with having publicly revealed hierarchies so that reverse lookups could exploit hierarchy. In your proposal above, for the observer who knows X, how does such observer retrieve hierarchy bits, given the HIT, HTag, and X? Also, I am not sure you can claim that the result from your above is a HIT, because according to RFC4843 and 5201, a HIT is formed without these HTags. In particular, the HIT would no longer be able to be associated to the key, for an observer who does not know the magic HTag to apply.=20 Tom From heer@informatik.rwth-aachen.de Mon Aug 10 09:50:05 2009 Return-Path: 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 B5ADA3A68CE for ; Mon, 10 Aug 2009 09:50:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, J_CHICKENPOX_16=0.6, J_CHICKENPOX_19=0.6, 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 SiWYlErXigFH for ; Mon, 10 Aug 2009 09:50:04 -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 767F63A6D45 for ; Mon, 10 Aug 2009 09:50:04 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII; format=flowed; delsp=yes 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 <0KO6000MW6RHPME0@mta-1.ms.rz.RWTH-Aachen.de> for hiprg@irtf.org; Mon, 10 Aug 2009 18:50:05 +0200 (CEST) X-IronPort-AV: E=Sophos;i="4.43,354,1246831200"; d="scan'208";a="22049673" 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; Mon, 10 Aug 2009 18:50:05 +0200 Received: from ip67.infrahip.net ([unknown] [193.167.187.67]) 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 <0KO600I656RG9N30@relay-auth-1.ms.rz.rwth-aachen.de> for hiprg@irtf.org; Mon, 10 Aug 2009 18:50:05 +0200 (CEST) Message-id: From: Tobias Heer To: "Henderson, Thomas R" In-reply-to: <77F357662F8BFA4CA7074B0410171B6D0A8B7219@XCH-NW-5V1.nw.nos.boeing.com> Date: Mon, 10 Aug 2009 19:50:02 +0300 References: <77F357662F8BFA4CA7074B0410171B6D0A8B7219@XCH-NW-5V1.nw.nos.boeing.com> X-Mailer: Apple Mail (2.935.3) Cc: hiprg@irtf.org Subject: Re: [hiprg] draft-zhang-hip-hierarchical-parameter-00: Includinghieararchy in HIT generation X-BeenThere: hiprg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Host Identity Protocol \(HIP\) Research Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2009 16:50:05 -0000 Hi Tom, I was just picking up an idea that was described in another hierarchical HIT draft (draft-jiang-hiprg-hhit-arch-02.txt). I did like the touch that the "HIT" is determined by the hierarchy because it binds the hierarchy to the HIT and it becomes more difficult to spoof the hierarchy information for a given HIT because with a different hierarchy you end up with a different HIT. Hence, the hierarchy information would be self certifying in the sense that if I give a HIT to someone, the hierarchy would be bound to it and it would stay like that unless I changed my HIT. I have not really considered the practical benefits, I just wanted to tell the authors about the other approach. Maybe the authors of draft-jiang-hiprg-hhit- arch-02.txt can give some reasoning. Dacheng was worried that putting the hierarchy information into the HITs would reveal the hierarchy (even in cases where this is not wanted). Hence my suggestion to secure the hierarchy information with an additional hash. However, since the number of hierarchies is probably too small to make a full search through all hierarchies infeasible (one could just hash each hierarchy information and see whether a given hash matches), I introduced X, which is supposed to protect against this simple search. This was only meant as a quick reply to Dacheng's privacy concerns. The proposed solution was not meant to replace the hierarchy information in an additional parameter it was only intended to have a stronger binding between hierarchy information and HIT. I already stated this in a reply to Dancheng's e-mail on the list (28th of July, 17:29 GMT+3). You are perfectly right that the resulting hash is not a HIT in the original sense, and yes you must supply the Htag to allow verification. Hence, it must also be transmitted with the HI. And yes, it breaks backwards compatibility with hosts that don't know what to do with it. However, since it seems that more hash functions will be introduced in the process of adding crypto agility to HIP, one could consider this as an additional "hash function" or way of hashing. Don't get me wrong: I'm not saying we should do this. I just wanted to make people aware of the way it is handled in the other draft. BR and greetings from Helsinki, Tobi Am 10.08.2009 um 19:12 schrieb Henderson, Thomas R: > > >> -----Original Message----- >> From: Tobias Heer [mailto:heer@cs.rwth-aachen.de] >> Sent: Tuesday, July 28, 2009 6:02 AM >> To: zhangdacheng@huawei.com; Xu Xiaohu >> Cc: hiprg@irtf.org >> Subject: [hiprg] draft-zhang-hip-hierarchical-parameter-00: >> Includinghieararchy in HIT generation >> >> Hi! >> >> I just wanted to clarify my comment in the HIPRG meeting on >> including >> the hierarchy in the HIT creation process. I think it would >> be good to >> have the hierarchy information in the HIT creation process >> because the >> hierarchy will be bound to the HIT itself. >> >> Below I briefly sketched a possible way of including it without >> revealing the hierarchy to all hosts. >> >> HIT generation could work like this: >> >> 1. Pick random secret X >> >> 2. H(Hierarchy, X) => HTag >> >> 3. H(PubKey, ..., HTag) => HIT (Orchid) >> >> --> Only use LTag if you do not want to reveal hierarchy. >> --> Use hierarchy and X if you want to reveal the hierarchy. > > Hi Tobias, > > I recently had a chance to listen to the audio archive of the meeting > and I'm reviewing the mail now. Can you explain in more detail what > is > the use case for what you are proposing? I thought that the draft was > mainly concerned with having publicly revealed hierarchies so that > reverse lookups could exploit hierarchy. In your proposal above, for > the observer who knows X, how does such observer retrieve hierarchy > bits, given the HIT, HTag, and X? > > Also, I am not sure you can claim that the result from your above is a > HIT, because according to RFC4843 and 5201, a HIT is formed without > these HTags. In particular, the HIT would no longer be able to be > associated to the key, for an observer who does not know the magic > HTag > to apply. > > Tom -- Dipl.-Inform. Tobias Heer, Ph.D. Student Distributed Systems Group RWTH Aachen University, Germany tel: +49 241 80 207 76 web: http://ds.cs.rwth-aachen.de/members/heer From thomas.r.henderson@boeing.com Mon Aug 10 10:34:44 2009 Return-Path: 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 E143928C114 for ; Mon, 10 Aug 2009 10:34:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.86 X-Spam-Level: X-Spam-Status: No, score=-5.86 tagged_above=-999 required=5 tests=[AWL=0.739, BAYES_00=-2.599, 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 ZzSSyngg5amr for ; Mon, 10 Aug 2009 10:34:44 -0700 (PDT) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by core3.amsl.com (Postfix) with ESMTP id D094B3A6EBF for ; Mon, 10 Aug 2009 10:33:48 -0700 (PDT) Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by slb-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id n7AHXhTU021319 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 10 Aug 2009 10:33:44 -0700 (PDT) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id n7AHXhlp027182; Mon, 10 Aug 2009 10:33:43 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by slb-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id n7AHXc5I026810; Mon, 10 Aug 2009 10:33:43 -0700 (PDT) Received: from XCH-NW-5V1.nw.nos.boeing.com ([130.247.55.44]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 10 Aug 2009 10:33:42 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 10 Aug 2009 10:33:41 -0700 Message-ID: <77F357662F8BFA4CA7074B0410171B6D0A8B7220@XCH-NW-5V1.nw.nos.boeing.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [hiprg] draft-zhang-hip-hierarchical-parameter-00:Includinghieararchy in HIT generation Thread-Index: AcoZ2p6iOojCPsdERVKxqnpDdUbAzwAA+FqA References: <77F357662F8BFA4CA7074B0410171B6D0A8B7219@XCH-NW-5V1.nw.nos.boeing.com> From: "Henderson, Thomas R" To: "Tobias Heer" X-OriginalArrivalTime: 10 Aug 2009 17:33:42.0100 (UTC) FILETIME=[B440E140:01CA19E0] Cc: hiprg@irtf.org Subject: Re: [hiprg] draft-zhang-hip-hierarchical-parameter-00:Includinghieararchy in HIT generation X-BeenThere: hiprg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Host Identity Protocol \(HIP\) Research Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2009 17:34:45 -0000 > Hence, the =20 > hierarchy information would be self certifying in the sense=20 > that if I =20 > give a HIT to someone, the hierarchy would be bound to it and=20 > it would =20 > stay like that unless I changed my HIT.=20 ... > The proposed solution was not meant to replace the hierarchy =20 > information in an additional parameter it was only intended=20 > to have a =20 > stronger binding between hierarchy information and HIT.=20 Maybe this is a terminology issue but I don't think of this as a binding or as self-certifying, in the same way that a certificate binds a name to a principal, or in the way that current HITs are self-certifying, because there is no authorization to use the hierarchy bits. - Tom From heer@informatik.rwth-aachen.de Mon Aug 10 11:16:37 2009 Return-Path: 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 3FB3D3A6EA8 for ; Mon, 10 Aug 2009 11:16:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.801 X-Spam-Level: X-Spam-Status: No, score=-4.801 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, 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 gtoaaEvvz2y8 for ; Mon, 10 Aug 2009 11:16:36 -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 2EEB63A6C53 for ; Mon, 10 Aug 2009 11:16:36 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII; format=flowed; delsp=yes 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 <0KO600G2RARQYR00@mta-1.ms.rz.RWTH-Aachen.de> for hiprg@irtf.org; Mon, 10 Aug 2009 20:16:38 +0200 (CEST) X-IronPort-AV: E=Sophos;i="4.43,354,1246831200"; d="scan'208";a="22056566" 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; Mon, 10 Aug 2009 20:16:39 +0200 Received: from [192.168.178.21] ([unknown] [62.78.196.88]) 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 <0KO600IYCARQ9N30@relay-auth-1.ms.rz.rwth-aachen.de> for hiprg@irtf.org; Mon, 10 Aug 2009 20:16:38 +0200 (CEST) Message-id: <1BD110F3-FDE7-48BA-9E42-61B1D6B400E0@cs.rwth-aachen.de> From: Tobias Heer To: "Henderson, Thomas R" In-reply-to: <77F357662F8BFA4CA7074B0410171B6D0A8B7220@XCH-NW-5V1.nw.nos.boeing.com> Date: Mon, 10 Aug 2009 21:16:35 +0300 References: <77F357662F8BFA4CA7074B0410171B6D0A8B7219@XCH-NW-5V1.nw.nos.boeing.com> <77F357662F8BFA4CA7074B0410171B6D0A8B7220@XCH-NW-5V1.nw.nos.boeing.com> X-Mailer: Apple Mail (2.935.3) Cc: hiprg@irtf.org Subject: Re: [hiprg] draft-zhang-hip-hierarchical-parameter-00:Includinghieararchy in HIT generation X-BeenThere: hiprg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Host Identity Protocol \(HIP\) Research Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2009 18:16:37 -0000 Am 10.08.2009 um 20:33 schrieb Henderson, Thomas R: >> Hence, the >> hierarchy information would be self certifying in the sense >> that if I >> give a HIT to someone, the hierarchy would be bound to it and >> it would >> stay like that unless I changed my HIT. > > ... > >> The proposed solution was not meant to replace the hierarchy >> information in an additional parameter it was only intended >> to have a >> stronger binding between hierarchy information and HIT. > > Maybe this is a terminology issue but I don't think of this as a > binding > or as self-certifying, in the same way that a certificate binds a name > to a principal, or in the way that current HITs are self-certifying, > because there is no authorization to use the hierarchy bits. > > - Tom I agree, this is probably a terminology problem. I also agree that this binding (or call it linking if you prefer) does not imply authorized use of the hierarchy data in the HIT generation. BR, Tobias -- Dipl.-Inform. Tobias Heer, Ph.D. Student Distributed Systems Group RWTH Aachen University, Germany tel: +49 241 80 207 76 web: http://ds.cs.rwth-aachen.de/members/heer From heer@informatik.rwth-aachen.de Mon Aug 10 23:24:42 2009 Return-Path: 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 74F943A6844 for ; Mon, 10 Aug 2009 23:24:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.807 X-Spam-Level: X-Spam-Status: No, score=-2.807 tagged_above=-999 required=5 tests=[AWL=-1.994, BAYES_00=-2.599, CN_BODY_35=0.339, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, J_CHICKENPOX_16=0.6, J_CHICKENPOX_19=0.6, MIME_CHARSET_FARAWAY=2.45, 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 3kaXBf5MuJRk for ; Mon, 10 Aug 2009 23:24:41 -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 3E6E33A6F77 for ; Mon, 10 Aug 2009 23:23:57 -0700 (PDT) MIME-version: 1.0 Content-type: text/plain; charset=GB2312; format=flowed; delsp=yes 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 <0KO700D5L8FZ7F20@mta-1.ms.rz.RWTH-Aachen.de> for hiprg@irtf.org; Tue, 11 Aug 2009 08:23:59 +0200 (CEST) X-IronPort-AV: E=Sophos;i="4.43,358,1246831200"; d="scan'208";a="22090463" 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; Tue, 11 Aug 2009 08:24:00 +0200 Received: from [192.168.178.24] ([unknown] [62.78.196.88]) 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 <0KO7004C78FZY300@relay-auth-1.ms.rz.rwth-aachen.de> for hiprg@irtf.org; Tue, 11 Aug 2009 08:23:59 +0200 (CEST) Message-id: <29910A68-445C-42F5-83C3-DDF6E800BE60@cs.rwth-aachen.de> From: Tobias Heer To: Dacheng Zhang In-reply-to: <000f01ca1a32$d5296fb0$6c0c6f0a@china.huawei.com> Content-transfer-encoding: quoted-printable Date: Tue, 11 Aug 2009 09:23:56 +0300 References: <000f01ca1a32$d5296fb0$6c0c6f0a@china.huawei.com> X-Mailer: Apple Mail (2.935.3) Cc: hiprg@irtf.org Subject: Re: [hiprg] draft-zhang-hip-hierarchical-parameter-00: Includinghieararchy in HIT generation X-BeenThere: hiprg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Host Identity Protocol \(HIP\) Research Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2009 06:24:42 -0000 Hi Dacheng, Am 11.08.2009 um 06:21 schrieb Dacheng Zhang: > HI,Tobi: > > You mentioned in your emails that your solution can provide a stronger > binding between hierarchy information and HITs. I am a little =20 > confused about > this argument. Why do we need a stronger binding? Could your please =20= > use an > example to clarify in which condition the binging in current =20 > solutions is > not strong enough? As I pointed out in my E-Mail to Tom, my main intention was to make =20 you aware of the possibility to have a hierarchy-dependent HIT as =20 described in draft-jiang-hiprg-hhit-arch-02.txt, not to point out any =20= flaws in your design or in the current HIT design. If you don't see =20 any application for this, feel free to discard the suggestion. > > In addition, there is something that I am not very sure in your =20 > algorithm. > If X is used to prevent guessing, the confidentiality of X must be > guaranteed. > That is, X must be kept privately. X must be kept as secret as the hierarchical information. It is safe =20 to reveal X to everyone who is intended to receive the hierarchical =20 information. > However, in your solution, > communicating peers need to know X in order to verify the binding =20 > between a > HIT and its public key pair. Then how can two communicating peers =20 > exchange X > securely before they have achieved basic exchange? > This is where the Htag comes in. If you don't intend to disclose X and =20= the hierarchy, the Htag is sufficient to verify the HIT / HI relation. =20= Since the Htag is the result of H(Hierarchy, X), the hierarchical =20 information cannot be guessed from the Htag. =09 BR, Tobias > > ^_^ > > BR > > Dacheng > > -----=D3=CA=BC=FE=D4=AD=BC=FE----- > =B7=A2=BC=FE=C8=CB: Tobias Heer [mailto:heer@cs.rwth-aachen.de] > =B7=A2=CB=CD=CA=B1=BC=E4: 2009=C4=EA8=D4=C211=C8=D5 0:50 > =CA=D5=BC=FE=C8=CB: Henderson, Thomas R > =B3=AD=CB=CD: zhangdacheng@huawei.com; Xu Xiaohu; hiprg@irtf.org > =D6=F7=CC=E2: Re: [hiprg] draft-zhang-hip-hierarchical-parameter-00: > Includinghieararchy in HIT generation > > Hi Tom, > > I was just picking up an idea that was described in another =20 > hierarchical HIT > draft (draft-jiang-hiprg-hhit-arch-02.txt). I did like the touch =20 > that the > "HIT" is determined by the hierarchy because it binds the hierarchy =20= > to the > HIT and it becomes more difficult to spoof the hierarchy information =20= > for a > given HIT because with a different hierarchy you end up with a =20 > different > HIT. Hence, the hierarchy information would be self certifying in =20 > the sense > that if I give a HIT to someone, the hierarchy would be bound to it =20= > and it > would stay like that unless I changed my HIT. I have not really =20 > considered > the practical benefits, I just wanted to tell the authors about the =20= > other > approach. Maybe the authors of draft-jiang-hiprg-hhit- arch-02.txt =20 > can give > some reasoning. > > Dacheng was worried that putting the hierarchy information into the =20= > HITs > would reveal the hierarchy (even in cases where this is not wanted). =20= > Hence > my suggestion to secure the hierarchy information with an additional =20= > hash. > However, since the number of hierarchies is probably too small to =20 > make a > full search through all hierarchies infeasible (one could just hash =20= > each > hierarchy information and see whether a given hash matches), I =20 > introduced X, > which is supposed to protect against this simple search. This was =20 > only meant > as a quick reply to Dacheng's privacy concerns. > > The proposed solution was not meant to replace the hierarchy =20 > information in > an additional parameter it was only intended to have a stronger =20 > binding > between hierarchy information and HIT. I already stated this in a =20 > reply to > Dancheng's e-mail on the list (28th of July, > 17:29 GMT+3). > > You are perfectly right that the resulting hash is not a HIT in the =20= > original > sense, and yes you must supply the Htag to allow verification. =20 > Hence, it > must also be transmitted with the HI. And yes, it breaks backwards > compatibility with hosts that don't know what to do with it. =20 > However, since > it seems that more hash functions will be introduced in the process of > adding crypto agility to HIP, one could consider this as an =20 > additional "hash > function" or way of hashing. > > Don't get me wrong: I'm not saying we should do this. I just wanted =20= > to make > people aware of the way it is handled in the other draft. > > BR and greetings from Helsinki, > > Tobi > > > > > > Am 10.08.2009 um 19:12 schrieb Henderson, Thomas R: > >> >> >>> -----Original Message----- >>> From: Tobias Heer [mailto:heer@cs.rwth-aachen.de] >>> Sent: Tuesday, July 28, 2009 6:02 AM >>> To: zhangdacheng@huawei.com; Xu Xiaohu >>> Cc: hiprg@irtf.org >>> Subject: [hiprg] draft-zhang-hip-hierarchical-parameter-00: >>> Includinghieararchy in HIT generation >>> >>> Hi! >>> >>> I just wanted to clarify my comment in the HIPRG meeting on =20 >>> including >>> the hierarchy in the HIT creation process. I think it would be good >>> to have the hierarchy information in the HIT creation process =20 >>> because >>> the hierarchy will be bound to the HIT itself. >>> >>> Below I briefly sketched a possible way of including it without >>> revealing the hierarchy to all hosts. >>> >>> HIT generation could work like this: >>> >>> 1. Pick random secret X >>> >>> 2. H(Hierarchy, X) =3D> HTag >>> >>> 3. H(PubKey, ..., HTag) =3D> HIT (Orchid) >>> >>> --> Only use LTag if you do not want to reveal hierarchy. >>> --> Use hierarchy and X if you want to reveal the hierarchy. >> >> Hi Tobias, >> >> I recently had a chance to listen to the audio archive of the meeting >> and I'm reviewing the mail now. Can you explain in more detail what >> is the use case for what you are proposing? I thought that the draft >> was mainly concerned with having publicly revealed hierarchies so =20 >> that >> reverse lookups could exploit hierarchy. In your proposal above, for >> the observer who knows X, how does such observer retrieve hierarchy >> bits, given the HIT, HTag, and X? >> >> Also, I am not sure you can claim that the result from your above =20 >> is a >> HIT, because according to RFC4843 and 5201, a HIT is formed without >> these HTags. In particular, the HIT would no longer be able to be >> associated to the key, for an observer who does not know the magic >> HTag to apply. >> >> Tom > > > > > -- =20 > > Dipl.-Inform. Tobias Heer, Ph.D. Student Distributed Systems Group =20 > RWTH > Aachen University, Germany > tel: +49 241 80 207 76 > web: http://ds.cs.rwth-aachen.de/members/heer > > > > > > > -- =20 Dipl.-Inform. Tobias Heer, Ph.D. Student Distributed Systems Group RWTH Aachen University, Germany tel: +49 241 80 207 76 web: http://ds.cs.rwth-aachen.de/members/heer From shengjiang@huawei.com Mon Aug 10 23:50:20 2009 Return-Path: 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 7BC303A6D38 for ; Mon, 10 Aug 2009 23:50:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.494 X-Spam-Level: *** X-Spam-Status: No, score=3.494 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CN_BODY_35=0.339, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_16=0.6, J_CHICKENPOX_19=0.6, MIME_CHARSET_FARAWAY=2.45, RDNS_NONE=0.1] 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 SOcwbqWrDXW8 for ; Mon, 10 Aug 2009 23:50:19 -0700 (PDT) Received: from szxga02-in.huawei.com (unknown [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id BCD0C3A6883 for ; Mon, 10 Aug 2009 23:50:18 -0700 (PDT) Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KO700EKL9NN9K@szxga02-in.huawei.com> for hiprg@irtf.org; Tue, 11 Aug 2009 14:50:12 +0800 (CST) Received: from huawei.com ([172.24.1.33]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KO70098H9NNBI@szxga02-in.huawei.com> for hiprg@irtf.org; Tue, 11 Aug 2009 14:50:11 +0800 (CST) Received: from j66104a ([10.111.12.172]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KO7004E69NNUJ@szxml06-in.huawei.com> for hiprg@irtf.org; Tue, 11 Aug 2009 14:50:11 +0800 (CST) Date: Tue, 11 Aug 2009 14:50:10 +0800 From: Sheng Jiang In-reply-to: <29910A68-445C-42F5-83C3-DDF6E800BE60@cs.rwth-aachen.de> To: 'Tobias Heer' , 'Dacheng Zhang' Message-id: <000001ca1a4f$f8afa680$ac0c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=gb2312 Content-transfer-encoding: quoted-printable Thread-index: AcoaTLuOzb75ifp1Rrizxs+tlGaxvgAAJuMg Cc: hiprg@irtf.org Subject: Re: [hiprg] draft-zhang-hip-hierarchical-parameter-00: Includinghieararchy in HIT generation X-BeenThere: hiprg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Host Identity Protocol \(HIP\) Research Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2009 06:50:20 -0000 Hi, Tobias, Thanks for your email. As the initial author of = draft-jiang-hiprg-hhit-arch, our original motivation is to enable HIT to be independently used in = many scenarios that needs hierarchical information. I believe the similor motivation also apply to Dacheng and his draft-zhang-hip-hierarchical-parameter. Two of us are actually working closely. The main different between his proposal and mine is that his proposal remains the current HIT architecture, hierarchical information is = additional while mine binds hierarchy information and HITs together and actually request a revolutionized HIT architecture. The biggest advantage of my proposal, also the answer Why do we need a strong binding between hierarchy information and HITs, is to enable HIT = to be independently used in many scenarios that needs hierarchical = information, such as high efficiency resolution, group management of HIT, etc. This proposal also ensure the global uniqueness of HITs, which the current = HIT architecture cannot guarantee. Best regards, Sheng > -----Original Message----- > From: hiprg-bounces@irtf.org [mailto:hiprg-bounces@irtf.org]=20 > On Behalf Of Tobias Heer > Sent: Tuesday, August 11, 2009 2:24 PM > To: Dacheng Zhang > Cc: hiprg@irtf.org > Subject: Re: [hiprg]=20 > draft-zhang-hip-hierarchical-parameter-00:=20 > Includinghieararchy in HIT generation >=20 > Hi Dacheng, >=20 >=20 > Am 11.08.2009 um 06:21 schrieb Dacheng Zhang: >=20 > > HI,Tobi: > > > > You mentioned in your emails that your solution can provide=20 > a stronger=20 > > binding between hierarchy information and HITs. I am a=20 > little confused=20 > > about this argument. Why do we need a stronger binding? Could your=20 > > please use an example to clarify in which condition the binging in=20 > > current solutions is not strong enough? >=20 > As I pointed out in my E-Mail to Tom, my main intention was=20 > to make you aware of the possibility to have a=20 > hierarchy-dependent HIT as described in=20 > draft-jiang-hiprg-hhit-arch-02.txt, not to point out any=20 > flaws in your design or in the current HIT design. If you=20 > don't see any application for this, feel free to discard the=20 > suggestion. >=20 > > > > In addition, there is something that I am not very sure in your=20 > > algorithm. > > If X is used to prevent guessing, the confidentiality of X must be=20 > > guaranteed. > > That is, X must be kept privately. > X must be kept as secret as the hierarchical information. It=20 > is safe to reveal X to everyone who is intended to receive=20 > the hierarchical information. >=20 > > However, in your solution, > > communicating peers need to know X in order to verify the binding=20 > > between a HIT and its public key pair. Then how can two=20 > communicating=20 > > peers exchange X securely before they have achieved basic exchange? > > > This is where the Htag comes in. If you don't intend to=20 > disclose X and the hierarchy, the Htag is sufficient to=20 > verify the HIT / HI relation. =20 > Since the Htag is the result of H(Hierarchy, X), the hierarchical =20 > information cannot be guessed from the Htag. =09 >=20 > BR, >=20 > Tobias >=20 > > > > ^_^ > > > > BR > > > > Dacheng > > > > -----=D3=CA=BC=FE=D4=AD=BC=FE----- > > =B7=A2=BC=FE=C8=CB: Tobias Heer [mailto:heer@cs.rwth-aachen.de] > > =B7=A2=CB=CD=CA=B1=BC=E4: 2009=C4=EA8=D4=C211=C8=D5 0:50 > > =CA=D5=BC=FE=C8=CB: Henderson, Thomas R > > =B3=AD=CB=CD: zhangdacheng@huawei.com; Xu Xiaohu; hiprg@irtf.org > > =D6=F7=CC=E2: Re: [hiprg] draft-zhang-hip-hierarchical-parameter-00: > > Includinghieararchy in HIT generation > > > > Hi Tom, > > > > I was just picking up an idea that was described in another=20 > > hierarchical HIT draft (draft-jiang-hiprg-hhit-arch-02.txt). I did=20 > > like the touch that the "HIT" is determined by the=20 > hierarchy because=20 > > it binds the hierarchy to the HIT and it becomes more difficult to=20 > > spoof the hierarchy information for a given HIT because with a=20 > > different hierarchy you end up with a different HIT. Hence, the=20 > > hierarchy information would be self certifying in the sense=20 > that if I=20 > > give a HIT to someone, the hierarchy would be bound to it=20 > and it would=20 > > stay like that unless I changed my HIT. I have not really=20 > considered=20 > > the practical benefits, I just wanted to tell the authors about the=20 > > other approach. Maybe the authors of draft-jiang-hiprg-hhit-=20 > > arch-02.txt can give some reasoning. > > > > Dacheng was worried that putting the hierarchy information into the=20 > > HITs would reveal the hierarchy (even in cases where this is not=20 > > wanted). > > Hence > > my suggestion to secure the hierarchy information with an=20 > additional=20 > > hash. > > However, since the number of hierarchies is probably too=20 > small to make=20 > > a full search through all hierarchies infeasible (one could=20 > just hash=20 > > each hierarchy information and see whether a given hash matches), I=20 > > introduced X, which is supposed to protect against this=20 > simple search.=20 > > This was only meant as a quick reply to Dacheng's privacy concerns. > > > > The proposed solution was not meant to replace the hierarchy=20 > > information in an additional parameter it was only intended=20 > to have a=20 > > stronger binding between hierarchy information and HIT. I already=20 > > stated this in a reply to Dancheng's e-mail on the list=20 > (28th of July, > > 17:29 GMT+3). > > > > You are perfectly right that the resulting hash is not a HIT in the=20 > > original sense, and yes you must supply the Htag to allow=20 > > verification. > > Hence, it > > must also be transmitted with the HI. And yes, it breaks backwards=20 > > compatibility with hosts that don't know what to do with it. > > However, since > > it seems that more hash functions will be introduced in the=20 > process of=20 > > adding crypto agility to HIP, one could consider this as an=20 > additional=20 > > "hash function" or way of hashing. > > > > Don't get me wrong: I'm not saying we should do this. I=20 > just wanted to=20 > > make people aware of the way it is handled in the other draft. > > > > BR and greetings from Helsinki, > > > > Tobi > > > > > > > > > > > > Am 10.08.2009 um 19:12 schrieb Henderson, Thomas R: > > > >> > >> > >>> -----Original Message----- > >>> From: Tobias Heer [mailto:heer@cs.rwth-aachen.de] > >>> Sent: Tuesday, July 28, 2009 6:02 AM > >>> To: zhangdacheng@huawei.com; Xu Xiaohu > >>> Cc: hiprg@irtf.org > >>> Subject: [hiprg] draft-zhang-hip-hierarchical-parameter-00: > >>> Includinghieararchy in HIT generation > >>> > >>> Hi! > >>> > >>> I just wanted to clarify my comment in the HIPRG meeting on=20 > >>> including the hierarchy in the HIT creation process. I think it=20 > >>> would be good to have the hierarchy information in the=20 > HIT creation=20 > >>> process because the hierarchy will be bound to the HIT itself. > >>> > >>> Below I briefly sketched a possible way of including it without=20 > >>> revealing the hierarchy to all hosts. > >>> > >>> HIT generation could work like this: > >>> > >>> 1. Pick random secret X > >>> > >>> 2. H(Hierarchy, X) =3D> HTag > >>> > >>> 3. H(PubKey, ..., HTag) =3D> HIT (Orchid) > >>> > >>> --> Only use LTag if you do not want to reveal hierarchy. > >>> --> Use hierarchy and X if you want to reveal the hierarchy. > >> > >> Hi Tobias, > >> > >> I recently had a chance to listen to the audio archive of=20 > the meeting=20 > >> and I'm reviewing the mail now. Can you explain in more=20 > detail what=20 > >> is the use case for what you are proposing? I thought=20 > that the draft=20 > >> was mainly concerned with having publicly revealed hierarchies so=20 > >> that reverse lookups could exploit hierarchy. In your proposal=20 > >> above, for the observer who knows X, how does such=20 > observer retrieve=20 > >> hierarchy bits, given the HIT, HTag, and X? > >> > >> Also, I am not sure you can claim that the result from=20 > your above is=20 > >> a HIT, because according to RFC4843 and 5201, a HIT is=20 > formed without=20 > >> these HTags. In particular, the HIT would no longer be able to be=20 > >> associated to the key, for an observer who does not know the magic=20 > >> HTag to apply. > >> > >> Tom > > > > > > > > > > -- > > > > Dipl.-Inform. Tobias Heer, Ph.D. Student Distributed Systems Group=20 > > RWTH Aachen University, Germany > > tel: +49 241 80 207 76 > > web: http://ds.cs.rwth-aachen.de/members/heer > > > > > > > > > > > > > > >=20 >=20 >=20 >=20 > -- =20 >=20 > Dipl.-Inform. Tobias Heer, Ph.D. Student Distributed Systems=20 > Group RWTH Aachen University, Germany > tel: +49 241 80 207 76 > web: http://ds.cs.rwth-aachen.de/members/heer >=20 >=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > hiprg mailing list > hiprg@irtf.org > https://www.irtf.org/mailman/listinfo/hiprg >=20 From xuxh@huawei.com Tue Aug 11 00:21:32 2009 Return-Path: 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 A133E3A67C0 for ; Tue, 11 Aug 2009 00:21:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.345 X-Spam-Level: ** X-Spam-Status: No, score=2.345 tagged_above=-999 required=5 tests=[AWL=0.955, BAYES_00=-2.599, CN_BODY_35=0.339, J_CHICKENPOX_16=0.6, J_CHICKENPOX_19=0.6, MIME_CHARSET_FARAWAY=2.45] 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 w-0mSa8K08pY for ; Tue, 11 Aug 2009 00:21:31 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id 51CF23A69A4 for ; Tue, 11 Aug 2009 00:21:31 -0700 (PDT) Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KO700CBYB3X18@szxga01-in.huawei.com> for hiprg@irtf.org; Tue, 11 Aug 2009 15:21:33 +0800 (CST) Received: from huawei.com ([172.24.1.33]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KO700ARYB3XAK@szxga01-in.huawei.com> for hiprg@irtf.org; Tue, 11 Aug 2009 15:21:33 +0800 (CST) Received: from HUAWEIE75F8F11 ([10.111.12.212]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KO70049OB3WUJ@szxml06-in.huawei.com> for hiprg@irtf.org; Tue, 11 Aug 2009 15:21:33 +0800 (CST) Date: Tue, 11 Aug 2009 15:21:32 +0800 From: Xu Xiaohu In-reply-to: To: hiprg@irtf.org Message-id: <002701ca1a54$5a734800$d40c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=gb2312 Content-transfer-encoding: quoted-printable Thread-index: AcoPg6Bi2z0pX6p4SVy893mzy7yk7wKUE+bQABZHwNAACbGKEA== Subject: Re: [hiprg] draft-zhang-hip-hierarchical-parameter-00: Includinghieararchy in HIT generation X-BeenThere: hiprg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Host Identity Protocol \(HIP\) Research Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2009 07:21:32 -0000 =3D=3D=3DIt seems that my preview email is not posted to the HIPRG = mailing-list successfully, so I resend it.=3D=3D=3D=3D Hi all, IMHO, one can directly use the CGA mechanism with small changes, rather = than a new algorithm as mentioned by Tobias, to generate hierarchical and cryptographic host identifiers. In fact, we have already been using the = CGA mechanism to generate host identifiers in our RANGI proposal (http://tools.ietf.org/html/draft-xu-rangi-01). The following is the = quote from that proposal. For more information, please read that draft. "The approach of generating hierarchical host identifiers in RANGI is = much similar to the Cryptographically Generated Addresses (CGA) [RFC3972]. = The major difference is that the prefix of the RANGI host identifier is AD = ID, rather than ordinary IPv6 address prefix. In the CGA, the process of generating a new CGA takes three input values: a 64-bit subnet prefix, = the public key of the address owner as a DER-encoded ASN.1 structure of the = type SubjectPublicKeyInfo and the security parameter Sec, which is an = unsigned three-bit integer. In RANGI, the process of generating a new host = identifier also takes three input values: the n-bit AD ID (the suitable value of = =A1=B1n=A1=B1 has not been determined), the public key of the host ID owner and the security parameter Sec." However, as stated in the CGA [RFC 3972], "...because CGAs themselves = are not certified, an attacker can create a new CGA from any subnet prefix = and its own (or anyone else's) public key. However, the attacker cannot = take a CGA created by someone else and send signed messages that appear to come from the owner of that address... ". Hence, in order to verify the association between the prefix and the address owner, we need some other means, e.g., a certification issued by a third-party authority, or = resorting to such an authority for verification if necessary. For the privacy of identifier's organizational affiliation (i.e., Administrative Domain), maybe the two communicating parties could use = the hierarchical identifier to find the opposing party's locator in a hierarchical id/locator mapping system, then use the self-certified flat = HIT instead for subsequent communication if the privacy is necessary. Xiaohu > -----=D3=CA=BC=FE=D4=AD=BC=FE----- > =B7=A2=BC=FE=C8=CB: Xu Xiaohu [mailto:xuxh@huawei.com] > =B7=A2=CB=CD=CA=B1=BC=E4: 2009=C4=EA8=D4=C211=C8=D5 12:02 > =CA=D5=BC=FE=C8=CB: 'Henderson, Thomas R'; 'Tobias Heer'; = 'zhangdacheng@huawei.com' > =B3=AD=CB=CD: 'hiprg@irtf.org' > =D6=F7=CC=E2: =B4=F0=B8=B4: [hiprg] = draft-zhang-hip-hierarchical-parameter-00: > Includinghieararchy in HIT generation >=20 > Hi all, >=20 > IMHO, one can directly use the CGA mechanism with small changes, = rather than > a new algorithm as mentioned by Tobias, to generate hierarchical and > cryptographic host identifiers. In fact, we have already been using = the CGA > mechanism to generate host identifiers in our RANGI proposal > (http://tools.ietf.org/html/draft-xu-rangi-01). The following is the = quote > from that proposal. For more information, please read that draft. >=20 > "The approach of generating hierarchical host identifiers in RANGI is = much > similar to the Cryptographically Generated Addresses (CGA) [RFC3972]. = The > major difference is that the prefix of the RANGI host identifier is AD = ID, rather > than ordinary IPv6 address prefix. In the CGA, the process of = generating a new > CGA takes three input values: a 64-bit subnet prefix, the public key = of the > address owner as a DER-encoded ASN.1 structure of the type SubjectPublicKeyInfo > and the security parameter Sec, which is an unsigned three-bit = integer. In RANGI, > the process of generating a new host identifier also takes three input values: > the n-bit AD ID (the suitable value of =A1=B1n=A1=B1 has not been = determined), the public > key of the host ID owner and the security parameter Sec." >=20 > However, as stated in the CGA [RFC 3972], "...because CGAs themselves = are not > certified, an attacker can create a new CGA from any subnet prefix and = its own > (or anyone else's) public key. However, the attacker cannot take a = CGA created > by someone else and send signed messages that appear to come from the owner > of that address... ". Hence, in order to verify the association = between the > prefix and the address owner, we need some other means, e.g., a certification > issued by a third-party authority, or resorting to such an authority = for > verification if necessary. >=20 > For the privacy of identifier's organizational affiliation (i.e., > Administrative Domain), maybe the two communicating parties could use = the > hierarchical identifier to find the opposing party's locator in a hierarchical > id/locator mapping system, then use the self-certified flat HIT = instead for > subsequent communication if the privacy is necessary. >=20 > Xiaohu >=20 > > -----=D3=CA=BC=FE=D4=AD=BC=FE----- > > =B7=A2=BC=FE=C8=CB: Henderson, Thomas R = [mailto:thomas.r.henderson@boeing.com] > > =B7=A2=CB=CD=CA=B1=BC=E4: 2009=C4=EA8=D4=C211=C8=D5 0:13 > > =CA=D5=BC=FE=C8=CB: Tobias Heer; zhangdacheng@huawei.com; Xu Xiaohu > > =B3=AD=CB=CD: hiprg@irtf.org > > =D6=F7=CC=E2: RE: [hiprg] draft-zhang-hip-hierarchical-parameter-00: > > Includinghieararchy in HIT generation > > > > > > > > > -----Original Message----- > > > From: Tobias Heer [mailto:heer@cs.rwth-aachen.de] > > > Sent: Tuesday, July 28, 2009 6:02 AM > > > To: zhangdacheng@huawei.com; Xu Xiaohu > > > Cc: hiprg@irtf.org > > > Subject: [hiprg] draft-zhang-hip-hierarchical-parameter-00: > > > Includinghieararchy in HIT generation > > > > > > Hi! > > > > > > I just wanted to clarify my comment in the HIPRG meeting on > > > including > > > the hierarchy in the HIT creation process. I think it would > > > be good to > > > have the hierarchy information in the HIT creation process > > > because the > > > hierarchy will be bound to the HIT itself. > > > > > > Below I briefly sketched a possible way of including it without > > > revealing the hierarchy to all hosts. > > > > > > HIT generation could work like this: > > > > > > 1. Pick random secret X > > > > > > 2. H(Hierarchy, X) =3D> HTag > > > > > > 3. H(PubKey, ..., HTag) =3D> HIT (Orchid) > > > > > > --> Only use LTag if you do not want to reveal hierarchy. > > > --> Use hierarchy and X if you want to reveal the hierarchy. > > > > Hi Tobias, > > > > I recently had a chance to listen to the audio archive of the = meeting > > and I'm reviewing the mail now. Can you explain in more detail what = is > > the use case for what you are proposing? I thought that the draft = was > > mainly concerned with having publicly revealed hierarchies so that > > reverse lookups could exploit hierarchy. In your proposal above, = for > > the observer who knows X, how does such observer retrieve hierarchy > > bits, given the HIT, HTag, and X? > > > > Also, I am not sure you can claim that the result from your above is = a > > HIT, because according to RFC4843 and 5201, a HIT is formed without > > these HTags. In particular, the HIT would no longer be able to be > > associated to the key, for an observer who does not know the magic = HTag > > to apply. > > > > Tom From falk@bbn.com Fri Aug 14 10:50:24 2009 Return-Path: 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 1A8C63A680E for ; Fri, 14 Aug 2009 10:50:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.05 X-Spam-Level: X-Spam-Status: No, score=-2.05 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, 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 o5l2KHPg1sve for ; Fri, 14 Aug 2009 10:50:23 -0700 (PDT) Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id C78913A6885 for ; Fri, 14 Aug 2009 10:50:22 -0700 (PDT) Received: from dhcp89-081-142.bbn.com ([128.89.81.142]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1Mbzyz-0004cm-FQ for hiprg@irtf.org; Fri, 14 Aug 2009 12:50:25 -0400 Message-ID: <4A85A3E3.5000605@bbn.com> Date: Fri, 14 Aug 2009 13:50:27 -0400 From: Aaron Falk User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: hiprg@irtf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [hiprg] [Fwd: Copyrights and the IRTF and Independent Stream] X-BeenThere: hiprg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Host Identity Protocol \(HIP\) Research Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2009 17:50:24 -0000 Forwarding to all active IRTF RG mail lists because this issue affects the publication rights for IDs and RFCs developed within the IRTF. Information about IRTF RFCs can be found in http://tools.ietf.org/html/draft-irtf-rfcs-03. Please direct comments to the RFC-interest list (coordinates below). --aaron IRTF Chair -------- Original Message -------- Subject: [rfc-i] Copyrights and the IRTF and Independent Stream Date: Thu, 13 Aug 2009 18:59:42 +0200 From: Olaf Kolkman To: RFC Interest Dear Colleagues, This mail is about rights in RFCs and Internet drafts. The topic draws context, and uses terminology from: RFC 4844: The RFC Series and RFC Editor RFC 4846: Independent Submissions to the RFC Editor RFC 5378: Rights Contributors Provide to the IETF Trust RFC 5377: Advice to the Trustees of the IETF Trust on Rights to Be Granted in IETF Documents First some administrational notes. This mail serves as setting a baseline for a public discussion and is based on a few (virtual and real-life) hallway discussions. The goal of this discussion is to make sure all issues are brought to the table and the stream maintainers and the Trust are aware of the communities opinions. I see my role as an IAB member that is driving the discussion, and mildly moderating it. In the end it is the role of the IAB to see that an appropriate stream dependent process has been followed and that the streams do not interact inapropriatly. So in that sense this discussion informs the IAB too. Although this mail is sent to multiple lists I would like to urge folk to discuss the issues on the rfc-interest list: http://www.rfc-editor.org/mailman/listinfo/rfc-interest Without further ado. As you may know RFCs are published from different streams. With respect to the incoming and outgoing rights only the rights of the IETF stream documents are well defined. And currently the IAB has chosen to have IAB documents fall under this regime too. The situation is less clear for Independent and IRTF Stream documents: all existing provisions are targeted specifically towards IETF Contributions (in the narrow context defined by RFC5378). Besides, currently and in the context of copyrights, Internet Drafts (I-Ds) are seen as IETF contributions. Maintainers of the Independent and IRTF stream would like to have documents from their streams published with full rights to make derivative works or make no derivative works whatsoever, and require attribution in both cases. There are two strategies to make this work: 1. Allow I-Ds and RFCs for the IAB, IRTF, and Independent stream to be published with a Creative Commons license added. A rough outline of one of the ideas that is floating around ist that all contributions that are intended to become an RFC or are an IETF contribution (in the sense of RFC 5378 definition) will continue to have the 5378 license terms as defined by the trust. Since 5378 is non-exclusive authors may add a creative commons license if they'd like to. Care should be taken that those licenses would not be applied to IETF contributions, as that could lead to 'spoofed standard-track RFCs' 2. Have the trust manage the rights for the IAB, IRTF, and Independent streams RFCs and I-Ds. Both strategies may require that at the moment Internet Drafts is published as an RFC it is clear on which stream they are intended to be published, with which rights, and that the authors have appropriate authority to grant/sublicense those rights. In both cases we want to avoid that IETF contributions (I-Ds and RFCs, although it is not clear whether this is a strong requirement for I-Ds) are published with a license policy that would circumvent the Trust's control over the outgoing rights. A tactic/straw-man to implement (2) is as follows: i) Treat all I-Ds as or similar to IETF contributions (this way there is no doubt about the Trust having all necessary rights, see BCP78 section 5.3). There seem to be two paths to proceed: i.1) The stream controllers choose to apply the RFC5378 rules. This possibility is offered in section 4 of 5378 and the IAB stream chooses to apply the rules through its declaration in section 11. i.2) The streams write a stream specific "Rights contributors provide to the IETF trust" document. ii) Have the stream controllers request the IETF Trust to create license(s) for non IETF-Stream RFCs that grant for (full|no) derivative rights, attribution required. (document this request in an RFC). iii) Ask the trust to develop language that can be put on an I-D with which the author can request (full|no) derivative rights if/when the I-D is published on a specific non-IETF stream document. This sort of text would serve as an indication of consent with wide licensing and could be included as boilerplate material together with an indication of intended stream (as in draft-iab-streams-headers- boileplates). There are some pros and cons to this scheme that we need to identify in public discussion, hence this mail. During the hallway discussion, I've seen the following arguments and identified the following open questions. I don't claim completeness. - The Trust is not well equiped to hold non-IETF documents. Mainly because it requires the interperetation that all documents are IETF Documents. Is this interpretation based on language in the Trust agreement or on the definition of IETF Documents in the context of BCP78? Or, is the trust well suited, and does implementation only need some boilerplate changes? - IETF Stream RFCs need to be protected by limited derivative rights so that the IETF keeps ownership over its Standards and can maintain those. Suppose a I-D with full derivative rights is posted (either because the author has published it with Creative Commons, or because the Trust allows full derivative rights for stream specific I-Ds) would narrowing down the rights by publication as an IETF stream RFC cause any problems? Feedback welcome, --Olaf Kolkman