Re: [secdir] review of draft-ietf-dhc-secure-dhcpv6-04.txt

Sheng Jiang <jiangsheng@huawei.com> Mon, 27 February 2012 08:18 UTC

Return-Path: <jiangsheng@huawei.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACB2C21F8528 for <secdir@ietfa.amsl.com>; Mon, 27 Feb 2012 00:18:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.494
X-Spam-Level:
X-Spam-Status: No, score=-6.494 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
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 wY8vIpBsrw+J for <secdir@ietfa.amsl.com>; Mon, 27 Feb 2012 00:18:07 -0800 (PST)
Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id 8378621F8540 for <secdir@ietf.org>; Mon, 27 Feb 2012 00:18:05 -0800 (PST)
Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0M01007OXLPWAB@szxga03-in.huawei.com> for secdir@ietf.org; Mon, 27 Feb 2012 16:17:56 +0800 (CST)
Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0M010071SLPWW2@szxga03-in.huawei.com> for secdir@ietf.org; Mon, 27 Feb 2012 16:17:56 +0800 (CST)
Received: from szxeml213-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AHB75477; Mon, 27 Feb 2012 16:17:04 +0800
Received: from SZXEML403-HUB.china.huawei.com (10.82.67.35) by szxeml213-edg.china.huawei.com (172.24.2.30) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 27 Feb 2012 16:16:36 +0800
Received: from SZXEML506-MBS.china.huawei.com ([169.254.3.20]) by szxeml403-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.003; Mon, 27 Feb 2012 16:16:57 +0800
Date: Mon, 27 Feb 2012 08:16:56 +0000
From: Sheng Jiang <jiangsheng@huawei.com>
X-Originating-IP: [10.108.4.88]
To: Sheng Jiang <jiangsheng@huawei.com>, Stephen Kent <kent@bbn.com>
Message-id: <5D36713D8A4E7348A7E10DF7437A4B92188B1DF2@SZXEML506-MBS.china.huawei.com>
MIME-version: 1.0
Content-type: multipart/alternative; boundary="Boundary_(ID_Iail226E+BvXNTAM6H5I7Q)"
Content-language: zh-CN
Accept-Language: en-GB, zh-CN, en-US
Thread-topic: review of draft-ietf-dhc-secure-dhcpv6-04.txt
Thread-index: AQHM1wVGR+IsEftM3kywUBVOpvWIcZYUcUbwgDPx0pCAAP6SAIAAhvYAgAanwQA=
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
X-CFilter-Loop: Reflected
References: <p0624080ccb3e5b4801c7@[128.89.89.66]> <5D36713D8A4E7348A7E10DF7437A4B92188B034F@SZXEML506-MBS.china.huawei.com> <p06240802cb6b41feba2f@[172.20.8.192]>
Cc: "rdroms.ietf@gmail.com" <rdroms.ietf@gmail.com>, "john_brzozowski@cable.comcast.com" <john_brzozowski@cable.comcast.com>, "ted.lemon@nominum.com" <ted.lemon@nominum.com>, "shenshuo@cnnic.cn" <shenshuo@cnnic.cn>, "secdir@ietf.org" <secdir@ietf.org>
Subject: Re: [secdir] review of draft-ietf-dhc-secure-dhcpv6-04.txt
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 27 Feb 2012 08:18:09 -0000

Hi, Stephen,

We are still working on your comments. You wrote "it appears that algorithm agility support for Secure DHCPv6 is based (in large part) on carrying the hash and signature algorithm IDs in the Signature Option. That is different from the RFC 4270 analysis of how to enable algorithm agility for the CGA itself."

Could you give further suggestion: if you don't like the way of agility support? What is better mechanism to support algorithm agility in our approach?

Many thanks and best regards,

Sheng

From: Sheng Jiang
Sent: Thursday, February 23, 2012 9:39 AM
To: 'Stephen Kent'
Cc: secdir@ietf.org; shenshuo@cnnic.cn; ted.lemon@nominum.com; john_brzozowski@cable.comcast.com; rdroms.ietf@gmail.com
Subject: RE: review of draft-ietf-dhc-secure-dhcpv6-04.txt

Hi, Stephen,

Thanks for point out the incorrect text. It was there from early stage design. I have corrected it in the new version.

Many thanks,

Sheng

From: Stephen Kent [mailto:kent@bbn.com]
Sent: Thursday, February 23, 2012 9:32 AM
To: Sheng Jiang
Cc: Sheng Jiang; secdir@ietf.org; shenshuo@cnnic.cn; ted.lemon@nominum.com; john_brzozowski@cable.comcast.com; rdroms.ietf@gmail.com; Stephen Kent
Subject: RE: review of draft-ietf-dhc-secure-dhcpv6-04.txt

At 2:33 AM +0000 2/22/12, Sheng Jiang wrote:
Hi, Stephen,

Thanks for your review. I have integrated them in a new version or make some correspondent improvements. However, I do not agree the below comment and would like to discuss it further.

<Stephen> The fact that the signature option can be placed anywhere in the DHCPv6 message strikes me as dangerous. It imposes a requirement on a receiver to treat the protected and unprotected portions of the message differently, for any possible placement of the signature option. This adds complexity to implementations, since the security checking would have to indicate to the rest of message processing which parts of a message were checked and which were not verified. Unless there are DHCHv6 options that may be modified (or added) legitimately when a message traverses a relay, it is not clear why there needs to be a provision to exclude any portions of a DHCPv6 message from  the integrity/authentication check.

<Sheng> The charge is not right here. Although the signature option can be placed anywhere, it actually protects ALL DHCPv6 options and payload (except for itself and auth option), see Section 5.2 for how to perform signature. Therefore, there is no unprotected  portion at all. The place of signature option does not mean the portion after it is unprotected.

The text in 5.2 states, when it describes the Sig option:

"It protects all the DHCPv6 header and options before it. Any options after the Signature option can be processed, but it should be noticed that they are not protected by this Signature option."

This text contradicts what you said above. The text later in 5.2, in the discussion of how to compute the sig value, says what you meant (sort of), but that contradicts the text cited above.  Also, the text describing how to compute the sig is incorrect, since it says:

" The signature constructed by using the sender's private key over the following sequence of octets:..."

The private key is used to sign the hash value computed over the sequence of octets described in this part of 5.2. Also, allowing the sig option  to appear anywhere in the message is, as I indicated earlier, a bad idea. Even if the text is corrected to make clear that the whole message is protected, it is "cleaner" to put the sig option at the end, so that the sender and receiver does not have to skip over it in computing the hash value that is to be signed.

Steve