IETF Logo Mail Archive

Re: [dhcwg] WGLC for draft-ietf-dhc-sedhcpv6-04 - Respond by Nov 3, 2014

神明達哉 <jinmei@wide.ad.jp> Thu, 30 October 2014 16:54 UTC

Return-Path: <jinmei.tatuya@gmail.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 8334A1A1A64 for <dhcwg@ietfa.amsl.com>; Thu, 30 Oct 2014 09:54:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.978
X-Spam-Level:
X-Spam-Status: No, score=-0.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no
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 Z-49tdqhKpkX for <dhcwg@ietfa.amsl.com>; Thu, 30 Oct 2014 09:54:13 -0700 (PDT)
Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBFB11A040C for <dhcwg@ietf.org>; Thu, 30 Oct 2014 09:53:28 -0700 (PDT)
Received: by mail-wi0-f179.google.com with SMTP id h11so7981558wiw.6 for <dhcwg@ietf.org>; Thu, 30 Oct 2014 09:53:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=cb2QnWgko0pZQ355GXTyunIrpUwhQAxogUkCXcENI90=; b=YGXSR2l6GcoTp2FfiJ9Nph3F9Zefiah55s4yjgPKENvMxHTSJGenA1MWwU7Hdr1cQb wRx6AQIz1RUNpgnGwOvaNm6MVhuIZeQeN/Scbp/dnAfS7Bext7Gt/cLEEQitrw/cFW44 JWEdOw45hwocYRB4yECaErNkIvwSxw7u08p93m466lD09r75wsW1dTd+pWyJ9qNvR3LY I4CgEKX8LU4jSqf9Cae2qLSvJ5fGTrdneknLUlKZ4VKo6bTc0N4jYgK5XpWQkFUASUsY PpRzNFA+L6YiZezmXvehmOhy5VDGBtJmgNjOiU7EpQSIEWdwSk5i1M3idOFciXpYvJb2 LJEQ==
MIME-Version: 1.0
X-Received: by 10.180.94.138 with SMTP id dc10mr45598820wib.31.1414688006768; Thu, 30 Oct 2014 09:53:26 -0700 (PDT)
Sender: jinmei.tatuya@gmail.com
Received: by 10.194.19.136 with HTTP; Thu, 30 Oct 2014 09:53:26 -0700 (PDT)
In-Reply-To: <2134F8430051B64F815C691A62D9831832D6FD2C@XCH-BLV-504.nw.nos.boeing.com>
References: <489D13FBFA9B3E41812EA89F188F018E1B6F6882@xmb-rcd-x04.cisco.com> <2134F8430051B64F815C691A62D9831832D5B51E@XCH-BLV-504.nw.nos.boeing.com> <5D36713D8A4E7348A7E10DF7437A4B923AF6A5C0@nkgeml512-mbx.china.huawei.com> <2134F8430051B64F815C691A62D9831832D6E707@XCH-BLV-504.nw.nos.boeing.com> <CAJE_bqeLugy4UuJdT2wLYN6Kr_B-WGBnqXo5x5j0iNGAmCqNCA@mail.gmail.com> <2134F8430051B64F815C691A62D9831832D6FD2C@XCH-BLV-504.nw.nos.boeing.com>
Date: Thu, 30 Oct 2014 09:53:26 -0700
X-Google-Sender-Auth: 1QvWzIk6GAV6Sjf0QG9dUIu3a88
Message-ID: <CAJE_bqd54u_msDjwO0Khaz3o+vTe=wbPjOCSAPSr=_gBbzaHgw@mail.gmail.com>
From: 神明達哉 <jinmei@wide.ad.jp>
To: "Templin, Fred L" <Fred.L.Templin@boeing.com>
Content-Type: text/plain; charset="UTF-8"
Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/sUgPn1Iz1FfzLTcp39cIApQEip8
Cc: "dhcwg@ietf.org" <dhcwg@ietf.org>, "Bernie Volz (volz)" <volz@cisco.com>
Subject: Re: [dhcwg] WGLC for draft-ietf-dhc-sedhcpv6-04 - Respond by Nov 3, 2014
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: <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: Thu, 30 Oct 2014 16:54:14 -0000

At Wed, 29 Oct 2014 20:03:42 +0000,
"Templin, Fred L" <Fred.L.Templin@boeing.com> wrote:

> Take for example a client C1 that provides a valid certificate but includes a DUID
> corresponding to client C2 in a DHCPv6 PD Request. Will the server return an
> IA_PD to client C1 that includes a prefix that is intended for client C2? That is
> the scenario I need to defend against.

Again just in my understanding, the protocol described in the sedhcpv6
draft wouldn't be able to prevent it by itself.  I suspect it's a
matter of the server implementation/operation.  In practice, the
server should maintain some relationship between the certificate's
subject (i.e., that particular client, whether it's in the form of
DUID or of an FQDN or something else) and information (address,
prefix, etc) that the server would assign to the client; otherwise,
just validating the certificate wouldn't be much useful.  I believe
your goal can be achieved by using sedhcpv6 with this setup.

> > Enforcing it could be part of the server implementation/configuration,
> > though.
>
> Enforce by linking the client's certificate to its DUID? Something else?

Enforce by linking the client's certificate to *some ID* of the client
(which might be the DUID or something else).  See above.

--
JINMEI, Tatuya

v2.23.0 | Report a Bug | By Email