Re: [dhcwg] WGLC for draft-ietf-dhc-sedhcpv6-02 - Respond by May 18

神明達哉 <jinmei@wide.ad.jp> Thu, 08 May 2014 16:24 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 267F31A0066 for <dhcwg@ietfa.amsl.com>; Thu, 8 May 2014 09:24:33 -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 0d1MKR09FGdp for <dhcwg@ietfa.amsl.com>; Thu, 8 May 2014 09:24:29 -0700 (PDT)
Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) by ietfa.amsl.com (Postfix) with ESMTP id 112691A0052 for <dhcwg@ietf.org>; Thu, 8 May 2014 09:24:28 -0700 (PDT)
Received: by mail-wi0-f177.google.com with SMTP id f8so3387117wiw.16 for <dhcwg@ietf.org>; Thu, 08 May 2014 09:24:24 -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=BDdhA8fnQcaECzr1g29cRkGWDrvsuWlV6Ke6fPn/eIs=; b=ewSNsgnGvDkmOKWC86W3co/chz0klUghELoiv5SGu4WZ0X9Pd9ztCXXB5aTbmKoFmP F2dP5GFfPWjI6CwhiiB9keTzqJb+4qmSkquN110PSnGSaDY4grov+hy54sWbJULYHBba Y6YViR4lwii/DxCo9BFLjckUCIdDyGGVDAMF3GIw2KZW69sYn7e0sukL7xgFzTGzKjL8 hYiePToHeoElmc57e/3lAFLZQLLCRFjk6Epj5Oa+3vx+3+9ApBBUdsYbopdAjCzGlvKq kSA/iIG0Rh1VfRAJH5/B+2Tpu9rHZPcGg+1CL7UFEf7v7QIGQCi6Ic1aAEifqe9kS8G5 60kg==
MIME-Version: 1.0
X-Received: by 10.180.11.178 with SMTP id r18mr13865979wib.41.1399566264091; Thu, 08 May 2014 09:24:24 -0700 (PDT)
Sender: jinmei.tatuya@gmail.com
Received: by 10.194.3.14 with HTTP; Thu, 8 May 2014 09:24:23 -0700 (PDT)
In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B923AE442FD@nkgeml512-mbx.china.huawei.com>
References: <535FEDAD.5010103@gmail.com> <CAJE_bqen37j5UCsKZj6syVyvk2Xed4V_xGp-t4xY8shjmS+H5g@mail.gmail.com> <5D36713D8A4E7348A7E10DF7437A4B923AE43272@nkgeml512-mbx.china.huawei.com> <CAJE_bqe75D7oRJq=XmjPR9Dfvu3-AcL8kF9Pkm3JEOVsyxhr5A@mail.gmail.com> <5D36713D8A4E7348A7E10DF7437A4B923AE442FD@nkgeml512-mbx.china.huawei.com>
Date: Thu, 08 May 2014 09:24:23 -0700
X-Google-Sender-Auth: x4ks-EN6rMC0SDu9BG6AMxN5YeY
Message-ID: <CAJE_bqc+Z8awb5773OLs8QtXuCRxYCWFRAKuQ9YP8anFwEQqsQ@mail.gmail.com>
From: 神明達哉 <jinmei@wide.ad.jp>
To: Sheng Jiang <jiangsheng@huawei.com>
Content-Type: text/plain; charset="UTF-8"
Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/SdTM91coKlcr1FAJlUrWaU_6K4E
Cc: dhcwg <dhcwg@ietf.org>, Ted Lemon <ted.lemon@nominum.com>
Subject: Re: [dhcwg] WGLC for draft-ietf-dhc-sedhcpv6-02 - Respond by May 18
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, 08 May 2014 16:24:33 -0000

At Thu, 8 May 2014 08:56:59 +0000,
Sheng Jiang <jiangsheng@huawei.com> wrote:

> In the common scenario that we expect, the leap of faith model is
> not deployed independent. In the deployment of secure DHCPv6 server,
> the server serves three types of clients: 1) full authenticated
> clients, 2) clients trusted by leap of faith model, 3)
> un-authenticated clients. Hence, the clients are in different class
> for limited resource assignment and access priority. It provides
> fine-grained client management.

I'm afraid we're on different pages...the above explanation doesn't
answer my questions:

> >I don't think my main point is MUST vs MAY.  It's about a more
> >general point of authenticating messages from clients to servers:
> >
> >- whether we really need (public key) authentication in that
> >  direction, and if we do, why
> >
> >- also if we do, what's the commonly expected model of "trust anchor":
> >  leap of faith or use of CA or something else, and if it's more
> >  likely to be a weaker model like leap of faith (I suspect so, for
> >  the direction of clients to servers), whether the motivation (1st
> >  bullet) is worth the weaker security
> >
> >- and, if it's more likely to rely on leap of faith, what kind of
> >  consideration is needed

If this is because I was not clear enough, I have no idea how I can
clarify my questions further.  As I said in my very first comment on
the draft, I don't have a strong position on whether to advance the
draft, so I guess I should simply drop these points, especially if
others in the wg don't see these an issue.

--
JINMEI, Tatuya