[dhcwg] Benoit Claise's No Objection on draft-ietf-dhc-dhcpv6-active-leasequery-03: (with COMMENT)
"Benoit Claise" <bclaise@cisco.com> Mon, 06 July 2015 20:41 UTC
Return-Path: <bclaise@cisco.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 01E021B3250; Mon, 6 Jul 2015 13:41:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 0hAPmyNJZuxw; Mon, 6 Jul 2015 13:41:30 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D3521B3230; Mon, 6 Jul 2015 13:41:13 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Benoit Claise <bclaise@cisco.com>
To: The IESG <iesg@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 6.0.4.p1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20150706204113.4940.92347.idtracker@ietfa.amsl.com>
Date: Mon, 06 Jul 2015 13:41:13 -0700
Archived-At: <http://mailarchive.ietf.org/arch/msg/dhcwg/MlvvNcyy5lWhkJiObBjEw2bEdks>
Cc: dhc-chairs@ietf.org, draft-ietf-dhc-dhcpv6-active-leasequery@ietf.org, sob@harvard.edu, dhcwg@ietf.org
Subject: [dhcwg] Benoit Claise's No Objection on draft-ietf-dhc-dhcpv6-active-leasequery-03: (with COMMENT)
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.15
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: Mon, 06 Jul 2015 20:41:36 -0000
Benoit Claise has entered the following ballot position for draft-ietf-dhc-dhcpv6-active-leasequery-03: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-active-leasequery/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- No objection, but if taken into account, Scott's OPS DIR feedback would improve the document. ================================= Scott, We totally agree that this protocol should be able to restrict who gets the information about what is going on with the DHCP server. We *thought* that we had that covered... The current draft has TLS connections as a SHOULD, and includes the following text at the end of section 9.1: > In the event that the DHCPv6 server sends a REPLY message without > DHCPv6 status code option included (which indicates success), the > requestor is supposed to initiate a TLS handshake [RFC5246] (see > Section 8.2). During the TLS handshake, the DHCPv6 server MUST > verify the requestor's digital certificate. > If the TLS handshake is not successful in creating a TLS connection, > the server MUST drop the TCP connection. The intent here is that in requiring the verification of the requestor's digital certificate that the server would also be able to restrict connections to requestors that it considered acceptable. We recently took a lot of words out of the security considerations section on restricting connections to acceptable requestors because that would have required using IP addresses, which everyone thought was useless. We didn't put more words back in about the TLS certificates, but perhaps we should have? Anyway, there are several issues: 1. Does the verification of the TLS certificates allow the server to be able to determine that a requestor is or is not allowed to access the active leasequery capability? 2. We believe that there is more than one way to utilize certificates to decide if a requestor is allowed. We also sort of assumed that was documented elsewhere and wasn't something that we needed to detail in this draft. Do you know of a draft we could reference on how to do that, or failing that, know of text we could incorporate that explains how to do that. If #1 is no, then we are confused because we thought that was the point of verifying the digital certificates (instead of just using the certificate to ensure that the link is encrypted). =============================== Scott's answer: it is always useful to spell out what is on your mind if you are projecting that the use of certs equals access control you should just say that a few extra words would dog a LONG way Scott
- [dhcwg] Benoit Claise's No Objection on draft-iet… Benoit Claise