[dhcwg] FW: Could you please help me forward this to DHCP list?
Sheng Jiang <jiangsheng@huawei.com> Wed, 22 July 2015 13:42 UTC
Return-Path: <jiangsheng@huawei.com>
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B95F1A89A7 for <dhcwg@ietfa.amsl.com>; Wed, 22 Jul 2015 06:42:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.61
X-Spam-Level:
X-Spam-Status: No, score=-3.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_57=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QKmcSwEvEOy5 for <dhcwg@ietfa.amsl.com>; Wed, 22 Jul 2015 06:42:26 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E566E1A9149 for <dhcwg@ietf.org>; Wed, 22 Jul 2015 06:42:04 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BZA86902; Wed, 22 Jul 2015 13:42:02 +0000 (GMT)
Received: from nkgeml405-hub.china.huawei.com (10.98.56.36) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 22 Jul 2015 14:42:01 +0100
Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.227]) by nkgeml405-hub.china.huawei.com ([10.98.56.36]) with mapi id 14.03.0158.001; Wed, 22 Jul 2015 21:41:56 +0800
From: Sheng Jiang <jiangsheng@huawei.com>
To: "dhcwg@ietf.org" <dhcwg@ietf.org>
Thread-Topic: Could you please help me forward this to DHCP list?
Thread-Index: AQHQxHYW3awiaOcTaUeYfdzFw0/eFZ3nfzAx
Date: Wed, 22 Jul 2015 13:41:55 +0000
Message-ID: <5D36713D8A4E7348A7E10DF7437A4B927BAE0D5E@nkgeml512-mbx.china.huawei.com>
References: <BLU436-SMTP14100930473A4FF3EECB04988830@phx.gbl>
In-Reply-To: <BLU436-SMTP14100930473A4FF3EECB04988830@phx.gbl>
Accept-Language: en-GB, zh-CN, en-US
Content-Language: en-GB
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.47.71.110]
Content-Type: multipart/alternative; boundary="_000_5D36713D8A4E7348A7E10DF7437A4B927BAE0D5Enkgeml512mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <http://mailarchive.ietf.org/arch/msg/dhcwg/YO8oZrwlu0h54cqRjSHaDX46V3g>
Cc: "dacheng.zhang@gmail.com" <dacheng.zhang@gmail.com>
Subject: [dhcwg] FW: Could you please help me forward this to DHCP list?
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.15
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: <https://mailarchive.ietf.org/arch/browse/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, 22 Jul 2015 13:42:30 -0000
Forward on behalf of Dacheng, co-author of secure DHCPv6 draft. Hi, Charlie: Thanks for the comments. See my reply inline please. [dhcwg] Additional feedback on secure DHCPv6 draft Brian Haberman <brian@innovationslab.net<mailto:brian@innovationslab.net>> Mon, 20 July 2015 12:25 UTCShow header<https://mailarchive.ietf.org/arch/search/?email_list=dhcwg&q=security#> All, Charlie Kaufman has provided a review of the secure DHCPv6 draft. Brian -------- Forwarded Message -------- Subject: RE: [secdir] DHCP IPv6 help needed Date: Thu, 16 Jul 2015 19:28:54 -0700 From: Charlie Kaufman <charliekaufman@outlook.com<mailto:charliekaufman@outlook.com>> To: 'Brian Haberman' <brian@innovationslab.net<mailto:brian@innovationslab.net>>, 'Kathleen Moriarty' <kathleen.moriarty.ietf@gmail.com<mailto:kathleen.moriarty.ietf@gmail.com>> CC: 'Stephen Farrell' <stephen.farrell@cs.tcd.ie<mailto:stephen.farrell@cs.tcd.ie>> I've reviewed draft-ietf-dhc-sedhopv6-08, and I have some thoughts on possible improvements - some are details; others are more philosophical. I don't have a detailed understanding of DHCPv6, so some issues may be based on my misunderstanding it. I'll try to mention my assumptions where I'm less confident in them. I wasn't sure where to send this, so I'll send it to you and hope you will forward it appropriately. A big question that probably should be answered in the introduction or under security considerations is "what security vulnerabilities are we trying to mitigate?". To the extent that the primary goal of DHCP is to hand out network parameters (and in particular, temporary IP addresses), a badly behaved DHCP server on a link can issue an IP address that will not work, thus denying service to the requesting client. If it issues an IP address already in use, it might also deny service to some other node on the network. A bad client can acquire large numbers of IP addresses and (at least with IPv4) exhaust the address pool. It was my understanding that with IPv6 nodes just had to acquire the network address and could use their own unique ID so that allocations from a limited pool of addresses was unnecessary. [Dacheng] DHCP server could provide additional information (DNS for example) other than IP address. Such information could be worthwhile to be protected. Given all that, what are the threats? The other use of DHCP was as an extension to the old BootP protocol, where an uninitialized node could "boot from the network" and download its operating system and other extremely security sensitive information. That process started by getting some parameters via DHCP. In that case, it would make a lot of sense to make the protocol more secure, but it would also be harder because when dealing with an uninitialized machine there is are not going to be trusted root certificates or any other means of authenticating the messages. [Dacheng] Interesting. If you are at IETF, maybe we can have a talk about it. In some cases dealing with the secure initialization of a node, it would be good if there were a way for the messages to be encrypted as well as signed. I know of at least one system that uses DHCP to download a random number of purposes of helping to seed the booting client's random number generator. It would be better if that exchange could be encrypted. [Dacheng] Encryption could be an optional function. Will discuss with DHC people to discuss we should support such information again. A smaller but still global issue: the spec is written as though DHCPv6 were symmetric between the two communicating nodes. My understanding is that it is a request/response protocol where the client always initiates exchanges and the server always responds. This implies some [Dacheng] Server may also send out unsolicited messages to the client, if they have communicated in advance.. differences in how algorithms are negotiated. It is appropriate that if a server gets a request with an algorithm it does not support, that it send an error code with the expectation that the client will try again. But if the client gets a request with an algorithm it does not support, it cannot request that the server use a different one. This will make it difficult for the server to migrate to new algorithms. A better way would be to introduce a new optional field in requests listing the supported algorithms. The only real alternative is for the server to assume that the client supports that algorithms that the client used in the request and to favor those. [Dacheng] In this case, we will expect there will be multiple step communications between the client and server, which,however, will change DHCP a lot. We discussed this with the DHC before, the idea was rejected. Please keep in mind during the discussion that in all the conditions the client sends a request and the server replies. We cannot add additional messages for negotiation. My remaining comments are to the details of the formatting, though some are pretty important: The encoding allows only a single certificate. There are very few cases where this will be useful. In all of the public PKIs deployed out there, endpoints have certificate chains of at least 2 or 3 certificates and not infrequently 4 or more. The protocol should probably allow what IKEv2 calls a "certificate bundle”. [Dacheng] Agree! Will discuss DHC people about this comment. That, however, will exacerbate what might already be a fatal problem of very long messages that need to be fragmented. It is very difficult for a server to protect itself from state exhaustion denial of service attacks while accepting fragmented datagrams. It might be better to do something like sending hashes of certificates instead of the certificates themselves and then providing a mechanism for retrieving the certificates based on the hashes in a series of messages. But there are no simple elegant solutions here. I don't have a concrete recommendation of than to discuss alternatives with implementers. [Dacheng] It is an open question which will occurs in many cases where fragmentation exists. In the syntax of a signature, it would probably be better to have a single algorithm identifier that specifies both the hash and the public key signature algorithm rather than separate identifiers for the two. That's because some public key signature algorithms - including RSASSA-PKCS1-v1_5 include a specifier of the hash algorithm within the encoded signed data. If you include the signature algorithm redundantly, they you need to say what happens when they differ. Another alternative would be to take the signature encoding from X.509 certificates the way you did with public key Specifications. [Dacheng] OK. It is dangerous to use timestamps to avoid replay attacks when synchronized time is not otherwise needed because it implicitly requires caching all packets that arrived during the clock-skew window, and that might be a very large number. You might be better off using something like TCP-cookies or IKEv2-cookies where if the server is being overwhelmed it replies with an unsigned reply containing a nonce and asks the client to resubmit the request with that nonce. If cleverly designed, the server can compute that nonce as a hash of a secret and information from the packet header so that it need not keep state while waiting for the second message. [Dacheng] I think it only is a design choice. The server can record all the messages within a window, it can get a better anyti-replay capability. However, if the server does not record messages, it can only rely on the timestamps to detect replays. At the end of section 6.2, there is a mention of minimum and maximum key lengths. While I think this is a good idea, there does not appear to be anywhere that this information is encoded in the exchanged data. The only place I can think of it being useful would be in the "supported algorithms list" field that I proposed adding. Otherwise, the sender picks a number and the recipient can take it or leave it. [Dacheng] The later option is better. Because we cannot extend the DHCP with additional messages for negotiation, if the receiver thinks the key is not long enough, it just discard the message. I will double check whether there is such a error type which the server can use to inform the client. Finally, when discussing Relay Agents, there are fields that Relay agents need to be able to add and remove. Unless these are encoded in some separate part of the message, the sender will have to anticipate any fields that it knows the relay agent will remove and not include those under the signature and the recipient will need to know what fields the relay agent added and exclude those from the signature calculation. This all seems very fragile. It might be good to do something explicit about it. [Dacheng] As far as I know, in DHCPv6, rely agents will not change the fields protected by the signatures. Correct me if I am wrong.^_^ --Charlie