Re: [secdir] review of draft-ietf-dhc-secure-dhcpv6-04.txt
Sheng Jiang <jiangsheng@huawei.com> Thu, 23 February 2012 01:39 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 BC39E21F8527 for <secdir@ietfa.amsl.com>; Wed, 22 Feb 2012 17:39:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.485
X-Spam-Level:
X-Spam-Status: No, score=-6.485 tagged_above=-999 required=5 tests=[AWL=0.113, 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 Y5XMadMyGWJ7 for <secdir@ietfa.amsl.com>; Wed, 22 Feb 2012 17:39:31 -0800 (PST)
Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id BD01F21F8522 for <secdir@ietf.org>; Wed, 22 Feb 2012 17:39:30 -0800 (PST)
Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LZT008J7OLP5J@szxga04-in.huawei.com> for secdir@ietf.org; Thu, 23 Feb 2012 09:39:25 +0800 (CST)
Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LZT00IAVOLGAD@szxga04-in.huawei.com> for secdir@ietf.org; Thu, 23 Feb 2012 09:39:25 +0800 (CST)
Received: from szxeml214-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AGZ93729; Thu, 23 Feb 2012 09:39:24 +0800
Received: from SZXEML414-HUB.china.huawei.com (10.82.67.153) by szxeml214-edg.china.huawei.com (172.24.2.29) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 23 Feb 2012 09:39:05 +0800
Received: from SZXEML506-MBS.china.huawei.com ([169.254.3.20]) by SZXEML414-HUB.china.huawei.com ([10.82.67.153]) with mapi id 14.01.0323.003; Thu, 23 Feb 2012 09:39:18 +0800
Date: Thu, 23 Feb 2012 01:39:17 +0000
From: Sheng Jiang <jiangsheng@huawei.com>
In-reply-to: <p06240802cb6b41feba2f@[172.20.8.192]>
X-Originating-IP: [10.108.4.88]
To: Stephen Kent <kent@bbn.com>
Message-id: <5D36713D8A4E7348A7E10DF7437A4B92188B095A@SZXEML506-MBS.china.huawei.com>
MIME-version: 1.0
Content-type: multipart/alternative; boundary="Boundary_(ID_r+qy3YkjBITemwCMmeXN/w)"
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+IsEftM3kywUBVOpvWIcZYUcUbwgDPx0pCAAP6SAIAAhvYA
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: Thu, 23 Feb 2012 01:39:32 -0000
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
- [secdir] review of draft-ietf-dhc-secure-dhcpv6-0… Stephen Kent
- Re: [secdir] review of draft-ietf-dhc-secure-dhcp… Sheng Jiang
- Re: [secdir] review of draft-ietf-dhc-secure-dhcp… Sheng Jiang
- Re: [secdir] review of draft-ietf-dhc-secure-dhcp… Stephen Kent
- Re: [secdir] review of draft-ietf-dhc-secure-dhcp… Sheng Jiang
- Re: [secdir] review of draft-ietf-dhc-secure-dhcp… Sheng Jiang
- Re: [secdir] review of draft-ietf-dhc-secure-dhcp… Sheng Jiang