Re: [dhcwg] draft-bi-dhc-sec-option

Cui Yang <cuiyang@huawei.com> Wed, 28 March 2012 17:31 UTC

Return-Path: <cuiyang@huawei.com>
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D64D921E809E for <dhcwg@ietfa.amsl.com>; Wed, 28 Mar 2012 10:31:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.74
X-Spam-Level: *
X-Spam-Status: No, score=1.74 tagged_above=-999 required=5 tests=[AWL=0.136, BAYES_00=-2.599, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lg5T30y7SeEb for <dhcwg@ietfa.amsl.com>; Wed, 28 Mar 2012 10:31:36 -0700 (PDT)
Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 3A85621E804A for <dhcwg@ietf.org>; Wed, 28 Mar 2012 10:31:36 -0700 (PDT)
Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AET69298; Wed, 28 Mar 2012 13:31:35 -0400 (EDT)
Received: from DFWEML406-HUB.china.huawei.com (10.193.5.131) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 28 Mar 2012 10:29:32 -0700
Received: from SZXEML401-HUB.china.huawei.com (10.82.67.31) by dfweml406-hub.china.huawei.com (10.193.5.131) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 28 Mar 2012 10:29:36 -0700
Received: from SZXEML508-MBS.china.huawei.com ([169.254.6.137]) by szxeml401-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.003; Thu, 29 Mar 2012 01:29:26 +0800
From: Cui Yang <cuiyang@huawei.com>
To: Ted Lemon <Ted.Lemon@nominum.com>, Alper Yegin <alper.yegin@yegin.org>, dhc WG <dhcwg@ietf.org>
Thread-Topic: [dhcwg] draft-bi-dhc-sec-option
Thread-Index: AQHNDEv5iTILqwgG4EabUrbxfUEvZ5Z/0S6a//+QYwCAAI3x1A==
Date: Wed, 28 Mar 2012 17:29:24 +0000
Message-ID: <8CC0CB0BCAE52F46882E17828A9AE2161F479BD7@SZXEML508-MBS.china.huawei.com>
References: <CAC16W0DXs4q5ApuiyN4pVJVuXQQunAFMGnu5JjJvszcWjnncJA@mail.gmail.com>, <2F208A97-BFF3-4820-BA98-3E47AC41D992@yegin.org>, <8D23D4052ABE7A4490E77B1A012B6307472C3E6F@mbx-02.win.nominum.com>, <8CC0CB0BCAE52F46882E17828A9AE2161F479B8F@SZXEML508-MBS.china.huawei.com>, <8D23D4052ABE7A4490E77B1A012B6307472D1DD6@mbx-01.win.nominum.com>
In-Reply-To: <8D23D4052ABE7A4490E77B1A012B6307472D1DD6@mbx-01.win.nominum.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [172.24.1.67]
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Subject: Re: [dhcwg] draft-bi-dhc-sec-option
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: <dhcwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dhcwg>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 28 Mar 2012 17:31:36 -0000

Yes, the client could find out that the PKI server it is talking with is not a valid one in this case, after running a mutual authentication.
A proof of possession method in X.509 [RFC4210,4211] could be used to avoid revealing the sensitive information.

BR,
Yang
________________________________________
发件人: Ted Lemon [Ted.Lemon@nominum.com]
发送时间: 2012年3月29日 0:30
到: Cui Yang; Alper Yegin; dhc WG
主题: RE: [dhcwg] draft-bi-dhc-sec-option

> The proposed DHCP option is aimed to help set up the security mechanism, i.e., carrying IP addresses of PKI server, etc.
> But the option itself does not need to be protected, or in other words, the security does not necessarily rely on the DHCP option.

So if a rogue DHCP server provides a PKI server address, the client will be able to tell that it is not a legitimate server without revealing sensitive information to it?